Zugg Software :: View topic

SubAdmin Joined: 18 Nov 2001 Posts: 5182

This basically puts a stop to my entire ability to test anything further with 2.06. I am so frustrated that after spending 12 hours between trying to import all my settings and testing to locate all the bugs that made it hard; it still totally @#!$#^.

Right now I have a number of triggers that don't exist according to #TRIGGER.
I have classes that don't exist according to #CLASS
I have alarms that don't exist according to #ALARM
I have aliases that don't exist according to #ALIAS
I have variables that don't exist according to #VAR

Basically I can't do a single thing with my settings the way they are because it makes no sense. The entire contents of one class does not exist, but the class does. The exact same conditions show up in my session as simply using an untitled session and opening the package. Pretty much all the settings in the package we made that way during import from the .mud. A few were moved in from another file, but most were only adjusted for modules and compatibility.

I just give up. Shall we try the email to sales again?

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I thought would provide a nice little screan shot of this.

Procedure
1. Launch CMud
2. Close Sessions Window (ESC)
3. Open Package Editor (CTRL-G)
I am so sick of typing out those first 3 steps!
4. Adjust preferences for untitled widow to display informational message, why this is not on by default is beyond me.
5. Select File|Open from Package Editor window
6. Grabbed my .mud and let the conversion go
At this point everything is fine, perfectly fine when checking in the window 'Room.mud' window
7. Create module in my imported package gave it a name and set it to global
8. Drag a few classes from the window into the global module
9. Check with the various command in the untitled window to see what is there.

Checking in the imported package's window still has everything. I think the same problem occurs with the External Only setting of a module since I had stuff not working when I tried using that too. This test makes it look like it is just an issue with not checking inside classes correctly. It gives me some joy to at least believe that the import is not the issue.

Enchanter Joined: 10 Oct 2000 Posts: 698

Don't give up or get sick of testing Vij. Your reports are excellent and seriously appreciated by current and future users. I wish I had the time and know-how to do half the reporting you've done the past few days. Massive kudos to Zugg too. Thanks guys!

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

Hear hear! I always get the impression that, Zugg aside, it's you that knows the product as if you'd written it yourself. No doubt Zugg and the rest of the forum appreciate the efforts.

Posted: Mon Oct 15, 2007 11:08 pm

Vijilante, is this using the same file as you uploaded to the Guru area? If not, make sure the MUD file that you had trouble importing is there. I'll be working with all of your files tomorrow (Tuesday). I definitely want to get these import issues fixed.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

This was a different file. I saw the same results with every file I tested so you should be able to get the same with just about anything you have that will convert. If you can't match it then I can make up a zip the pkg used in that screen shot and the .mud that was converted.

Posted: Tue Oct 16, 2007 9:42 pm

OK, I got the files from the Guru area without any problem. Today is "Vijilante Day" at Zugg Software :) I'm spending all day trying to track down the various bugs you have reported and will keep working on them tomorrow as necessary. I'll keep you posted.

Posted: Wed Oct 17, 2007 7:03 pm

Looks like maybe the status bar import problem was also causing this. I cannot reproduce it in 2.07 with any of your files now. But let me know after 2.07 is released is you still have trouble.

Also, the Echo Messages option *is* set by default, but when you Import a *.MUD file, then the zMUD preferences from that file are also loaded, so maybe it was disabled in your imported mud file? It's also possible the status bar problem was causing this too since it was screwing up for everything that came after it in the mud file.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I will check it again in 2.07.

The particular file used in that screen shot had no status bars. It does seem likely that it was a culmination of other bugs though. I can't replicate it from an untitled session.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I just checked this with a package file made with 2.06 and everything looks good in 2.07

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Some days I just can't win. I decided to go through entire import and rearrange process again with 2.08. Fun I know.

I have this same problem with some of my newly created by v2.08 packages. These ones have the nice ability to be opened into any session and get the same results. I also think I know what causes it to get messed up like this. As near as I can guess when a class is dragged from a window into a module in the same package, child settings of that class don't get some sort of ownership flag set correctly. The class itself will properly be repointed/indexed whatever, also moving an individual setting will do it right, but all the settings contained in a class are not. This seems to affect every type of setting.

To see this with my current packages I doing the following
1. Launch CMud
2. Close Sessions Window (ESC)
3. Open Package Editor (CTRL-G)
4. Using File|Open from the PE menu open Channels and Room packages
5. Enter at the command line

Posted: Tue Oct 23, 2007 9:41 pm

Yep, I think you are correct. I think the database is actually getting updated, but the cached settings in memory are not. I'll look into this and see what I can learn.

Posted: Fri Oct 26, 2007 9:52 pm

It was just as you guessed. In the original database design, everything was a relative pointer. In other words, a setting record in the database had a "parent" record, which pointed to the class (or parent trigger/button for multistate stuff) that it was contained in. So settings could be moved by just changing this parent field, and if you changed the parent field of a class, all of the settings within that class were uneffected.

But sometime during the development of CMUD, I had to add the "pkgid" field, which is actually a pointer to the *module* (or window) that contains the setting. It's called "pkgid" because it used to be a package number, back when a package was the same as a module. But when multiple modules/windows within a single package was added, this field was changed to be the module ID pointer.

Having the module ID pointer for every setting made it a lot easier to implement the scoping rules, and improved performance (since it didn't have to recursively look up the parent of the parent until it got to the top to determine what module it was in).

But, the side-effect of this is that when you move a class, you can't just change the parent pointer of the class. Now you must loop through each child setting within the class to update it's module pointer value. And this is what wasn't happening. So when you moved a class to a different module, all of the settings within the class were still pointing to the previous module (and that is used for the scoping rules).

So, I have made two fixes in v2.09. First, I have fixed the drag/drop and MoveTo routines so that they will loop through the child settings and properly update their module pointer (this was already being done with CopyTo since Copy already needed to make new copies of each child setting).

The second "fix" is that when you load a previously saved package into v2.09, it performs a one-time check of your package. It looks at each setting within the package and calculates what the module ID pointer *should* be (based upon recursively following the parent pointers). This will make it take a bit longer than normal to load an existing package the first time. But once the package has been checked for consistency, then this procedure won't run on that package again.

This consistency check *should* fix any existing packages that have messed-up module pointers left over from drag/drop or MoveTo.

So, this bug was rather serious. It didn't just effect the internal cache. It was effecting the actual *.PKG database file and was storing incorrect module ID pointers. So even loading the package again wasn't fixing this, and you could end up with settings in other modules/windows that had the incorrect pointer and therefore incorrect scope (making it appear in windows that it shouldn't, and not work in windows that it should). Very very nasty problem, so I'm glad Vijilante reported this one!