Zugg Software :: View topic - [3.03a-3.05] bug: PE freezes on a particular package, and wont create new setti

Posted: Sun Feb 22, 2009 4:37 am

This used to happen ages back. Then it was fixed. Now I randomly see it again after using a friends packages. I'll be creating triggers (only seems to be triggers) and suddenly when I click on new trigger, it wont create it. I also then cannot switch between package-tabs. Closing and reopening the PE won't change this - it needs me to restart CMUD.

I did a fresh install before trying his packages on 2.37. After it happened, I exported each package to xml, did another reinstall and then imported them all. Still occurring. Now I'm trying 3.03a and once again, its occurring. Its also happened much more often than it ever did many months ago when the bug first occurred and was fixed. So often I sometimes can't create a single trigger without it happening.

This is not on my computer with 64 bit XP, by the way. I've been using a laptop with normal XP for quite a while now, and CMUD has been impressively stable. Yet for some reason it is suddenly crapping out on me.

Posted: Sun Feb 22, 2009 6:28 am

Update: Its not only when creating triggers, though that is the most common time. Here are some things I have noticed:

- when creating triggers, I can generally create as many as I like one after the other. It is when I am creating one, going back to main window (to get the next pattern) then returning and creating another. To actually modify my settings, I've been creating whole bunches of triggers and giving them temporary patterns, so that when I'm going back and forth between PE and main window, I don't have to create new triggers - but instead modify the ones I make at the start.

- it happens intermittently when I am going in between packages, and not necessarily when creating triggers. There seems to be a higher frequency if I am modifying the "this package enabled for the following packages" checkboxes.

- [Edit] Removed this one about the package being lost. That was my own mistake - and it wasn't really lost. I was a bit, though.. hehe

I'll continue to add information to this reply as I find it.

Posted: Mon Feb 23, 2009 5:43 pm

Are you doing your editing "live" while the MUD is running? If so, my guess is that you have some new trigger running in the background that is causing this problem that you didn't have in the past. The threading issues in CMUD can be specifically related to a certain command or function that you are calling. If there is a particular command/function that isn't thread-safe, then you'll only have problems when calling that specific command/function.

So this could be hard to track down. You'll need to spend some time trying to determine which scripts are being triggered and running while you are editing that might cause the problem. You could start by disabling all triggers and then enable them one by one until you start seeing the problem, but that will take a while.

It might also be mapper related if you have any room scripts that are running. Using the Script Debugger and turning on the "Show all script execution" message should help you determine what scripts are running.

Posted: Tue Feb 24, 2009 8:27 am

I almost always edit live. Hrm. Hard for me to track down since its new packages (from a friend), but since he told me he doesn't get the same problem, it could be a conflict between one of my 2 remaining packages, and one of his.

I've tried to eliminate issues like that by setting all of his packages to not see mine, and vice versa. Whenever there is need for communication between packages, I do something in another package I created, and communication goes via that one.

Still, I will try to figure it out. The new packages have been scripted quite simply - my friend doesn't really understand features like functions, events, multi-threading, even multistate triggers. The majority of his scripts could have been done in zmud 3.11 :D so its more likely to be something o mine clashing with him, perhaps.

Posted: Sun Mar 15, 2009 4:19 am

<?xml version="1.0" encoding="ISO-8859-1" ?>
<cmud>
<trigger name="prompt sub" priority="1" prompt="true" enabled="false" copy="yes">
<pattern><![CDATA[<<< ARM BALANCE >>>]]></pattern>
<value>#SUB {@armb}</value>
</trigger>
</cmud>

I customise my own prompt using mudbot. Since mudbot has a bug where it doesn't pass on arm balance properly in the prompt stats, I have turned off arm balance in the Aetolian (serverside in other words) config options. I then display <<<ARM BALANCE>>> in my prompt in a nice, big ugly way, and use the above trigger to substitute this with my own arm balance stat.

The value of @armb is always one of: lr, xy, xl, ry.

While that trigger is disabled, I don't get the problem in the OP. The script debugger always shows the following as the last thing seen when the fault occurs:

a AetBot ]H:3820|3556 100% Exp:18 >>> 18000|17514
f AetBot | Pattern: <<< ARM BALANCE >>>
c AetBot | exec : Pattern "prompt sub" : #SUB {@armb}
g AetBot =[37mH:[32m3820[1;37m|3556 [1;31m100[1;37m% [0;37mExp:18 [1;31m<[0;37mkcsdb [32me[32mb[37m lr[1;31m> [0;37m18000|17514 [0m

An interesting extra piece of information, is if I have the debugger window open, and switch to it once the bug occurs, then switch back to the PE - the bug is fixed and I can continue working without the need to close and reopen CMUD as I would otherwise.

Edit: my main window is called "Aetbot" because I use mudbot with it as that session.. not because I'm botting. Just in case one of the Aetolian developers happens to follow this forum, hehe.

Posted: Sun Mar 15, 2009 4:25 am

I wonder.. if its got something to do with subbing only a partial prompt? I don't want to have to match the entire prompt though, because I want to preserve the colouring without having to recreate the if statements and math that sets those colours in the first place. Also, there are bits of the prompt that appear/disappear in various circumstances, so I would need some help setting up the right regex pattern - which I don't really want to do since the only thing I actually want is that one simple substitution.

Posted: Mon Mar 16, 2009 9:35 am

Update: I was wrong, it only seemed like that script was causing it, though I am sure I am not imagining that it makes it happen more often.

I just had it occur twice with triggers off. I'm not using my friends packages at the moment, and in fact are only using a couple of my original ones.

#thread returns only the one thread (the main one). I don't use any of the multithreading commands anyway.. I don't really "get" that feature so I avoid them. (I think I mostly understand the theory, but I can't think of an actual use for them) At any rate, there doesn't seem to be any scripts running in the background on loops or similar. Nothing being called by the tick timer either.

So now I am confused. I'll try to narrow it down to a single package.

Posted: Fri Apr 10, 2009 3:55 pm

I did a fresh install of CMUD 3.05.
I imported a few scripts in, all from xml. Seemed to be going well. Then the bug reoccurred.
I then tried to narrow it down. Ended up removing all non-default packages. In the screenshot, I have selected "view default" from the menu so you can see exactly which packages are there, and also see the bug in action. I have clicked on the default package tab, which you can see highlighted, but the window continues to display the previously selected english directions module. I was connected directly to Aetolia (not using mudbot).

The only way (aside from restarting CMUD) to "fix" the bug and continue working, is to switch to the script debugging window, deselect the "Enabled" button, click on "clear" to clear the log, then select "Enabled" again. This means that while trying to reproduce this bug, the debug log remains small. The part I have pasted below is the entire thing.

I need help interpreting what I have found. It seems it is not a problem with a script of my own, since it is happening without any of my own scripts present. On the other hand, could one of my imported scripts cause the default package to become corrupted? Alternatively, it could be some problem with my windows installation.

I am not sure how to proceed from here. It is happening very regularly when I edit settings in the PE, and more regularly when I switch focus back and forth between main window and PE while entering commands at the command line. In my attempts to reproduce it today, it has primarily been with movement - though obviously when it occurs while I am working in the PE (as opposed to switching back and forth), its not being caused by the movement alone.