Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD General Discussion
charneus
Wizard


Joined: 19 Jun 2005
Posts: 1876
Location: California

PostPosted: Wed Nov 10, 2010 8:44 am   

[3.31-3.32]Bug: Class folders with zone keys not closing
 
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


Last edited by charneus on Wed Nov 17, 2010 8:04 pm; edited 1 time in total
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
charneus
Wizard


Joined: 19 Jun 2005
Posts: 1876
Location: California

PostPosted: 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
Reply with quote
Moo
Apprentice


Joined: 10 Apr 2009
Posts: 145

PostPosted: Thu Nov 11, 2010 12:44 pm   
 
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.
Reply with quote
shalimar
GURU


Joined: 04 Aug 2002
Posts: 4683
Location: Pensacola, FL, USA

PostPosted: 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.
_________________
Discord: Shalimarwildcat
Reply with quote
charneus
Wizard


Joined: 19 Jun 2005
Posts: 1876
Location: California

PostPosted: 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.
Reply with quote
Rahab
Wizard


Joined: 22 Mar 2007
Posts: 2320

PostPosted: Wed Nov 17, 2010 9:08 pm   
 
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?
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
charneus
Wizard


Joined: 19 Jun 2005
Posts: 1876
Location: California

PostPosted: 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...
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD General Discussion All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net