ScalyMUCK Base Modification

Found here is a great example of how modifications are implemented inside of ScalyMUCK. All modifications that are intended to be loaded into ScalyMUCK must be provided in the form of a module you can merely drag and drop into application/game/ and from there the server host can modify their server_config.cfg file to add the modification to the loaded modification listing.

class scommands.Modification(**kwargs)

Main class object to load and initialize the scommands modification.

__init__(**kwargs)

This initializes an instance of the scommands modification and it will remain loaded in memory until the server owner either unloads it or reloads it which therefore will reset any associated data unless the data had been defined on the class definition itself rather than being initialized in this function.

Keyword arguments:

• config – This is the instance of Settings that contains all loaded configuration settings available for this modification, if the file exists. If the file does not exist, then this will simply be None.
• interface – This is the instance of the user interface used internally by ScalyMUCK. Generally, you won’t need access to this for any reason and is currently deprecated for later removal.

Actions such as binding your Blinker signals should be performed here so that events will be received properly when they occur.

Along with initializing the modification, __init__ acts as a gateway for other important data passed in by the modloader under the **kwargs argument.

callback_client_authenticated(trigger, sender)

Callback that is bound to the “post_client_authenticated” event.

Callbacks like this one are helpful in cases that if you want to initialize certain data upon the authentication of a certain client – perhaps you’re loading mod data that is related to this client.

Refer to the __init__ function.

callback_message_sent(trigger, sender, input)

Callback that is bound to the “pre_message_sent” event.

Callbacks like this one are helpful in cases that if you want to intercept input for any reason, such as an interactive menu that will handle it’s own text parsing for handling menu functions as that if the callback at any point returns true, the server will not pass the input text into the core parser.

Refer to the __init__ function.

get_commands()

Returns a dictionary mapping the available commands in this modification.

This is a function call merely for the purpose of being able to provide variable output, so that if the modification has an accompanying configuration file it can omit or include certain commands based on the configuration settings loaded in the modification’s __init__ function.