Zugg Software :: View topic - [2.20] Variables reverting back to previous values.

Posted: Sat Mar 22, 2008 12:10 pm

I'm seeing that the values set by Cmud in the course of playing the Mud often aren't being saved when I exit, despite the fact that I explicitly open the settings editor and do a save. I'll come back into Cmud the next time and find many values reverted back to a former value.

Am I missing some location I need to hit save other than the settings editor save?

Posted: Sat Mar 22, 2008 12:33 pm

Nope. You shouldn't even actually need to hit the settings editor save, because it saves in the background. My guess would be a Vista (perhaps virtual store related) permissions problem. It's possible, I suppose, that something is silently crashing or holding the background package saving thread and preventing it from saving, but I have no idea what that might be.

Posted: Sat Mar 22, 2008 12:39 pm

Windows XP SP2

Posted: Sat Mar 22, 2008 12:45 pm

Also, this is only with the values of variables. Triggers are always exactly how I left them. Additionally, if I edit the variable through the settings editor things stick around. It's when the value is set through scripting during actual mudding that the values fail to stick.

Posted: Sat Mar 22, 2008 12:55 pm

you didn't accidentally set them to use default value did you? or have a second instance of them somewhere?

Posted: Sat Mar 22, 2008 1:45 pm

Response to Shalimar's questions: No, and no.

Posted: Sat Mar 22, 2008 2:13 pm

I was looking at this a bit more and noticed that if I change the variable and exit, I can reload cmud and do an off-line load (instead of choosing connect) and the variables will be the latest. Once I use #con to connect I see them revert back to a previous state. I checked through for something that might be causing this or modifying them on a connect, but couldn't find anything.

Posted: Sat Mar 22, 2008 2:21 pm

Sounds like something has set the nosave flag for those settings, in that case. Try using the #nosave command to re-enable database writes for the settings that aren't working and see if that helps.

Posted: Sat Mar 22, 2008 4:45 pm

If you can narrow this down to a small test package then maybe we can try to reproduce it. But there isn't anything about #CON that should change your variables, unless you have an event firing on the OnConnect event. I'm not sure the #nosave command would cause this kind of behavior.

Posted: Sun Mar 23, 2008 1:26 am

Try this:

1) Create a named blank named session that you can reload later.
2) Load it off-line and go into the settings editor.
3) Create a test variable @test as a db variable with the values: one=1|two=2|three=3.
4) Save the package.
5) Exit Cmud, Load Cmud, load the session off-line.
6) Execute #addkey test two two
7) Exit Cmud, Load Cmud, load the session
8) Verify that test variable reverted to its previous setting.

I tried this a number of ways including opening the settings editor and selecting 'save' (which didn't work). I discovered that the only way to keep the value was to not only open the setting editor, but to actually view the variable in the settings editor and then save.

My suspicion is that the change exists only in memory and isn't being written back to disk. Viewing the variable in the settings editor somehow causes it to be written back to disk, but otherwise it seems to vanish from memory without being written when you close.

Posted: Sun Mar 23, 2008 1:32 pm

The #con thing I mentioned turned out to just be a red herring. I was reading the variable state off of buttons and the buttons updated their state when I did a #con, thus them changing... when in reality it was just them changing to reflect the current values.

So ignore the at connection thing, the real issue is that they don't stick around after you close unless you view them in the settings editor as I outlined above.

Magician Joined: 23 Nov 2004 Posts: 364

I've had this problem as well, using windows xp sp2 too. I'm thinking it only is affecting db variables. I don't really have a set way to reproduce this, but for example:

Posted: Mon Mar 24, 2008 2:35 am

I'm fairly certain it is just an oversight in writing the changed values of db variables to disk. It is fairly straight forward to follow the procedure outlined (in my post above) to reproduce this. From what I see this is only db variables.

Posted: Mon Mar 24, 2008 4:27 pm

Added to bug list.

Posted: Sat Mar 29, 2008 2:14 pm

I saw from the 2.21 change log that an item similar to this with #additem was fixed. The fix didn't affect this bug as I can confirm it is still present in 2.21.

Posted: Sat Mar 29, 2008 5:45 pm

I used your test procedure that you gave above (with the #ADDKEY test two two) and I can no longer confirm this bug in 2.21. Your test *did* cause problems in 2.20, but I cannot get it to fail now with 2.21. So I either need a new procedure, or it is something corrupted in your settings file.

Posted: Sat Mar 29, 2008 11:37 pm

I just tried this with another clean package.

1) Create a new package which you can save and load back.
2) Open the settings editor and create a variable "test" with a key of two and a value of 2.
3) Save the package and exit Cmud.
4) Load Cmud and enter back into the saved package (do not open the settings editor).
5) Without opening the setting editor modify the value of the "test" variable by typing "#addkey test two two" at the command line
6) Exit Cmud (Not having opened the settings editor)
7) Reload Cmud and verify the variable didn't save.

I tried this with an auto-type variable and can confirm that it saved that variable. It seems only to be with a db variable and only when you don't open the settings editor. In my tests when I opened the settings editor it *would* save. I'm not sure whether it was the act of opening the settings editor or whether you have to view the variable in the settings editor for it to save, but since I only had one item in the settings editor it always did both if I opened it.

Posted: Tue Apr 01, 2008 5:58 pm

Still no luck reproducing this I'm afraid. I tried your exact instructions and when I reloaded CMUD in step 7 and went into the settings editor, it properly showed a key and value of "two".

How exactly are you creating the package and loading it? I created a session called "test1" and then created the variables, and in step 7 I clicked Open Offline to open the package. Maybe your exact steps were different? It's very important to post *exact* steps for bugs like this that are hard to reproduce. This procedure that you just posted is the same as the previous procedure that I already said I couldn't reproduce.

Posted: Wed Apr 02, 2008 9:02 am

Sorry if these look similar, since it never saves for me I'm grasping at straws on what else to tell you here. I've created a more detailed step-by-step explanation below. If this doesn't do it it must be something in my settings. Perhaps I accidentally selected the disregard my db variable changes button or some such.

Perhaps you can spot something you did differently in the details below:

1) Create a named blank named "Test" that you can reload later.
1a) Delete the pkg file and the backup pkg file for this in the directory it created (if it exists). I'm just making double sure there is nothing there to start with.
2) In the session load screen right click "Test" and select load off-line.
3) At the command line type "#addkey Test one 1".
4) Verify the value with "#say @Test". Output should be "one=1".
5) Under the File menu, select "Close Session".
6) In the session load screen right click "Test" and select load off-line.
7) Repeat step 4: Look at the value of @Test with "#say @Test". In my tests you now get a blank output indicating the value it was set to was lost.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

Using the steps in the previous post, I was able to reproduce this. Maybe CMUD just doesn't save the settings when closing the session?

Posted: Wed Apr 02, 2008 2:24 pm

Looking at this a bit more there are a lot of variations that produce weird results. For example, it varies the results if I open then close the settings editor before I modify the variables at the command prompt. It gave me mixed results. Sometimes it keeps the new value, sometimes it doesn't. Very odd and very inconsistent.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I'm guessing that it's a matter of timing: sometimes the app has time to save the settings before they're closed, and sometimes it doesn't get to it.

Posted: Fri Apr 04, 2008 11:07 pm

I was *finally* able to reproduce this. The key was that you were using "Close Session" to exit the session, where-as I was exiting CMUD completely and reloading it. That's exactly the kind of detail that really matters. It was a bug in the Close Session that wasn't saving the value. Should be fixed in 2.22.

Edited: Also, there *was* a timing issue here. When Close Session was used, it was calling the background Save thread, but it wasn't waiting for it to complete. Meanwhile, it would destroy the current window/module being closed, so that when the background thread started saving, it couldn't save anything because the window was gone. The same problem could occur when closing a window...the settings in that window might not be saved. All I had to do was add my "Wait" flag to force it to wait until the save was done before destroying the window.

Posted: Fri Apr 04, 2008 11:52 pm

Ah very nice. Thanks for fixing that!

How were you normally closing your window down? Normally I use the upper right red "x" or "file->close" to close, but in this example I used close session for the heck of it.

Posted: Fri Apr 04, 2008 11:57 pm

Yep, I was using the "X" in the upper-right corner. And that *was* waiting until the background save completed.