Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD Beta Forum Goto page 1, 2  Next
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Tue Nov 14, 2006 11:51 pm   

Events added in version 1.16
 
Today I'm adding the Event support for CMUD. This is one of the remaining features that needed to be done before the public release.

In zMUD, there were some "special" aliases that were called by zMUD. For example, there as an "atconnect" alias that would be called when you connected to the MUD. The mapper also had various special aliases.

The problem with these aliases is that they don't scale well to the concept of packages. When you execute an alias, CMUD looks for the current alias with a matching name that is enabled and executes it. There is no way to execute more than one alias.

What we have discussed in the past for CMUD is a new concept called "Events". Events are sort-of a cross between Aliases and Triggers. They have a plain name, like an alias (as opposed to a trigger pattern), but when an event "fires", all events with the same matching name are fired.

To create an event, you use the #EVENT command:
Code:
#EVENT name {commands} "optional classname"
#EVENT onConnect {#PLAY connect.wav}

You can fire an event within a script using the #RAISEEVENT command (or just #RAISE). You can fire a system-defined event if you want, but this is mainly for your own custom events.

Any enabled event with the matching name is fired. For example, you can have an event within a published module of another package. One example is to have a package that detects your prompt and the issues the #RAISE Prompt command to notify all other scripts that a prompt was detected.

Events can have arguments. These work just like aliases. You can use the normal %1..%99 syntax, or named arguments like this:
Code:
#EVENT onPrompt($hp,$mana) {hp=$hp;mana=$mana}
#RAISE onPrompt 123 456

This would assign 123 to @hp and 456 to @mana.

There was some discussion in the past of making Events into a special kind of trigger. I decided against that. For one thing, the user interface is different. Most of the trigger options don't apply to events. And in the event editor interface, the Name field is actually a drop-down list of currently defined event names so that you can see which events are already defined and available.

Also, by keeping the Events as a simple name, like aliases, CMUD is able to optimize the execution of events. Internally, the event names are converted to an ID number. So when you use #RAISE, it converts the name of the event that you specify to a number and then actually executes any event that matches the number. This is much faster than the string testing that triggers use. This ID number is transparent to the player...players just use the names of events. But internally the ID number helps speed up event execution, making them faster than triggers.

When I'm done implementing this, I'll write up some help files for it. I'll also add this to the list of changes from zMUD because anyone using the existing system-defined aliases will need to convert them to events instead of aliases.

If you want to use multiple trigger states with events, you can use the #FIRE command that was added to CMUD a couple of versions ago. For example, an Event can use #FIRE to cause a trigger to fire, or a trigger can use #RAISE to cause an event to fire. So there is already plenty of flexibility here, and yet remains pretty simple for most users.

This should be another cool addition to CMUD. I'm expected to see lots of interesting uses for this new feature.

Feel free to discuss it here, although I've already implemented most of it.
Reply with quote
Vorax
Apprentice


Joined: 29 Jun 2001
Posts: 198
Location: USA

PostPosted: Wed Nov 15, 2006 12:10 am   
 
Quote:
If you want to use multiple trigger states with events, you can use the #FIRE command that was added to CMUD a couple of versions ago. For example, an Event can use #FIRE to cause a trigger to fire, or a trigger can use #RAISE to cause an event to fire. So there is already plenty of flexibility here, and yet remains pretty simple for most users.
I trust there will be some kind of infinite looping protection so that a user can't Raise an Event that Fires a Trigger that Raises the same Event again, causing an infinite loop.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Wed Nov 15, 2006 12:30 am   
 
Yep, there will be loop protection just like with aliases.
Reply with quote
makena
Apprentice


Joined: 11 Aug 2006
Posts: 100

PostPosted: Wed Nov 15, 2006 5:30 am   
 
Will there be a predefined-event for the tick timer reaching 0/resetting, etc?

More so, what predefined-events will there be?

I have been waiting for these! *cheer zugg*
Reply with quote
bortaS
Magician


Joined: 10 Oct 2000
Posts: 320
Location: Springville, UT

PostPosted: Wed Nov 15, 2006 3:32 pm   
 
Event driven MUD scripts! *drool* Like VB6 for MUDs. Twisted Evil
_________________
bortaS
~~ Crusty Klingon Programmer ~~
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Wed Nov 15, 2006 4:27 pm   
 
This is great! Now, I'll have to get started on converting my scripts to be the modular, event-driven, black boxes I've always wanted them to be!
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Wed Nov 15, 2006 7:12 pm   
 
The current pre-defined events are (these are just converted from the old at* aliases):

OnConnect - fires when connected to the MUD
OnDisconnect - fires when disconnected
OnExit - fires when session window is closing (CMUD exit, or manually closing the MUD window)
OnRoomEnter - fires when entering a room in the mapper
OnWalkEnd - fires at the end of a speedwalk in the mapper
OnRoomWalk - not sure on this one (it's the old atroomwalk alias), but I think it fires when you are about to leave a room
OnRoomCreate - fires when a new room is created

Adding events for the tick timer is a great idea. In fact, there are probably other useful events that can be added, so if people have more ideas, let me know. It's pretty trivial to add a call to an event within the CMUD code now.

I'll add events for:

OnTickWarning - fires when the tick timer warning is normally displayed
OnTick - fires when the tick timer expires
OnEverySecond - fires each second when the clock is normally updated
OnEveryMinute
OnEveryHour (we probably dont need OnEveryDay, do we?)
Reply with quote
Rainchild
Wizard


Joined: 10 Oct 2000
Posts: 1551
Location: Australia

PostPosted: Wed Nov 15, 2006 9:24 pm   
 
We can use #alarm for things like 'atmidnight'...

It might be nice to add a watch event to variables, but that could get complicated on the syntax I suppose. Still it could be nice to see an OnHpChange which can then do checks like if hp low, cast cure, etc...
Reply with quote
The Raven
Magician


Joined: 13 Oct 2000
Posts: 463

PostPosted: Wed Nov 15, 2006 11:06 pm   
 
Wonderful. This will make it a lot easier to catch the same action in multiple areas. If you've ever created a trigger that just calls an alias, and that alias does 3 different things, then events will probably make your life easier.
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Thu Nov 16, 2006 12:24 am   
 
Zugg wrote:
OnEverySecond - fires each second when the clock is normally updated

Heh, I already worked around this one in zMUD by setting my tick timer to be 1 second! Wink And then scripting some stuff like #ECHOs after x seconds and resetting my counter after 60 seconds. Still, this would be cool - it means I can have more timers without using #ALARMs which I feel might be overkill for something I want running the whole time.

I thought about some generic MXP events - almost posted the idea earlier but then I thought that #MXPTRIG is pretty similar. Anyway, maybe just a couple of generic MXP events would be nice, e.g. OnMXPTagStart($TagName, $TagParam1, $TagParam2, ... , $TagParamn) and OnMXPTagEnd($TagName, $TagParam1, $TagParam2, ... , $TagParamn). This might be more efficient than MXP triggers? Then one could use #SWITCH in the #EVENT code to call other more specific events if one wants to... Anyway, just an idea.
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Thu Nov 16, 2006 12:54 am   
 
A couple of other ideas:
OnRoomEdit - fires when a room is edited by the AutoMapper (not via #CALL %roomwhatever(, stuff)), e.g. when the Room Description was blank before and gets filled in. %1 should be the roomkey or something.
OnRoomLost - fires when the AutoMapper gets lost, i.e. enters a room that wasn't the one it was expecting. I think there is a message "Slow walk aborted" or something that gets echoed after a while under these circumstances, but it seems a bit silly to make a trigger for that. %1 should be the roomkey or something of the last known room.
OnRoomFound - fires when the automapper was lost but now is found(!), e.g. when you press the Find position button and it finds the room. %1 should be the number of possible matches, %2 ... %n the roomkeys or something of the matches. Or maybe OnRoomFind when there is more than one possible room match, and onRoomFound when there is only one?


Last edited by Seb on Thu Nov 16, 2006 9:58 am; edited 1 time in total
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Thu Nov 16, 2006 4:03 am   
 
Do any of the mapper events fire when you do a #FIND to update your position? Or a #TELEPORT?
Reply with quote
mr_kent
Enchanter


Joined: 10 Oct 2000
Posts: 698

PostPosted: Thu Nov 16, 2006 8:10 am   
 
OnWindowFocus
Reply with quote
The Raven
Magician


Joined: 13 Oct 2000
Posts: 463

PostPosted: Thu Nov 16, 2006 5:27 pm   
 
And OnWindowBlur. It would be nice if you could enable triggers when you minimize/leave the MUD screen (like setting AFK, or turning on an activity siren)
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Thu Nov 16, 2006 6:50 pm   
 
I probably won't add any mapper events until I work on the mapper rewrite next year. It was easy to just convert existing "atalias" calls into events, but adding new events requires that I have a better understanding of how the mapper works than I do right now. The mapper is very complicated and it's been years since I worked on it, and now isn't a good time to spend several days trying to figure out how it works again.

For the MXP stuff, you can use the existing MXP triggers instead...they are much better for that kind of stuff. For detecting a change in a variable, use the existing Expression triggers...they work much better than they did in zMUD.

So, I don't want to create a ton of system events that duplicate too much existing functionality. But things like OnWindowFocus and stuff like that are good ideas.

Remember that in the settings editor when you create an event, you get a drop-down list of all defined event names, so we don't want this list to get too unmanageable.
Reply with quote
shalimar
GURU


Joined: 04 Aug 2002
Posts: 4692
Location: Pensacola, FL, USA

PostPosted: Thu Nov 16, 2006 8:38 pm   
 
OnCommandLine - would let you know when the last user entered command was... you could have it turn off triggers and whatnot if you have not manually entered anything recently

OnMacro - same as above but for macros
_________________
Discord: Shalimarwildcat
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Mon Nov 20, 2006 3:18 pm   
 
Shalimar: Not sure how OnCommandLine would be any different than setting up an #oninput trigger? And not sure what you mean by OnMacro.
Reply with quote
Vitae
Enchanter


Joined: 17 Jun 2005
Posts: 673
Location: New York

PostPosted: Mon Nov 20, 2006 4:19 pm   
 
Zugg, I'd assume that he meant that onmacro "would let you know when the last user entered macro was... "
_________________
http://www.Aardwolf.com
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Mon Nov 20, 2006 5:58 pm   
 
Right, and that doesn't really make any sense to me. Perhaps he could post an example of what he is trying to do with such an event.
Reply with quote
shalimar
GURU


Joined: 04 Aug 2002
Posts: 4692
Location: Pensacola, FL, USA

PostPosted: Mon Nov 20, 2006 11:22 pm   
 
A system to check if user is idle or not. If one hasn't manually (typing or macro) entered any commands within a given timeframe, it could be used to turn off any classes that would break the afk scripting policies that alot of muds have.

Maybe on OnIdle event would be better suited?
_________________
Discord: Shalimarwildcat
Reply with quote
mr_kent
Enchanter


Joined: 10 Oct 2000
Posts: 698

PostPosted: Tue Nov 21, 2006 6:22 am   
 
shalimar,

I think we're being asked for suggestions about situations where events are needed. That is, where current scripting stuff can't do what we want it to.

Scripting aliases, variables, macros and triggers for when the user is idle is already possible for the most part. If you have a special case where an event is needed, please explain why it can't be accomplished with current scripting commands; or at least why creating an event for OnIdle would be vastly superior to using the-already-implemented scripting commands.

I like the idea of creating as many events as possible if they are neccessary (OnConnect), if they significantly simplify our scripts (OnTick), or if they are so broadly manipulated by most users that the need is evident (OnPrompt). I don't see why OnIdle shouldn't be an event except that Zugg is working on creating a stable client with basic functionality for public release. In my opinion, duplicating the functionality of current scripting commands doesn't make sense right now, unless there is something specific you want to accomplish and are not able to. I believe this is the point Zugg was making and I apologize if I'm off the mark.
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Tue Nov 21, 2006 7:35 am   
 
I thought OnPrompt was an example of a custom event. Since you'd always have to raise the event manually via triggers.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
mr_kent
Enchanter


Joined: 10 Oct 2000
Posts: 698

PostPosted: Tue Nov 21, 2006 7:50 am   
 
Fang Xianfu wrote:
I thought OnPrompt was an example of a custom event. Since you'd always have to raise the event manually via triggers.


Well that makes sense I guess. Please disregard my tired bumbling.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Tue Nov 21, 2006 6:28 pm   
 
OnIdle is a possibility for the future. But it's not a simple event that I can just add to the current code. I'd have to build in some code to detect when CMUD is idle, and add some sort of idle time preference. This is possible later, but right now I was looking for quick and easy events to add, like the OnTick, where the logic for it already exists. But I'll put OnIdle into the wish list for the future.
Reply with quote
Morgal
Beginner


Joined: 06 Nov 2006
Posts: 26

PostPosted: Tue Dec 12, 2006 8:08 pm   
 
Zugg wrote:

I'll add events for:

OnTickWarning - fires when the tick timer warning is normally displayed
OnTick - fires when the tick timer expires
OnEverySecond - fires each second when the clock is normally updated
OnEveryMinute
OnEveryHour (we probably dont need OnEveryDay, do we?)


Just curious, did ALL these get added, as either.. im dumb and cant figure out how the OnEverySecond event works, or.. the time ones didnt get added....

Someone help me out please, even if its just to say.. im dumb.

Morgal
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net