Zugg Software :: View topic

Posted: Thu Aug 20, 2009 6:58 am

I find some settings that are changed from script (or by hand) recover their old value. Changing it by hand will "work" until I move away from the setting. Looking again at the setting shows the old value. This is not an illusion (a bad display) because scripts react to the setting. The only way to stop this is to delete the setting and recreate it. this problem is persistent though I have no way of telling when it begins. Sometimes, the setting behaves normally but some time during the session it begins to behave as I describe. I only realize the problem is back when my scripts start misbehaving. This also applies to enabling/disabling, though in this case there is no need to move away from the setting to see the problem. Unchecking the enabled flag on a trigger will sometimes show that, according to the treeview, CMUD thinks that the trigger is still enabled, even though the box is unchecked. Then, moving away and back from the setting will show that the box is now again checked. I've been trying to figure out the problem for some days now without success.

Posted: Thu Aug 20, 2009 4:25 pm

You will need to give me a specific step-by-step procedure for reproducing this. I've never run into this problem, so either some trigger is running in the background while you are editing that is causing confusion, or something else is happening. But you'll need to pin this down to something the rest of us can try or else we don't be able to help with this.

Posted: Fri Aug 21, 2009 12:43 am

It is precisely because triggers didn't fire that I discovered this problem. The setting in question is a flag that tells an invoked script whether I should enable a set of triggers or not. When I looked at the flag, it was in the wrong state and I assumed that it was my mistake. So I reset it. Went back to look at it again and it was again set. This went on and on until I finally deleted the flag and created it again. Then it stayed put when I reset it. This happens every session, more than once. It also happens that disabled triggers stay enabled. When they start doing it or why they are doing it I have no way to tell. I'v looked at the package file and it shows that the state of the trigger is enabled even though the checkbox is unchecked which is why the treeview shows the trigger as enabled. Same with the pesky flag, even though I am looking at the setting and it has a 0, in the settings file the value is 1, which explains why going to another setting then coming back to the flag setting shows that the value has been "restored". This problem is not new (I didn't just notice it) . I am posting because I don't know what to do about it. Unless you can instruct me on how to develop some "onvaluechange" event, I don't know how to track this problem.

EDIT: I just attempted the following: A trigger that I tried to disable remained enabled, so I cut/pasted it. This caused an access violation and the setting disappeared, the pasting operation didn't take. However, pasting the setting to a text file showed that the XML was on the clipboard. CMUD just won't perform the paste operation.

Wizard Joined: 22 Mar 2007 Posts: 2320

I have seen similar things happen when my package gets messed up. To fix it, I usually have to export and import the settings anew, checking that everything gets imported correctly.

Posted: Fri Aug 21, 2009 2:41 am

Re-starting CMUD restored the balance. Either procedure to fix the problem, yours or mine, is a bit drastic IMHO. I suspect that this is linked to some package file I/O operation done by CMUD, where it thinks that it has updated the database and for some reason the update fails causing the old value to be "restored" next time one accesses the setting.

Posted: Fri Aug 21, 2009 3:57 pm

I assume that after restarting CMUD, if you paste the above XML into your session then it works fine? I pasted it here and it worked.

The crash dump that you gave shows that the memory stack is completely corrupted. It's just showing a bunch of Windows system event calls and nothing in my actual source code.

So something in one of your scripts is causing a severe memory and database corruption at some point during your playing. It is going to be very difficult to track down the actual cause of the problem.

You might create an alarm trigger that runs every 10 seconds or so and checks your triggers to see if the one that fails gets disabled suddenly. Then you can print a message as soon as it happens (or within 10 seconds). And if you play with the Script Debugger open, then you can look at the past 10 seconds of activity and see which trigger or other script was running.

Also, when you said "this problem is not new", can you confirm that this problem happens in the 2.37 public version? I want to rule out any changes related to the new mapper and database formats.

Posted: Sat Aug 22, 2009 2:07 am

Sorry, by "not new" I meant that it has been with 3.10 since the beginning. I didn't have this problem in 2.37 or any of the prior BETA versions.