Zugg Software :: View topic - [3.03a] Events as a substate of a trigger?

Posted: Tue Feb 17, 2009 5:08 pm

I was wondering why events were made into a new object instead of being a trigger type so that they could also be used as a substate of a trigger.

In many situations I'd love to be able to initially trigger on some text and then have a substate be an event. Not being able to do this forces me to have two identical searches for the text. One to raise the event and another to trigger the exact same text in a substate of a trigger.

Magician Joined: 17 Apr 2005 Posts: 496

Still an awesome idea.

Posted: Tue Feb 17, 2009 5:57 pm

I encounter many examples of where this would be useful, the one that stands out the most in my mind deals with the prompt. I replaced all my primary prompt triggers with one trigger which then raised an event for the other ones. However, I have a ton of triggers which use the prompt in a substate. And those had to be left as is since there's no way for an event to trigger a substate. It also meant I couldn't do any more optimization for the prompt such as setting the prompt priority low and using the "stop further processing" checkbox. If there's one candidate for doing such a thing, it is the prompt since I receive that line more than any other. But since I have to test for the prompt pattern in substates, I can't use that.

Posted: Tue Feb 17, 2009 6:33 pm

I guess I need a more concrete specific example of where this would be useful. Seems like you'd just create additional events with the same event name (but different ID values) and enable/disable them as needed by your other triggers. But I'm obviously missing something here.

Events were made into a different object because they are really more like a combination of a trigger and an alias. I might be able to add a new type of trigger state that would interact with an event object, but I'll need to understand what you are trying to do a bit more.

Posted: Tue Feb 17, 2009 6:39 pm

You can atleast disable futher processing on the prompt, use an event to change the triggers state, and using your other states enable or disable the on prompt event.

Posted: Tue Feb 17, 2009 7:27 pm

I'd assume the problem is just about waiting for some kind of event as part of a multistate trigger. You might have something like this:

#trig {First line of something} {blah}
#cond {HerbCheckHeartbeat} {now wait for the event "HerbCheckHeartbeat"} {waitforevent}
#cond {Last line of something {blah2}

The idea is that the second state will stay active until something - anything - raises the HerbCheckHeartbeat event. You could think of it as similar to creating a temporary event handler like you can create a temporary trigger. It's also a bit like the #waitsignal command, except you're waiting for an event. I can definitely imagine it being useful

Enchanter Joined: 09 Sep 2007 Posts: 605

But why you can't create the HerbCheckHeartbeat event handler and in it's body advance to the next state of your trigger?

Posted: Tue Feb 17, 2009 7:56 pm

Well, you can, but the whole idea of multistate triggers is to make something that'd otherwise be complex very easy. This suggestion would do that, so I think it's a good one.

Posted: Tue Feb 17, 2009 8:13 pm

hmm use a signal instead of an event?

#trigger {first condition} {script stuff
#waitsignal prompt
#state thistrigger 1} {manual}
#trigger {second condition} {more script stuff}

Posted: Tue Feb 17, 2009 8:52 pm

Fang nailed exactly what I was talking about.

For example:

An elephant tramples you
It breaks your right arm
It breaks your left arm
It breaks your left leg
4000h, 4000m

Ideally this would be done with a trigger for the first line, followed up by a substate which detects the Event Prompt. Starting in the first state and ending when I see the prompt, I enable a trigger which detects all the limbs that become broken (it's a variable number of limbs that are affected):

#trigger {An elephant tramples you} {#T+ trample_trigger}
#cond {Event: Prompt} {#T- trample_trigger}

The way I do it now is to check for the pattern of the prompt even though I already have a prompt event defined.

#trigger {An elephant tramples you} {#T+ trample_trigger}
#cond {\d+h, \d+m} {#T- trample_trigger}

The appeal of being able to do this by event is:
1) If I change the prompt I don't have to edit every single one of these substates.
2) I already have a prompt event defined
3) I'd like to make the prompt priority very high (low number) so that I detect it first and then disable further processing. I can't do that if substates need to detect it.

Like mentioned in another post, I could create yet another event setting to manually advance it, but that's messy and seems no better than just putting the text in the substate for detection.

I was thinking ideally Event would just be another drop-down menu choice for a trigger. That way you could have an event followed by a substate of another event or by a pattern. Or you could have a pattern trigger followed by an event substate. It'd be very flexible. That's why I originally asked why it was created as a separate object.

Wizard Joined: 22 Mar 2007 Posts: 2320

[edit] repeated what is already said

Magician Joined: 17 Apr 2005 Posts: 496

Also it allows you to collapse more complicated triggers/trigger sets into single states that can be used repeatedly. For example you might want to recognize an ATCP prompt as well as a normal text prompt, which you can't recognize in a single state currently (because they need to be different trigger types). But it's easy to raise a prompt event from both of them. Or you might need to do a lot of processing to make sure that it really is a line of the type that you're looking for, in which case you really only want to do that once per.

Wizard Joined: 17 Jun 2006 Posts: 1201

Why don't you just create another onPrompt event for all your disabling? I used to do the same thing you do, but with events I just created a separate onPrompt event and give it an ID like promptDisable. Then I just put in promptDisable the #T- trample_trigger and so on. Then when the elephant tramples you just enable #T+ trample_trigger and also the #T+ promptDisable, which will disable the trigger when onPrompt is raised and then disable promptDisable itself again. This of course is just what Zugg was saying anyway. Razz

Where my problem is concerning the scenario like yours where you are essentially creating a ton of prompt triggers as second states to triggers are those triggers I want to make sure are proceeded by and followed by a prompt. In that case I still have a lot of triggers like yours. It would be easier if I could retrieve line numbers then I could store the line number for the prompt line and check if it is one off from that trigger and so on. This is mainly for working against illusions.

Posted: Wed Feb 18, 2009 3:43 pm

Well, like I was saying in the previous post, if it comes down to having either one trigger but with a substate that duplicates an event and having both a trigger and an additional event then I'm going to go for the simpler one trigger. I like having everything self contained in one item (when possible). Having the first trigger enable the event for the prompt is simply manually doing the very definition of what a substate does.

Wizard Joined: 22 Mar 2007 Posts: 2320

Oldguy2, would a 'Within Lines' trigger state help you?

Posted: Wed Feb 18, 2009 6:23 pm

OK, I think I understand now. I will add some sort of WaitEvent condition to the to-do list. While I'm at it, I'll probably also add an actual #WAITEVENT command. I could have sworn that I already had that command, but apparently not.

Posted: Wed Feb 18, 2009 7:20 pm

Thanks Zugg, I appreciate your efforts on this.

Also, I was thinking how the other triggers work and I just wanted to provoke a bit of thought about the implementation.

Trigger substates can use various different criteria to limit or modify when they are tested, such as:
- For a certain amount of time (Duration)
- For a certain number of lines (Loop Lines)
- Not until a certain number of lines (Skip Lines)
- etc.

I don't want to multiply the quantity of work on this, nor do am I suggesting adding everything that is available for patterns. I do want to throw out that some of these types of limiters might be handy to have available with the events as well. If I were to pick one item I think would be the most helpful I'd say it is the 'Duration' type of limiter. For example, if the event doesn't occur after x ms, then the substate automatically advances. I'd be interested in others' thoughts on the matter.

Posted: Wed Feb 18, 2009 8:24 pm

I don't know duration is probably the only one that makes sense for Events... and even that can be handled fairly easily with an alarm.

Posted: Wed Feb 18, 2009 9:11 pm

You mean have a separate alarm trigger to reset or advance the event substate?

It'd be much more convenient to have the duration option built into the event substate. Of all the trigger substate options I use, I probably use duration about 90% of the time. Even if only to make sure it doesn't get stuck in a substate. You never know when you might miss the event for some reason and you wouldn't want it waiting an hour in the substate.

Wizard Joined: 17 Jun 2006 Posts: 1201

Posted: Thu Feb 19, 2009 4:59 pm

Sorry, but trigger substates are *not* going to get mixed into Events.

Posted: Thu Feb 19, 2009 5:45 pm

Wizard Joined: 22 Mar 2007 Posts: 2320

Aha. A #waitevent or something similar is exactly what I need for those mapping functions I was working on before. I can do an #OK and then do a #Waitevent onRoomEnter before I start playing with the room descriptions.

Posted: Fri Feb 20, 2009 6:25 am

I'd imagine that #waitevent will work like #waitsignal or #waitfor, but the script will continue after an event is raised. The WaitEvent condition will more than likely run the state's script and advance the trigger state when the event is raised like in my example above.

Posted: Fri Feb 20, 2009 3:23 pm