Zugg Software :: View topic

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

I'm having an increasing amount of difficulty with my settings in 2.21. I've seen entire class folder structures disappear, which causes my aliases to suddenly get sent as commands to the MUD because they're just not there any more. I've also seen commands like #T+/- fail when using the full path "//Module/Class1/Class2" and work when I changed it to just "Class2." (The class folder is in the module executing the command, too, so it's not a matter of cross-module scope.)

When I import scripts, I paste the zScript in the command line, and I like to do a #DELCLASS before I create new settings, just to flush out the old stuff first. Well, I've been deleting class folders in other modules, apparently. I use a common naming scheme for my folders to make it easier to find things later: Interface, Internals, Tracking, GUI, etc. The "//Module Name/" part of the path seems to be stripped out in some cases, thus wiping out a folder in a completely different module.

This is frustrating not only because I'm losing settings fairly often, but also because I'm unable to come up with a decent test scenario to reproduce the issue for it to be fixed. Anyone help me out here? Please?

Posted: Fri Apr 04, 2008 4:21 pm

But even though you don't have a test scenario, are you thinking that it is the #DELCLASS that might be causing the problem?

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

I'm not sure if it's the original cause of the problem, but I know that the problem affects commands other than #DELCLASS now. If it'll help, I can send you all my packages so you can look for corrupted pointers or what-not...

Posted: Fri Apr 04, 2008 9:18 pm

If #DELCLASS screwed something up, then yes, it would effect a lot of other stuff. I'm not sure I'd be able to do anything with your package after the fact, but I'll look into #DELCLASS and see if it has problems.

Posted: Fri Apr 04, 2008 10:29 pm

I couldn't find any problem with #DELCLASS here, but I *did* find that #UNCLASS had a problem. #UNCLASS is supposed to move the settings within the class into the top-level class, but it wasn't doing that. It was removing the class record, but leaving the settings within the class pointing to the previous class record. This could definitely result in corrupted settings.

However, I can see some potential trouble here. If you just do:

#DELCLASS MyClass

then CMUD is going to search the current scope for a class called "MyClass". If it doesn't find one in the current package, then it's going to start looking in other packages. It *does* search regardless of the Disabled property of the class, so if you have a class with the matching name in the current package, then it should definitely find that. But if there isn't a class in the current package with that name, then it's going to delete a class in a different package, and the rules for which package it will look in first are undefined.

It's certainly possible that the #DELCLASS command shouldn't be looking for classes in other packages and should require the full //module/class path. This wasn't an issue in zMUD because zMUD didn't have packages. In fact, I think I'm going to change v2.22 so that you can't delete a class in another package without giving the full path for it.

When using the full //module/class path, I can see where it will have a problem if the module is disabled, and I have also fixed that in v2.22. Also, if it somehow couldn't find the specified module (for whatever scoping reasons), then it was defaulting to deleting the class in the current package/module. I have also fixed this so that it won't delete a class using the full path info if the module cannot be found.

For example, just making a typo in the module name could cause it to delete the class name in the current package instead of the one in the module that you were expecting. So that was probably bad.

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

Hmm. Well, those all sound like good things, but I'm not sure if any of them are the problem I'm seeing here. If I do manage to re-create it (maybe tomorrow), I'll come back and post the information.

Posted: Wed Apr 23, 2008 8:59 pm

Please let me know if you still see this problem in v2.22.

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

I'm unable to re-create it in 2.22, so I'll assume for now that the problem doesn't occur any more.

I'll admit, however, that I'm not doing the same sorts of things in 2.22 that I did in previous versions because I got frustrated with having to restore my packages after pointers got switched around. Instead of using lots of nice, small packages, I've been playing my MUD with just the main package and using all the modules in a simpler setup.

When I was using the two dozen packages before, it took several cycles of coding, importing, and testing scripts before I noticed the corruption. If I do ever see this again, I'll definitely be sending in the packages, I think.

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

Okay. It still happens to me in 2.22. I don't have a simple procedure to re-create it, but what I did goes basically like this:

1. Created brand new session.
2. Opened session offline.
3. Opened Package Editor.
4. File -> New Package -> Give it a name based on the script module I'm going to import. (I created three or four packages at a time, just to save me a bit of back and forth time.)
5. Selected the module in each package to enable the "core" package option for each "auxiliary" package that depends on it. (So, one package is the base for all others.)
6. Closed the Package Editor.
7. In my external text editor, loaded up the script files, copied them one at a time to the clipboard and pasted them into the CMUD command line to be executed.

After going through steps 4-7 a few times, creating 15 packages, I noticed that one or two modules were missing the "Tracking" class folder. I tried to re-build one by pasting the script again and noticed that the Tracking class folder then disappeared from another module. There seemed to be a link between these two packages that caused each to delete the Tracking folder in the other, though my #DELCLASS commands used the full "//Module/Tracking" path. Doing "#DELCLASS //ModuleA/Tracking" was removing it from ModuleB and vice versa.

I wanted to reproduce the problem using these packages in another session, so I closed my test session and opened the default session. I added the two packages in question first, but pasting the scripts (even repeatedly) worked perfectly.

I then went back to the original test session and found that pasting my scripts (same two modules) was now deleting the Tracking class folder in completely different modules than the first time.

I didn't have the Package Editor open at all when I was pasting these scripts, mostly because I've had trouble with zMUD's settings editor being opened when I deleted a big class tree structure, so I'm pretty much ruling it out as the primary source of the troubles.

Would it help to send you all my scripts and the order in which I imported them? If so, let me know where to send them and how (zip file, I'm guessing, since there are so many of them).

Posted: Fri Apr 25, 2008 7:43 pm

Yes, I think it would help to send the files and any instructions on the order to import them. Zip them and send them to sales@zuggsoft.com. Hopefully I'll get them. I definitely want to try and track this down.

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

Sent. And, thanks.

Posted: Fri Apr 25, 2008 10:22 pm

I think I found out why we were having email problems. Our server runs something called "Barracuda" which filters spam on our server. Apparently it used to run without me seeing it. Dale at Wolfpaw modified it so that we get summaries of the messages being blocked. I noticed that your message with the files you sent was in the blocked list.

Not sure what caused it to get blocked. It looks like something related to Google Mail that it doesn't like. Even though we get plenty of stuff from other gmail accounts. Maybe the way GMail handles attachments isn't being done properly. I know that if the proper MIME headers are not used for attachments, it can look like spam.

Anyway, at least this tells me why I wasn't getting your emails in the past. The Barracuda stuff happens on the main WolfPaw system before it ever gets to our server, so there was nothing in our local logs about the message.

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

Sent it a little different way. Hope this one works. Glad you found out about the blocked e-mails now, too. Heh.

Posted: Tue Apr 29, 2008 8:10 pm

OK, I think I finally reproduced this using the files that you sent me. As you said, a pretty complicated procedure. But I've now got it screwed up and am trying to debug it in Delphi to find out why it isn't creating the problem folders. Stay tuned.

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

Hooray! Hope you figure it out because it's been driving me a little bonkers. I'm hoping this is what's causing other strange side effects that I see when rebuilding my packages, too, like buttons that appear to be in the GUI folder of one module (when I select the class folder and see them on the list view at the right) but the class folder has no children in the tree and then the button mysteriously also shows up as a root node in my main session package. (Wow, run-on sentence there.)

Posted: Tue Apr 29, 2008 9:24 pm

OK, this is a pretty complex and time-consuming procedure. But I made a couple of fixes and now I can't get it to fail again, so hopefully it is fixed. But depending upon how intermittent the problem was, I might have still missed it. So I'll just need to wait for you to play with 2.23 to let me know if it's working better.

I also found a couple more bugs in the Remove Package command, and cleaned up the code a bit so that selecting a tab from a package that has been deleted and recreated will properly select the top module entry, and so that after you paste your script the first module entry in the package will be properly expanded.

I got pretty tired of always expanding the first module in each package (I'll bet you got tired of this too ;)

Anyway, the core bug I think was that the internal hash lookup table was getting confused. The hash table stores the internal records using the Name+ClassID as the hash value (each setting type has it's own hash table). Somehow when it was trying to look up "//Treant Acquisitio/Internals", it was returning the Internals class record from the "Treant Defup" module. Basically, the hash table had gotten overwritten with incorrect data for the Name+ClassID somewhere along the line.

Using the ClassID is actually a bad idea, because this requires an extra database lookup. Instead of ClassID, I should have been using the internal record number of the class record. This is also a unique value and doesn't require a database lookup. Most of the rest of CMUD has already been converted to use the record number instead of the ID field, and since the ID fields are cached, my guess is that the hash table was getting updated with a cached ID value instead of a real ID value.

But this was all pretty obscure, so it might still be a problem and the changes might generate some unexpected side effects. So far everything seems to be working, but I'll probably need to release 2.23 to testers for this weekend before I actually flag it as a public release. I'm always nervous about changing this kind of low-level stuff.

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

I know it was complex and time consuming. It wasn't easy for me to do this, either. I'm glad you have the patience to go through it a few times. Sounds like more good fixes! I figured it was probably the internal lookups getting crossed.

I'll be rebuilding my packages again in 2.23, so I'll definitely let you know if any more strangeness occurs!