...
Below i will try to create examples for common use cases in Mudlet and CMUD.
General Best Practice
| Info |
|---|
While a super will fire if a sub event is sent, That does not mean that all the data on the super is updated, or indeed, available. Therefore, a set of best practices have been described below. |
Use Small, specialized event handlers and triggers
It is recommended best practice to make the event handlers as small as possible, reacting to the "lowest possible" sub module because of this. Also that the handler only uses data from its own "node" and "downwards"
Example:
- You do not want to make a handler for gmcp.Char as the submodules below this fire at completely different intervals and events. Also there is no guarantee that all data in gmcp.Char is available at this time
- Rather make separate handlers for gmcp.Char.Vitals and gmcp.Char.Effects
- In these handlers, don't access other trees like gmcp.Char.Spells or gmcp.Char.Status
In the event/trigger, use only data from the relevant submodule
For the same reasons above, it is important that each handler only has awareness of the data "below it". Otherwize you will quickly encounter crashes or missing data due to the sparse nature of the protocol. If you need data from other parts of the tree, use Caching.
Example:
- In your gmcp.Char.Vitals handler, do not use the gmcp.Char.Status.name variable
- In your gmcp.Group.Party handler, do not use the gmcp.Char.Vitals.hp variable
Use caching when persistance/global access is needed
It is common that you want to access data from other parts of the gmcp tree in one of the handlers. E.g. you might want to access gmcp.Char.Status.name inside gmcp.Group.Party, or from within the gmcp.Action.Round.
As this can easily cause crashes and undeterministic behaviour due to the sparseness of the data, it is therefore recommended that for such use cases, you cache the inbound data to a global variable/hierarchy.
Note that this is primarily a challenge when communicating across trees, and less of a problem when navigating upwards in the same tree. However, the protocol does not enforce update of a super object when a child is sent, so consider this a general best practice!
Example:
- in your gmcp.Char.Status handler, you store the gmcp.Char.Status.name to a globally accessible variable Char.name
- in your gmcp.Char.Vitals handler, if you need the character name, you use Char.name instead of gmcp.Char.Status.name
Mudlet Specific
How to "look at" the gmcp objects
...
- a handler tied to "gmcp.Char" will fire on gmcp.Char, gmcp.Char.Vitals and gmcp.Char.Effects
- a handler tied to "gmcp.Char.Vitals" will NOT fire on gmcp.Char.Status or gmcp.Char.Effects
...
- or
...
It is recommended best practice to make the event handlers as small as possible, reacting to the "lowest possible" sub module because of this. Also that the handler only uses data from its own "node" and "downwards"
Example:
...
- gmcp.Char
...
- .
...
- Effects
...
There are two main ways to setup handlers for events in Mudlet. I recommend reading the documentation for the Mudlet Event_Engine for details, but i will brifely describe the methods here:
...