Table of Content Zone | |
---|---|
|
Introduction
GMCP is handlet a little bit differently in different clients. E.g. in CMUD it is considered an event, and is handled with event handlers. While in CMUD it is considered a special form of trigger. Also access to the properties are not always the same.
...
- 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
Don't drive GUI updates directly from the gmcp handlers
As you don't have control over the frequency of the gmcp events, it is generally a bad practice to have the gmcp handler update gui objects like gauges, buttons or screens.
Example:
- If you use the gmcp.Char.Vitals.hp to update a HP indicator in your GUI, it is recommended that the gmcp handler stores the value, and that you have cyclic update of the GUI component, e.g. via timers.
Make your handler "light weight"
To prevent lagging your client, it is recommended that you handler "does as little as possible", generally store the data, then move on. Then do heavier tasks on the data in cyclic processes outside of the event itself.
Mudlet Specific
How to "look at" the gmcp objects
...