Zugg Software :: View topic - [3.31-3.32]Bug: Class folders with zone keys not closing

Posted: Wed Nov 10, 2010 8:44 am

This happens sporadically, sadly, so I can't reproduce it. However, it does only happen with folders that have zone keys in them (quite possibly room keys as well, not sure).

The bug is this: I'm not sure that the zone folders close out all the way, if that makes sense. The reason I say this is because variables will duplicate in a folder recently accessed by the mapper, and so will newly created triggers. The weird part about this is that the folders ARE still disabled (due to not being in the zone anymore), but the variables and triggers still create in that folder.

The only way I can stop it from creating new items in that folder is to do #CLASS 0 on the command line.

Zugg, can you look into the coding for the mapper vs zone/roomkeys to see if there is a missing #CLASS 0 (or the equivalent of it)? It's getting to be annoying, and I think has happened in earlier versions, though I'm not sure since I haven't been active with the mapper and zonekeys until very recently. Thanks!

Charneus

Posted: Wed Nov 10, 2010 5:26 pm

I know you said you couldn't reproduce it, but without a script to reproduce it, there isn't much I can do. There certainly isn't any missing "#class 0" or else it would happen all the time to everybody. If a folder is disabled, I can't see any way to create a new variable within it unless you are forcing it with the //module/class/varname syntax somehow.

Posted: Wed Nov 10, 2010 10:16 pm

That's the problem though... The only script I run that has to do with the mapper is using %mapquery to find a certain room, then using a macro to run to that room. I don't use the //module/class/varname syntax in any of my scripts, nor do I use a #CLASS "foldername" except when I am creating a new class folder for a new area, but even that is closed out.

And the folder is definitely disabled, unless the GUI is lying to me. It is greyed out and has a strike-through. But it not only creates new variables, but #ALARMs are created in the "disabled" folder, and due to it BEING disabled, the #ALARMs never fire. In fact, all settings are created in the disabled folder, but none will work, including temp triggers, and you can't even call the variables. But they are created, nonetheless.

The only thing that works is #CLASS 0. I don't know how you're calling that a zone-specific folder is enabled, but it's not fully closing out, and again, it's sporadic, and I could spend all day trying to reproduce it and I probably wouldn't get anywhere. However, I will see what I can do... *sigh*

Charneus

Apprentice Joined: 10 Apr 2009 Posts: 145

I've had this happen before too. Variables created new in a mapper related class instead of using the existing variable in a "normal" class. I don't know what caused it, and usually only noticed later when things acted unexpectedly.

Posted: Thu Nov 11, 2010 5:09 pm

The only time I had this happen to me was when i tried to make the old mapper scripts from zMUD in CMUD.
Any variables declared will be made in the appropriate mapper room class instead of the within the session module unless you use full path names.

Posted: Wed Nov 17, 2010 8:04 pm

Here's a video of it happening in real time. I'm in a different zone, which is why Grand City of Aylor is disabled (class key and everything). Note how the settings still continue to be created in that folder.

I still don't have a reliable way of doing this, though I'm beginning to suspect it has something to do with multiple threads using #WAIT while in the middle of changing zones... Not sure how I can really test that, though.

Disable class still creates new settings video

Charneus

Note: The variables created are part of scripts, none which contain a #CLASS command.

Wizard Joined: 22 Mar 2007 Posts: 2320

Are those threads defined within room folders, or as an enable/disable script, or initiated as a result of a trigger or script within a room folder?

Posted: Wed Nov 17, 2010 9:38 pm

If you are using #WAIT then you might need to add your own #CLASS command to ensure that the proper "default class" is still set. During a #WAIT some other script can change your current default class.

Posted: Wed Nov 17, 2010 11:01 pm

Well, the script would be an internal one to CMUD then, because as I've already stated, I do not have scripts that change default classes. Therefore, it would be the mapper using #CLASS instead of #T+ to enable/disable classes, which seems odd to me.

That still doesn't quite explain how CMUD is able to create settings in a disabled folder, as indicated in the video above...