Zugg Software :: View topic

Posted: Fri Aug 24, 2007 4:18 am

Does raising System Events prevent them from being called.

I'm making a mapping system for my client and after tagging the rooms I want to raise the onRoomCreate event. Now I'm wondering that if I do the mapper will still raise the event and if it does will it map the room twice.

This may all be moot since I'm still thinking the system through and that might not be the right approach.

I guess the better question would be when does the onCreate method get called? Is it when the next onPrompt event is raised?

Posted: Fri Aug 24, 2007 10:14 am

onPrompt isn't a system event. It's got no bearing on when OnRoomCreate is called.

A room won't be mapped twice if you call OnRoomCreate twice - it's the act of creating a room that raises the event, not the event that creates the room. Raising the event yourself will simply cause whatever scripts you have in OnRoomCreate events to run both when you raise it and when a room has actually been created.

You don't need to raise onRoomCreate after tagging rooms, because if your #tag triggers are configured properly, they'll cause a room to be created when you're in edit mode, which will raise the event.

Posted: Fri Aug 24, 2007 5:14 pm

Fang is correct. CMUD doesn't do anything with the system events itself. It just fires them. If you raise an event yourself, then CMUD will still raise the event too. So your event handler might be called twice (once by CMUD and once by your own #RAISE command), but that won't have any impact on what CMUD does when it creates a room.

The mapper events should be the same as the old aliases defined in zMUD, so you might be able to find some old zMUD posts that document their behavior. They were never well documented, and I don't want to document them here (or spend the time to remember what they really do), since it's likely they will change when the mapper is rewritten for CMUD.

Posted: Fri Aug 24, 2007 5:47 pm

Fair enough. As I said I'm still thinking through the system and I think I really went down the wrong path there. Thanks for the info.

Wizard Joined: 17 Jun 2006 Posts: 1201

OnPrompt is a user defined event right? You have to create it. I really don't understand events I guess. Basically if I put #raiseevent onPrompt in my prompt trigger and in the onPrompt event have a bunch of aliases and stuff I want to fire, this is how it works right? What's the advantage of putting all the aliases and stuff in the onPrompt event compared to just sticking them in the Prompt trigger itself? Or is there one?

Posted: Sun Aug 26, 2007 3:46 pm

Yes, onPrompt is a user-defined event. The idea is that you remove the aliases and replace them with event handlers, which are then all raised by the single onPrompt event. This is more convenient because your "aliases" will now be labelled exactly when they fire.

The main strength of events is modularity. By creating an onPrompt event, you make it easier for other people (if you distribute your scripts) to create their own event handlers that use your event. Instead of having to modify your trigger to add their commands in (and forcing them to have to make the change every time they update), they can just create their own onPrompt event and use that instead.

You can use this yourself if you use more than one package - events raised in one package will be "seen" from the other package, allowing you to bypass some scoping issues.

Modularity can also be very useful as a time-saving device. My prompt trigger looks like a (very long) list of #if statements that check to see if various systems are active before doing things related to that system. It's regular to see things like

Posted: Sun Aug 26, 2007 3:55 pm

Yes it's user defined. It's an example often cited, and one I have defined so when I wrote my post (in a sleep deprived state) I did it as if ti was a system event.l

The are several advantages to events, although technically you could accomplish the same thing with triggers and aliases. The more packages you work with and distribute the more important the become.

The allow packages to respond to certain events, like the prompt, and the associated information without knowing the exact format of the prompt.

For example I have some code that gives creates a 3-color health gauge based on the HP variable. Anyone can use this by simply raising an onPrompt (or onHPUpdate event, since you can get HP updates in places other than the prompt) and the package will work. While technically you can still do this triggers updating specific variables, using EVENT is cleaner.

Another example is I have an MXP driven status window. Initially to get it to work I had the MXP send text, with I would detect with and ONINPUT trigger, GAG and do the specific processing. I've recently updated it to use events and this is a cleaner approach.

So there's no real advantage if you never use other peoples package or plan to distribute your own... at that point it's a matter of aesthetics, but if that is not the case the become quite useful. I hope those examples help.