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

Enchanter Joined: 09 Sep 2007 Posts: 605

Well, this all started in 2.02, when I first sent feedback from within CMUD, but now I confirm it in 2.03.

After some point CMUD does not save any changes made to the settings in current session. You may edit whatever you want and all seems ok, but if you close CMUD and run it again (I never close session, only the application itself, since I play only 1 MUD with 1 character)... All your work is gone. There are no just added aliases, triggers, buttons... but there are some variables exists you've delete. I've noticed 2 new triggers that CMUD save, but after some investigations I realize that these triggers are modified versions of the old ones. In other words, you can edit old settings, but you cant delete them or add new.

I use the Package Editor to add/remove settings, not the command line.

When it first happened in 2.02, I reinstall CMUD completely and make the rule: if you want to add a setting, click on the class name, press "Add" button, give setting a name, press "Save changes" button. It all works OK until last session when I forgot to click Save, click on the other setting in tree view instead. Then I try to copy some settings, witout success though. (For what then Copy/Paste commands in tree view in Package Editor?) After all I have automapper crash, chose "close application" and... It happens.

I have all the files intact and can send them.

Posted: Mon Sep 10, 2007 8:42 pm

I haven't been able to reproduce this yet, but I've added it to the bug list. It's going to be difficult to track this one down since the saving is supposed to happen in a background thread.

Have you tried creating a new package file from scratch for v2.03? It's possible that there is something corrupted in your current package file from a previous beta version.

I can edit settings without using the Save changes button just fine here, so I'm not sure that's the problem.

Enchanter Joined: 09 Sep 2007 Posts: 605

No, I'm not tried creating a new package from scratch: I add new settings for 2 days and hope that another solution could be found. Although if I gonna use XML-import for this... Hmm... Can it be as temporary workaround? Edit anything I want, export to XML, close CMUD, run CMUD, import all from XML?
Back to the problem, about 2 days CMUD does not allow me to add/delete anything. Then I decide to walk around with automapper and make some maps, since maps stored separately. After being mapping for a while I noticed that CMUD begin accept new settings and even able to save them, although I still cant get rid of that nasty variable I want to delete as long as on Saturday!!! :)

Posted: Mon Sep 10, 2007 9:19 pm

Yes, you should be able to use the XML to Export your current settings, then create a new package and Import your settings into the package. That might help if there is something corrupted in the package. I think Export/Import is working now, but let me know if it doesn't work (create a new topic for any export/import issues).

What I think is happening is that the background thread that is responsible for saving your settings is crashing somehow. Usually this will cause an error message to be displayed, but there might be some weird case that doesn't display an error.

Enchanter Joined: 09 Sep 2007 Posts: 605

OK, I did it: create a new session and import settings there. Will not describe here how many crashes I see for the last 20 minutes. ;) Crashes on closing sessions, crashes right after XML was imported while new windows from imported file draws... Just say only 6th attempt was successful. And I'll definitely start a new topic on export/import issues later. :)

What can I say: the problem still exist in new package too. For example, I add 3 new aliases and delete 8 triggers. Save. Close session. Close CMUD. Run CMUD. Open session offline. None of those 3 aliases saved, and only 3 triggers actually deleted.

Posted: Mon Sep 10, 2007 11:48 pm

Post the XML or a small piece of it you know definitely crashes. This gives us something reproducible to work from.

Posted: Tue Sep 11, 2007 12:05 am

When was the last time you did a fresh install? That is, deleting the old files and installing into a fresh directory?

Also, how exactly are you creating a new package? What file/directory are you storing the package file? Also, you didn't mention what version of Windows you are using. But I cannot reproduce any problem creating aliases and triggers in a new package file.

Finally, what do you mean when you say "Save" in the above section (delete 8 triggers, "Save", Close session)? You shouldn't ever need to specifically Save anything. CMUD saves in the background and when you quit. So maybe the command you are using the Save is somehow messing something up.

Enchanter Joined: 09 Sep 2007 Posts: 605

XML file at first glance looks normally, nothing special... I'll look closer later on it and post if found smth.

Fresh install I did 9 days ago. It was first CMUD installation at all. I keep all session files in CMUD directory. Firstly I chose save settings in user Documents folder, but then first errors occured and I did full reinstall, in clean folder, with new settings files location. System Windows XP SP2. Package was created automatically, because I cant create new session without a new blank package (I tried to do so, but can't figure out how). Then I open session offline, open Package Editor and choose File->Import XML. It import all settings from XML, with all windows, including Main window. Yes, this results in two main windows co-exist within 1 session. I try to copy setting from imported main window to new one, but it cause a crash. Next time (yes, after each crash I create new clean session to make my tests on!) I keep old main window and delete new default main window. It seems ok, but it crashes when I try to save package in .pkg file. BTW, it was the first meaningful error info from CMUD for all time I trying to save imported via XML settings in new session: "Error saving data in background - Error resolving datasets : Access violation..." I've send this error, may be it'll help somehow.

Under Save I meant Save menu from Package editor. I even don't know ever this menu item implemented or it just a stub, but I must try everything to be sure I'm not miss smth important, right?

Ok, I'm gonna make clean CMUD install and watch for how long CMUD will keep its ability to save changes. Will report as soon as I have news.

Enchanter Joined: 09 Sep 2007 Posts: 605

Here is me report on clean install.
First of all, it not helps me, I still can delete any settings I want but can't save the changes!

Step by step:

0) Let's consider that I play MUD with name MyMUD, so the main window has title MyMUD. I have also 3 child windows (Talks, Gossips, Auction), originally created by #CAPTURE command and saved automatically later in package MyMUD.pkg, as long as any window considered by CMUD as setting too.

1) In Package Editor: File->Export XML (All) -> MyMUD.xml
2) Uninstall CMUD, put to archive all what left after uninstall, delete all folders.
3) Install CMUD with "Settings in CMUD folder" option.
4) Set r/w rights for this folder and subfolders to all users
5) Logon as common user.
6) Check CMUD folder properties - Full Access, ok
7) Run CMUD.
8) In Session window: New Session with name MyMUD (I chose the same name, why not?)
9) Open session offline, open Package Editor.
10) In Package Editor (PE) menu View->Show Default Packages.

OK, at this point I have 5 tabs under PE' menu: All, Default Settings, English Keypad, English Directions, MyMUD. In MyMUD tab there is no settings yet. In Default Setting there is Publish:Global option chosen and 3 unchecked packages (Keypad, Dirs and MyMUD) in the package list.

11) Switch to MyMUD tab and choose in PE File->Import XML, specify there MyMUD.xml. All settings imported OK, only toolbars all located above main window as there is no info in XML regarding their location (should this info also be saved in XML?). In PE menu File->Save (because help message in PE status line for this menu item says 'Force all changes to be saved immediately') and this is exactly I need at this time. Close PE.

Now, I have 5 windows opened: MyMUD (this window was created automatically when new session with name MyMUD was created), MyMUD (from XML file), Talks, Gossips, Auction. Well, having 2 main windows is a bit boring, so we try to delete default window, which we need no longer.

12) Open PE, choose tab 'MyMUD', choose in the tree view window with name MyMUD that have no associated settings. Right-click on it, choose Delete Setting. Crash. I confirm that this happens in 100% cases when I tried to work with XML files before uninstall CMUD. If I gonna delete main window from XML file and keep default main window, it results in another crash while moving settings from one window to another.

Well, I guess that default window CMUD does not consider as common setting, regardless what was sayed in documentation and how PE interpret it.

Anyway, even with crashes, one of 2 main windows finally junked. Only 4 windows left, as it should be in my case.

13) Open automapper window and load .mdb file I kept. Rearrange windows the way I like it.

14) Close session and open it again to be sure that all settings are in effect.

15) Window layout was not saved. CMUD did not create MyMUD.xly file, no matter what option selected in its View menu. Close and run CMUD several times show no effect, layout just not saved. I forced to take .xly file from archive and put it in session folder. After that CMUD found it and make layout exactly it was before uninstall. Strange bug, though.

16) That is! Open PE, choose variables, delete some... Close session, restart CMUD, open PE... All deleted settings at their places.

I dont know what else I should do to get rid of this bug? CMUD completely unusable with it, only as simple Telnet-client...

Posted: Tue Sep 11, 2007 6:13 pm

The toolbar information (for buttons) is saved, however on completely new install (like you set up) your toolbar preferences are not saved. Go to the Preferences for the Window and change them to what you want.

After you did a clean install, but before you did the import of the XML did you try modifying and saving changes? Doing that would ensure that the problems on the clean install but before any of your scripts are a factor. It would also eliminate your scripts as a problem.

Try that if it doesn't work, then we know it's a bug, if not we know it's something in your code that's potentially corrupted. In that case post the XML or trying importing it a portion at a time.

Enchanter Joined: 09 Sep 2007 Posts: 605

Enchanter Joined: 09 Sep 2007 Posts: 605

YESSS!!! It works, finally!!! Twisted Evil

Do not know how long it will work Mr. Green

hope everything should be ok now at the price of CMUD functionality.

I carefully studied all XML content and decide to edit (since I can't delete anything) my the only trigger that can send MXP command with tags. Here is it:

Wizard Joined: 14 Aug 2004 Posts: 1269

If this is the problem, good catch! I've got my fingers crossed for you too!

Posted: Wed Sep 12, 2007 9:22 am

I have been getting issues with settings not saving also; specifically new triggers and new records in a record variable not getting saved. Going into the package editor and manually saving seems to work. (Seems to because i cannot be sure it would not have saved anyway)

Newbie Joined: 06 Sep 2007 Posts: 5

I had this problem, but I had installed the v2.03 in a folder called CMUD203, while v1.34 was still installed in CMUD.

It seems like the Beta was still going back to the CMUD folder for package information, rather then where I installed it.

Kinda fixed the problem by removing every version of CMUD I had installed, installing only v2.03 in the default place, and let it run from there. Sometimes, however, I close the settings window and exit the program, come back and see several items I had previously deleted still around. I can't explain why it would still happen, but I haven't had any settings last through more then two deletes.

Enchanter Joined: 09 Sep 2007 Posts: 605

As for me, everything runs smooth so far! I just avoid write any MXP-related triggers and periodically check XML. :)

Enchanter Joined: 09 Sep 2007 Posts: 605

Have add this simple trigger:

----------------
pattern
strange triangular shaped token

script
play_magic;
#ECHO "^^^^^^^^^^^TOKEN!!!!^^^^^^^^^^";
#ECHO "^^^^^^^^^^^TOKEN!!!!^^^^^^^^^^";
----------------

play_magic is an alias for playing .wav file.

Export all settings to XML-file and look it through - this trigger is enclosed in CDATA tags.
Delete last line and type it from keyboard again, export to XML - no CDATA...

Hmm... Shocked

Newbie Joined: 06 Sep 2007 Posts: 5

Because I am currently plagued with this problem, let me add a few more observations. If there's an easier way to test these ideas, please, tell me.

In cMud 1.34, you couldn't edit a trigger, alias, macro, or any other setting if it had fired (been used) while you were editing it. When you tried to save, the 'save changes' button would stay green, and if you selected another setting and then selected the setting you were trying to edit, it would revert to what was last presented.

In cMud 2.03, that doesn't happen. At the same time, it seems like whenever I edit my settings while triggers are on, nothing actually gets saved. I'm forced to sit somewhere quietly, turn off the client's ability to activate triggers (the gun icon in the lower right corner of the window, just right of the command line), and then do all my settings editing.

Posted: Tue Sep 25, 2007 6:47 pm

Exactly what are you editing that isn't getting saved? Is it a trigger that is firing, or an alarm that is firing, or what? I cannot reproduce any problem with editing settings while triggers are firing in v2.03. In fact, that was one of the problems that happened in 1.34 that was *fixed* in 2.03. So if it is still happening, then you might want to create a new forum topic to give the exact steps that you are using and exactly what is running in the background that is messing up the saving.

But that problem is different than what the original poster is reporting, so please create a new topic. The original poster is talking about a different problem where changes are never written to the package file in the background.

Enchanter Joined: 09 Sep 2007 Posts: 605

Aaarrrghhhh! Its happened again, a day ago. Evil or Very Mad

May be I could miss that fact, but yesterday I've add a big red button and didn't find it today, along with several new triggers.

Now, after I have read the post from lvmwrah (thanks a lot, lvmwrah!!! your post gave me new info to think about) I believe that there are two types of this bug exist.
First of it was that bug I fought two weeks ago. Somehow, appearance of CDATA tag in XML file for no obvious reasons indicate that some settings may be lost. It is not a problem with CDATA tag itself as it's the standard tag. The application should know when to use it and when not use, it must have some strict criteria. It appears that current version have different algorithms and can act one or another way for the same source data, see my previous post with simple trigger sample. The only solution for me is to check if CDATA tag present and, if any, ask CMUD "make another decision" by edit Script or Value fields.
Second type, mentioned by lvmwrah, I've see yesterday and confirm it. I check all settings and found that lost triggers and button was created while I play MUD. All settings I've create before connecting to MUD and right after I disconnect from it are in place. So, in this case it cannot be explained by "saving thread was terminated before it can save something". It did save in begining and in the end application' run, but failed to do that in the middle.

I have no idea how to reproduce this bug. Zugg, could you add some sort of internal log, in which saving thread will write messages on all write actions? Like [01:23:46] save setting: Trigger pattern:^<(*) result: ok

P.S. Creating that red gauge button with mxp-variable reveal a problem with screen flickering, but Im not sure should I report that problem? Reading forum I've got an impression that many peoples already aware of it...

lvmwrah, can you tell me, do you have any CPU-intensive tasks running in the background?

Posted: Tue Sep 25, 2007 9:18 pm

Posted: Tue Sep 25, 2007 10:40 pm

I'm not sure the CDATA problem is causing this, unless it's some problem with having the Settings Editor in the XML tab view when stuff happens in the background.

One thing that was added to v2.0 is the #NOSAVE command and flag. Normally this is just used for variables that have the Use Default option set. But I wonder if somehow your triggers or buttons are getting marked as "nosave".

If you can reproduce a case where something isn't being saved while you are connected to the MUD, try using the #NOSAVE command on it, like this:

#NOSAVE TriggerID 1

where "TriggerID" is the ID of your trigger (or button). The 1 tells the NOSAVE command to start saving the setting again in case it was marked as no-save somehow. That's the only way I could see that something might not be getting saved even though the background thread is still working.

I'll also take a look at trying to create some sort of log file to see if we can track this problem down.

Arde: It would also be useful to know more about your settings. For example, are you using multiple sessions, or multiple modules/windows/packages?

Posted: Wed Sep 26, 2007 7:23 am

For myself i was using <color X> tags in the status window; removing all the colours started things saving again just fine by themselves. There was CDATA in the xml which made me try removing it given what others said above.

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

I remember something that was causing similar problems now that I re-read this post.

After the last XML re-write Cmud no longer knows how to handle some control characters. I think it was the taking out of the CDATA tags... I had a variable that had control characters in the default value box.

I exported the XML took out the control characters, searched the text for more of the same and deleted any I found, then deleted the package and re-imported the xml. Finally saving started working again.

No I'm sorry I don't recall what those characters were, but it was a default value for a database variable. It is possible I have an old package that I can send in at home but I will be leaving town right after work and gone into the night. I'll see if I can reproduce this at work.

I hate giving bad bug reports but maybe this will help fix the problem.

As for the xml tab being open. It was not. In fact I have been completely unable to edit any of my settings in the xml tab. This is why I resorted to the export, change delete, import mentioned above.

Posted: Wed Sep 26, 2007 1:49 pm