Zugg Software :: View topic - [cmud 3.2 beta] Syntax of the #Class command to create Keywords for Classes?

Newbie Joined: 24 Jun 2010 Posts: 8

I cannot figure out the syntax of the new #Class command that supports specifying the keyword or value that is required for room key classes to function properly with the mapper. The relevant threads discussing how this work are here:

https://forums.zuggsoft.com/forums/viewtopic.php?t=31681&postdays=0&postorder=asc&start=0

Posted: Sat Jun 26, 2010 6:27 pm

Quite simple, really.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Don't think multiples are supported at all, actually. That's not too relevant for non-mapper classes, but on top of the singular keyword thing room/zone scripts absolutely MUST be in the form of RoomXXX or ZoneXXX or else they don't activate.

Posted: Sat Jun 26, 2010 8:26 pm

Multiple keywords are not supported yet. It's on the to-do list, but not for the initial 3.x public version.

Charneus is correct about the syntax for setting the keywords.

And remember that how Room Scripts work now is completely different. In the past, CMUD/zMUD would create a temporaty class folder (System/TempMap, etc) and would execute your room script within this class context when you enter a room. When exiting the room, the entire contents of this temporary class were deleted. Recreating and deleting these scripts each time you enter/exit a room was a big performance problem.

In 3.x, you put your scripts *within* the special class folders "RoomXXX". When you enter the room, this class is *enabled* and when you exit the room, the class is *disabled*. This saves the overhead of deleting/creating settings. In addition, each class folder now has it's own "onEnable" and "onDisable" script that is executed when the class folder is enabled/disabled.

When CMUD 3.x tries to "convert" your old room scripts, all it does it place your script within the "OnEnable" script for the "RoomXXX" class. This is not always the desired behavior. For example, if you have a #BUTTON creation command in your room script, you don't want to create that button every time you enable the RoomXXX class. In that case you would remove the #BUTTON command from the OnEnable script and just move the button within the RoomXXX class folder. As the class folder is enabled/disabled when you enter/exit the room then the button will automatically appear and disappear.

Because of the core change in the nature of how room scripts are done in 3.x, it was impossible to seamlessly convert existing scripts. In our surveys, the vast majority of users did not have very many scripts to make this an issue. If you have hundreds of existing scripts then you are definitely in the small minority. I apologize for the initial inconvience of converting your scripts, but in the long run it will be faster and you'll be able to do a lot more with scripts in the mapper.

Once multiple keywords are added, you should be able to consolidate your room scripts into specific classes. For example, you will be able to create a class folder keyword for a "shop" that will contain all scripts needed when you are in a "shop" room in the MUD and can just give those "shop" rooms the "shop" keyword to activate those scripts.

Newbie Joined: 24 Jun 2010 Posts: 8

Ah, thanks charneus. I had tried that syntax but not with brackets. Thanks! Zugg I'll respond over in the other thread. Thanks for your help! I do agree the new method of scripts is MUCH nicer, there will be a lot more opportunity for managing them seamlessly, especially with the events and classes being scriptable so mass changes can be made easily.