Zugg Software :: View topic - [2.13 - 2.14a] Button states wiped out from the package

Enchanter Joined: 09 Sep 2007 Posts: 605

This is really driving me insane. I have a problem with button states in my primary package.
After installing 2.13 I opened my session offline, checked what's new in it, closed CMUD, ran it again and opened my session. All buttons that had any additional states have lost them completely. That includes state info, associated script - everything within <state> tags in xml view. Here is an example.
Before:

Posted: Fri Nov 23, 2007 3:34 am

I tried this with an empty session and it works just fine for me. Is it only happening in one package file?

Enchanter Joined: 09 Sep 2007 Posts: 605

Yes, it is only happening with my package.

Firstly I wrote that this happening while 2.13 is saving settings from 2.12 and never happens with newly created states. But after I found that even new states not get saved every time in my package.

Enchanter Joined: 09 Sep 2007 Posts: 605

I can add that if I use "Export to XML" command of PE before closing of CMUD, my package saved properly. I tried 6 times in a row (and even got 1 crash while trying) but nothing happened.
Next, I tried closing CMUD without exporting to xml and "successfully" lost buttons state info from the second try.
Something is definitely happening with settings saving on CMUD exit.

Posted: Mon Nov 26, 2007 4:54 pm

If it's only happening in one of your packages, please email me the *.PKG file to sales@zuggsoft.com so that I can try to reproduce this.

Enchanter Joined: 09 Sep 2007 Posts: 605

I sent it.

Posted: Mon Nov 26, 2007 6:21 pm

OK, thanks, I got it.

Enchanter Joined: 09 Sep 2007 Posts: 605

I just tried it once more and I've got partial states loss. Some buttons lost their info on other states while others keep it intact.

Enchanter Joined: 09 Sep 2007 Posts: 605

Still the issue in 2.14a. At least for me.

Posted: Mon Dec 03, 2007 5:50 pm

Yep, sorry Arde, but I didn't have time to get to this bug yet in 2.14. Hopefully this week.

Enchanter Joined: 09 Sep 2007 Posts: 605

Zugg
Heh, you have answered while I upload images for this thread. Smile

Anyway, I hope this will help:

=====

I've got pissed off with this bug preventing me from writing any scripts for several weeks now, so I decided to go and check something else, for example, my old bug report for v. 2.03 that Editor does something wrong while edit button states. But right after I've start with the Editor, I find what I believewas a relative bug, now in the untitled package. The procedure is quite long because we need to create 2 multistate buttons with several states (one regular and one bugged for comparision) and make them from the Editor.

Originally the main objective of my test was to check this Zugg reply:

Novice Joined: 31 May 2007 Posts: 32

My button states have not come over perfectly clean either. However, they all work properly and when you are in your main window and click a multi-state
button, the drop down list shows everything correctly. Within the editor it is different.

Here's an example:

<button type="Multistate" autosize="false" toolbar="3" priority="3" id="771">
<caption>Corpse Options</caption>
<state caption="Sacrifice">#t- auto_decap
#t+ auto_sac
#t- auto_skin
#t- auto_butcher
#variable corpse SACRIFICE</state>
<state caption="Skin">#t- auto_decap
#t- auto_sac
#t+ auto_skin
#t- auto_butcher
#variable corpse SKIN</state>
<state caption="Butcher">#t- auto_decap
#t- auto_sac
#t- auto_skin
#t+ auto_butcher
#variable corpse BUTCHER</state>
<state caption="Nothing">#t- auto_decap
#t- auto_sac
#t- auto_skin
#t- auto_butcher
#variable corpse NOTHING</state>
<state caption="Decapitate">#t+ auto_decap
#t- auto_sac
#t- auto_skin
#t- auto_butcher
#variable corpse DECAP</state>
</button>

Should show up like (and does in the main window):

Corpse Options
Sacrifice
Skin
Butcher
Nothing
Decapitate

However, in the editor window, it shows up like:

Corpse Options
1:Decap ON
2:Decap ON
3:Decap ON
4:Decap ON
5:Decapitate

But, each option executes the proper code. And the Caption box for each selection shows the correct "state name" that I want. It just doesn't
show up in the tree on the left when you expand the multi-state button.

When I loaded 2.14, I uninstalled 1.34 and 2.13 (was running side by side). Installed 2.14 into main CMUD directory and started.
The sessions showed up as is and I ran from there.

After I discovered this issue, I deleted the sessions, created new sessions and imported the XML that I created before I installed 2.14.
The button states did not import very well from that XML file. None of the button states were attached to the main button. Instead,
it created individual buttons for each multi-state option. And again, in my editor, they showed up like above.

Creating a new multi-state button creates it like it should.

Posted: Mon Dec 03, 2007 11:04 pm

Arde: I'm having a problem with your procedure:

3) New->Button (Name: TestButton, Script:#SAY TestButton), Save Changes
4) Change button type to Multistate. Click Save Changes now!

As soon as I click Save Changes in step 4, CMUD properly creates the first state of the button and shows "1:" in the tree. So you don't need to select Add Button State here. If you select Add Button State, then you get a second "2:" button state.

So, I cannot reproduce your steps for button bug type a.

I *did* reproduce your "bug type b" and have added that to the bug list.

Ardwick: I reproduced the display bug in the tree view using your button XML and I have that fixed for v2.15.

Posted: Mon Dec 03, 2007 11:11 pm

OK, bug type "b" should be fixed now in 2.15.

Edited: OK, I have also found the problem with getting the new child state added first instead of last.

Several of these bugs required that the package editor be "filtered" by clicking the Buttons button in the main toolbar, rather than just pressing Ctrl-G to open the settings editor. So it's always important to note exactly how you open the settings editor.

Enchanter Joined: 09 Sep 2007 Posts: 605

Posted: Tue Dec 04, 2007 10:58 pm

OK, I tried your Sloth.pkg file in v2.15 and I cannot get it to fail. Everytime I load it all of the buttons (including the btnActAutoTgt shown at the beginning of this post) look and work fine. I tried going into the Prefs and changing the Pueblo flag on and off and then exited CMUD. When CMUD was reloaded, the buttons were still all fine.

Unfortunately I cannot reproduce the data loss that you are getting. Even though I've fixed the various bugs with the Package Editor and how it displays the button states, I don't think any of those really have any effect on the button state loss (because the settings editor is never even opened in my tests).

So, I either need a more complete, step-by-step procedure for getting this to fail, or I'm probably not going to be able to fix it.

Enchanter Joined: 09 Sep 2007 Posts: 605

There is no procedure, Zugg. Or, the procedure is:
1) Open CMUD
2) Load the package (open session offline)
3) Close CMUD with red cross

This is the shortest procedure that may cause the buttons to loose their state info. I have no instruments to catch what is happening. If someone can suggest how I can track changes in real-time - you welcomed.

Next, if buttons don't want to loose their states from the first or second try, I usually perform very simple activity while in offline session. That includes clicking on different buttons (push, toggle, multistate) 10-20 times, opening of the Editor window, opening of the Debugger window. That's all. I left at least 1 toggle button in pressed position, multistates in some state (I have variables to track button states between sessions). Then I close CMUD. I need no more than 2 CMUD restarts to get buttons with lost states. So again, I can't determine what causing this bug to appear. Sorry, Zugg. Sad

===
About packages tag - I just wondered why you are using "window", "button", "module", but "packageS". There is no problem with it. I've forget that there is a list of several packages should be.

Enchanter Joined: 09 Sep 2007 Posts: 605

Does buttons info forced to save at the session close (CMUD exit)? I've see that buttons with changing captions recompiles each time I press them, therefore CMUD considers them as "edited", therefore CMUD must save all changes to settings in the end. How it handles the case when a button left in pressed position? Does state info actually gets to database or lost somewhere?

What I can suggest else is to send you 2 packages: original package and the package after this bug has happened. May be there is everything fine with the package, but CMUD somehow fails to read it?

My last suggestion for you to make a quick release 2.14b with fixed bugs for buttons editor. May be they are related, after all...

Posted: Wed Dec 05, 2007 6:35 pm

Enchanter Joined: 09 Sep 2007 Posts: 605

I can't force this bug to show up today! Confused

Will try later again.

Wizard Joined: 17 Jun 2006 Posts: 1201

Well this bug is REALLY on my last nerve. I've exported and reimported XML and even reinstalled CMUD completely. Yet when I close CMUD after adding something and then the next time I reopen it the button states all vanished.

I can't wait for 2.15 tomorrow.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

The bug looks to actually be an interaction between the XML view of a button and activation of the button. The also something specific about using a session versus the untitled with this bug.

Procedure
1. Launch CMud
2. Create new session with name of 'test'
3. Open 'test' session offline
4. Open Package Editor (CTRL-G)
5. Left click in tree panel
6. Paste button in

Posted: Thu Dec 06, 2007 2:57 pm

Thanks for the procedure Vijilante!! I was able to reproduce the bug using your procedure. It really is a tricky one. After it failed to save, I added the button again and it *did* save the second time. Anyway, hopefully I'll be smart enough to figure out how to fix this today before 2.15 is released. If it wasn't for your procedure, I would have never found this one.

Posted: Thu Dec 06, 2007 3:59 pm

Found it!

OK, this was a really nasty one. When CMUD closes, it deletes all settings from memory. If the background SQL updater thread was still running, then it could detect these deletions and write them to the *.PKG database file. The timing had to be exactly right for this to happen. I'm not sure what exactly about Vjilante's procedure caused this timing to happen every time, but it did.

In 2.15 I properly terminate the background updater thread *before* clearing all of the settings from memory, and now this bug seems to be fixed.

The reason it only effected button states is that when settings are deleted from memory, most settings have already deleted the internal database cache first, and has marked it so that this doesn't propagate to the disk database file. But when a Button is deleted, it loops through it's button states and deletes them from the internal cache, and these deletions were not getting flagged as temporary, so these changes could get saved to the disk file.

So, very obscure...only effected button states and had to have the timing just right.

Enchanter Joined: 09 Sep 2007 Posts: 605

Nice, Zugg!
And what a pity that Vijilante didn't drop in here earlier! Wink

Thanks for excellent procedure!