Zugg Software :: View topic - [2.03] CMUD neither save new settings nor delete old ones

Enchanter Joined: 09 Sep 2007 Posts: 605

I confirm that settings created while connected to MUD is not saved at all. Just connect to MUD, add a gauge, some triggers and variables. Disconnect from MUD. Edit StatusBar content. Close session, close CMUD. Run CMUD. StatusBar saves all changes. All other newly added settings have gone without a trace.

And I mention earlier text flickering bug - I failed to reproduce it, although I've repeat all steps. Sad

Another hard-to-find bug.

Posted: Wed Sep 26, 2007 5:14 pm

You definitely should not store raw control codes within any settings field. These can likely cause problems with the SQL text that is generated to save records to the database. If you need a control character, use the %char() function instead of a raw character. Or, for ESC use %e and for CR use %cr and for LF use %lf.

The way the CDATA is "supposed" to work is that first CMUD tries converting angle brackets < and > to < and > If the length of this new value is more than 10 characters longer than the original string, then CMUD converts the string to a CDATA string instead. So, it depends upon the number of angle brackets as to whether or not CDATA is used.

But I can't think of any reason why this would effect the background saving. The CDATA stuff is only used for XML export/import. None of the XML stuff is used for the saving in the SQL database itself. I can see where control characters might cause the SQL save to fail, but I can't see where extra angle brackets would have any effect.

Enchanter Joined: 09 Sep 2007 Posts: 605

Heh, Zugg answer almost same time than I. Just pull this topic on top in order to Zugg read my post

Posted: Wed Sep 26, 2007 5:36 pm

Enchanter Joined: 09 Sep 2007 Posts: 605

I add new settings in the settings editor, not from the command line.
What I tried to check:
1) Clean session, all triggers are off. Add/save everything - OK.
2) My session, all triggers are off. Add/save everything - OK.
3) Clean session, all triggers are ON. Add prompt trigger/parser. - OK
4) My session, all triggers are ON. MXP prompt parser ON (currently, it only send #TAG prompt command, I plan to add more commands to it later). Add/save everything - OK
5) My session, all triggers are ON. Old-style prompt parser ON. Triggers fires, passive (just parse info from MUD: set new values to variables, capture lines to other windows) and interactive (send commands to MUD, like eat/drink, etc). Add/save everything - OK.
6) I turn back ON MXP prompt parser.

7) Now I decide to do a trick. I repeat some steps from my previous post.
a) My statusBar (currently I use it for scripts debug, displaying variables values, so here dirty and ugly expressions) shows my unused experience points stored in @CurrEXP variable. While online, I change this value to MXP variable %mud.CurrentXP. Add some triggers while all other triggers are continue to fire as it was in 5)
b) Disconnect from MUD
c) In offline mode edit statusBar back to use of CMUD variable @CurrEXP.
d) Close session, close CMUD. Run CMUD. StatusBar save my changes, but all other changes have gone.

Just for information - here is what my StatusBar expression looks like:
MXP: @CurrEXP *CharState: @CharState

I must point that yesterday, when my screen starts to flick (and I also lost all changes), I've made the same changes: %mud.CurrentXP instead of @CurrEXP.

Ok, what else I should report about?

Enchanter Joined: 09 Sep 2007 Posts: 605

I repeat step 7 in the clean session. Everything looks normal there...

Posted: Wed Sep 26, 2007 7:27 pm

Let me make sure I understand...

In steps 1-6, were you connected to the MUD. When you say "OK" do you mean that you were connected to the MUD and then closed CMUD and then ran CMUD again and everything was saved properly?

I'm trying to understand what the difference is between step (5) (which you said was OK) and step (7). Looks like in step 7 you just edited a status bar item, but somehow the triggers that you saved are gone?

What happens if you make some other change to your status bar? In other words, does it only happen when adding %mud.CurrentXP, or does it happen when making any other change?

In step 7d you say "Close session, close CMUD". Does it make any difference if you just close CMUD without first closing the session?

Enchanter Joined: 09 Sep 2007 Posts: 605

Posted: Wed Sep 26, 2007 9:45 pm

Enchanter Joined: 09 Sep 2007 Posts: 605

I can't reproduce it any more. Sad

But for your question - yes, it was so: adding variable or anything before changing the st.bar saves that variable normally. I just make 2 tries - everything was saved, regardless of what I did with status bar.
Same thing was with buttons editor - I can't reproduce later one of the bugs I had previously. Looks like something must happen before these bugs get active.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

I stand corrected, I AM able to make changes in XML in 2.03.

Thanks Zugg, I'll remember to be good and use %char %e %cr %lf in the future.

I just thought that since the behavior sounded similar it might be somehow relevant. It's been a long day I'm off to bed.

Enchanter Joined: 09 Sep 2007 Posts: 605

Posted: Thu Sep 27, 2007 7:27 pm

There isn't any "Editor -> DB converter". The contents of the Script field in the Editor is sent directly to the Value field in the database via SQL. The only "conversion" done is to double any quotes in the script to make it into a value SQL value. XML is not involved at all in the database. A failed SQL transaction in the background saving thread already will cause an error message to be shown. So the SQL isn't the problem here...there is something else happening.

I don't know why it's using CDATA for the cases that you show. I can confirm that it is using CDATA when it shouldn't, and I'll look at the code to see why it is doing this.

The normal conversion for XML is to convert a < character to a "amp lt semicolon" < and a > character to "amp gt semicolon" > ... No "slashes" are involved. I updated my above forum post to make it clearer (the forum bbcode was messing it up a bit)

I'm still going to do some more testing myself to see if I can reproduce the problem. If not, then I'll add a logging function. But since the logging will be done in a background thread, all I can do is write it to a file. I cannot display it in any kind of user interface (since that can only be done in the main thread).

Posted: Thu Sep 27, 2007 7:50 pm

OK, the reason it is using CDATA in your cases above is that it was also trying to convert the " quotes into " and that was triggering the CDATA conversion. Still doesn't explain why it isn't saving stuff yet, and why it matters whether you are online or not, so I'm still looking into that.

Enchanter Joined: 09 Sep 2007 Posts: 605

Heh, I have a lot #SAY "blah-blah" or #ECHO "blah-blah" quoted commands in triggers, but they never get enclosed with CDATA... And I was cursed with "cant save" bug for a week until I get rid of one variable with CDATA tag around its value. I delete only that variable, but all start to work. May be it's not explained anything, or may be it does - I wish I know it...

Posted: Thu Sep 27, 2007 8:29 pm

Found it!

At least, I found one of the problems. It was related to deleting settings. Arde sent me his XML file and indicated a variable that he could not delete. I imported his XML and tried to delete the variable and had the same problem. When I traced the background thread that was saving the SQL, it was crashing when trying to access the deleted setting. The database record was marked as deleted, but the cached record in memory was already freed. So when the background thread tried to access the cached record to check a property, it was getting an access violation and crashing the background update thread.

This particular crash wasn't being caught by the background thread error handler. So what was happening is that any setting stored *after* the deleted setting in memory wasn't getting updated on disk (because the thread would crash at the deleted setting and never get to the ones after it). So this depended heavily upon where the deleted setting was in the database. And certainly any *new* settings (which get added to the end of the database) wouldn't get saved. But editing a setting *before* the deleted setting would get saved properly.

The reason you sometimes couldn't reproduce it is that you needed to try deleting a setting first. Once you had deleted a setting, then this would trigger the problem to start occurring.

I believe that this happens any time you delete any setting. So this would definitely make it really flaky when trying to save changes to your settings, and it would effect a lot of people. So I think this bug is responsible for most of the problems with saving changes to settings. I have also modified the background thread so that something like this will properly trigger the error handler in the future.

This is a very serious bug and really makes it impossible to use v2.03 for any real playing or testing. This bug has been in all of the 2.0x versions, so it is probably responsible for a lot of the problems people are having.

I'm going to work on the problem with the screen going blank and MUD output not displaying, since I think that is also a serious problem. Then I might release a new version tomorrow with these major fixes just so people can do more productive beta testing.

Arde: Thanks for your patience in all of this. I know it was a tough and frustrating problem to work on.

Enchanter Joined: 09 Sep 2007 Posts: 605

SMASH that bug, Zugg! Mr. Green

Posted: Thu Sep 27, 2007 8:32 pm

Wizard Joined: 14 Aug 2004 Posts: 1269

Nice one, Zugg!