Zugg Software :: View topic - Opinion about how Shared Alarms should work

Posted: Tue Nov 20, 2007 1:58 am

In v2.12 you can put an Alarm in a global or external module and it gets "shared" between the existing windows. In other words, when the alarm fires, CMUD loops through each module/window and executes the alarm within any module/window that can "see" the alarm.

Right now, the order in which the module/windows are executed is the order in which the modules were created and loaded.

But I was thinking that I might want to tweak this. Obviously the module that contains the alarm can "see" it. So in addition to any windows that might execute the alarm, the alarm is also going to be executed within it's own module at some point.

So, should the alarm execute within it's own module First, or Last? If executed first, then it could initialize some stuff. But if it is executed Last, then it can do cleanup (like disabling itself).

Seems like executing Last would be an advantage for those who want to disable the alarm when it has finished executing in all of the other windows. But I'm interested in opinions on this. Oh, obviously this is only related to repeating alarms. Alarms that fire once actually have a bug in v2.12 in that they get removed after they fire in the first window and they don't get executed in other windows after that. This bug is fixed in 2.13.

GURU Joined: 10 Oct 2000 Posts: 873 Location: USA

Posted: Tue Nov 20, 2007 3:37 am

SubAdmin Joined: 18 Nov 2001 Posts: 5187

I think Tarn is right. Owning module/window first, then any other that can see it. After all modules have had thier chance then any #T± or deletion of a temporary alarm would occur. I am making the not so small assumption that a trigger creating a temporary alarm would create it in the window just the same as it does with a variable.

As a side note I did have a few odd hiccups with global alarms, but as soon as I corrected them to be - instead of * they all worked perfectly. I think the change is good and some sort of compatibility note will help those that still have to transition from zMud.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

I would expect that if I have set an alarm up to be global then anything that happens within it would be global as well. So if I use a #T- then the alarm would do its job everywhere then turn itself off everywhere.

I would NOT necessarily wait for the alarm to fire again before disabling itself however. I would suggest something more along the lines of a timeout threshold.

If the alarm will fire again within say five seconds then have it turn itself off right before the next time it would have fired again. On the other hand if the alarm will fire again in ten or more minutes you might want to disable the alarm sooner based on a predetermined timeout period. This is all just blowing in the wind however. If you could set it up so that the alarm could turn itself off instantly after it has run in all modules/windows that would be great.

Posted: Wed Nov 21, 2007 11:40 pm

So, I thought about this a bit more. One problem is that an alarm cannot execute without a window. So this whole decision of whether the alarm executes in it defined module first or last is moot...in a shared module the alarm cannot execute at all.

And this is what most people would expect I think. For example, what if the alarm script sent something to the MUD, or called #SAY to display text? Where should that text get displayed? If it is displayed in the current window, then you'd see the text in the current window twice: once for the alarm executing within it's own defined module, and once for the alarm executing within the current window.

So, 2.13 isn't going to execute the alarm within it's current module at all. If the alarm is defined within a window, then of course it executes only within that window. But if the alarm is defined in a shared module, then the alarm just executes within each *window* that can see the alarm.

Apprentice Joined: 26 Apr 2007 Posts: 113

While the solution you have come to isn't necessarily bad, how about having the option to specify a window for alarms in modules? As I'm seeing it, having an alarm firing in several windows could be more taxing than it has to be.

GURU Joined: 10 Oct 2000 Posts: 873 Location: USA

Posted: Thu Nov 22, 2007 2:28 am

This has no effect on aliases. It only effects alarms and it only effects alarms that are defined in a *module*. Normal alarms in windows work the same way they always have. If you want an alarm to only run within a certain window, you can already create it in that window using the normal #alarm syntax:

Apprentice Joined: 26 Apr 2007 Posts: 113

I meant if they're in a module, you could specify a windowname for them to route to, rather than going through all windows that can see that alarm.

SubAdmin Joined: 18 Nov 2001 Posts: 5187

That was part of what the change for using -time properly was for. If an alarm of the form #ALARM {-5} {do stuff} is in a shared module then it will only 'do stuff' in a window that is online. We all got in the habit of using * instead of -, and changing the way alarms work made that distinction more important.

Zugg already said quite clearly that an alarm defined in a window only fires within that window, so that is set. That means we already have 2 ways to make the alarm only work in specific windows.

Now lets say we need to distribute an alarm that only operates in 1 window of each session that is loaded. CMud doesn't do it for us automatically, just like if we distribute a package with triggers that depend on states they won't work too well for a multiplayer. I am fine with having to code around that limitation. I am not about to ask Zugg to write my scripts for me. The alarm that would do it by the way, totally untested but something I am planning on putting in my little toolbox package.

Posted: Thu Nov 22, 2007 5:08 am

Also, it's actually very easy in your alarm to perform different actions for different windows. The new %context variable gives the name of the window that the alarm is being executed within. So if you only want the alarm to do something in a specific window, just test the %context variable.

GURU Joined: 10 Oct 2000 Posts: 873 Location: USA

Posted: Fri Nov 23, 2007 3:49 am

Definitely should run first, and I think it should disable immediately. I can see the fixed 'listener' list being handy, but more often than not I only want my alarm fired in one window so I think the immediate T- would be what I want. Now granted you could make an argument for not doing so, but I think my approach represent the 90% usage case. Of course I could be wrong.

Posted: Mon Nov 26, 2007 4:50 pm

I think you guys are still confusing global alarms with normal alarms. If you only want an alarm to run once within a single window, then you should be using a normal alarm within that window. Remember that using the #ALARM command to create a new alarm *will* create the alarm by default in the current window. So this will continue to work the way you expect.

What we are talking about here is global alarms that you add to some external package/module. This alarm would probably not be a "run once" alarm, but would be something that runs at an interval. You control which windows run this alarm by enabling/disabling the package that contains the alarm in each window.

But when multiple windows have access to the same global alarm, then that alarm is always going to run within each window that sees it. Doing a #T- in one window won't prevent it from running within other windows. If you need to do this, just use a variable and set it to 1 and then check that variable within the alarm to prevent it from running more than once.