Zugg Software :: View topic

Newbie Joined: 19 Oct 2008 Posts: 8

On the MUD I'm on (Medievia) there are natural disasters that last for a certain period of time and during which one must be careful not to try to walk around etc., or else you take damage.

I therefore set out, about 4-5 hours ago, to set up what I thought would be a pretty standard simple multistate trigger to set a variable to true when certain text is received, and then after 5 seconds of not receiving any such text, reset the variable to false. (Then I could test this value in other triggers to not do something that would cause me damage until the value became false.)

Well, as I said, that was 4-5 hours ago and I am not getting predictable results, so let me just ask how any of you would do this, so that I might learn whatever it is I am not getting.

I simply want a something (I dont care if it's a trigger or some other command or function or w/e) that will set a variable to true (1) when any of several matching patterns is received from the MUD. When this happens I want to start counting down from 5 seconds, and if another match comes in before the timer goes to 0, reset the timer to 5 again. Once the counter makes it to zero, unconditionally set the variable to false (0).

How can I do this? Please, someone, help?

Thanks,
Mandelbrot, aka Lee

Sorcerer Joined: 13 Jan 2006 Posts: 715

How about this: (Slapped together in a few seconds, so you'll need to pattern it properly and make sure I didn't forget anything)

NOTE: This uses generic disaster strings off the top of my head... edit the variable to be correct for your patterns. This is a 1 trigger fits all disasters setup.

Newbie Joined: 19 Oct 2008 Posts: 8

I'm trying to understand what this is doing and it's just not making sense to me, so I am hoping you can walk me through the logic of it. I realize there's a typo wrt matching brackets but that's not why I am confused, I just don't understand how this works.

The trigger appears to contain an alarm which waits 5 seconds and then sets the variable DisYesNo to 0 (I guess, or null?) and then immediately to 1.
I'm not sure if you defined the trigger pattern in a seperate variable for the sake of making the trigger more tidy, or for some necessary functional reason.
I don't understand why DisYesNo is set again to {} in the next to last line.
And then it looks like this thing of setting "the default class" to 0 happens, also a mystery to me.

I am seriously questioning my cognitive abilities at this point. This is all completely opaque to me for some reason.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

A walkthrough of what Ralgith posted is pretty simple. I will of course correct the extra brace on the way. First let me say that the entire thing is meant to be entered into the command line, and creates an entire section of script.

#CLASS {Disasters}
Creates the class "Disasters" and sets that class as the default. When a class is the default all new settings will be created in it, and references to existing settings will try to use that location first.

#TRIG {{@NatDis}} {
#ALARM "DisOn" {+5} {#VAR DisYesNo {}}
#VAR DisYesNo {1}
}
Creates the example trigger. I will go into more detail on this later.

#VAR NatDis {The ground shakes in a massive earthquake!|Debris flies through the air as a tornado tears through the countryside!|Water thunders deep inland from a monstrous tsunami!}
#VAR DisYesNo {}
Creates both variables used with this script. One is for the trigger pattern and the other is a storage variable. As a storage variable it would be better to set it to have a default value, which would make the better script line be:
#VAR DisYesNo {} {}

#CLASS 0
Returns the default class to the root. This is just proper as that is where the default is when a session is first loaded. Having the default someplace else tends to cause havoc with variable assignments, which leads to multiuple variables with the same name.

Now to the details of the trigger:
#TRIG {{@NatDis}} {
The pattern used indicates that any of the items in the list NatDis should be a match. I think Ralgith did it this way because the editting display for a list variable is much easier to work with then trying to put all those things into the small pattern box.

When the pattern is matched these script items are preformed:
#ALARM "DisOn" {+5} {#VAR DisYesNo {}}
Creates a temporary alarm that will activate 5 seconds later. The script of this alarm clears the variable. This make a suitable toggle that can be used like '#IF (@DisYesNo) {script}'. Once the alarm fires it deletes itself.

#VAR DisYesNo {1}
Sets the variable to state that evaluates to true. Again this occurs when the trigger is matched. The combination of the alarm and this line is what makes the variable true for 5 seconds after the trigger fires.

Basically he created an example to meet your requested specifications.

Sorcerer Joined: 13 Jan 2006 Posts: 715

Vij missed one essential point here, if the 5 seconds are not yet up and the trigger fires again, it resets the ALARM back to 5 seconds instead of creating a new one. That's why it is a named alarm, because otherwise I just use unnamed alarms.

He is also completely correct when he says that I used the variable because it is easier. It also allows something like this from the command line:
#ADDITEM NatDis "A chasm opens at your feet and lava erupts into the air as a new volcano is formed"
To add to it without opening the settings editor.