Trigger Timing

  • Parnassus
  • Topic Author
  • Offline
  • Administrator
  • Administrator
More
6 years 3 months ago #5422 by Parnassus
Trigger Timing was created by Parnassus
This is one of my picky questions.

I'm working on what I call my "Interactive Fiction" series. These are zones that aren't actually playing zones (although even my non-IF zones aren't exactly known for their playability!) but are different ways of telling stories. The first zone is sort of like watching a play. There are suggestions to go certain directions or do certain things. If the suggestions are followed, you can watch the play from beginning to end.

These zones were originally built on a smaug mud so the triggers don't transfer over and the building style is simpler than a TBA zone would be. So now, here's the problem.

Because this is a play, there is often a situation like this:
Char1: statement1
Char2: response1
Char1: response2
Char2: response3

On smaug, mobs can use tells so the responses are triggered by the mobs sending tells to each other. Since that doesn't work here, they're triggered by the sentences themselves. As in most of my triggers, I fit as many as possible into one vnum (which I call portmanteau triggering) so all the responses are in the same trigger with the trigger phrase in "if %speech%" instead of in trigedit-arg.

Now things get weirder (if possible). I need to put waits in to give the trigger time to catch up or something. I prefer not to put the waits in because the prompts break up the look of my play. Anybody got any suggestions for me? I thought the triggers worked fast enough that I wouldn't need to wait 1 sec between responses.

Please Log in or Create an account to join the conversation.

More
6 years 3 months ago #5423 by Krell
Replied by Krell on topic Trigger Timing

This is one of my picky questions.

On smaug, mobs can use tells so the responses are triggered by the mobs sending tells to each other. Since that doesn't work here, they're triggered by the sentences themselves. As in most of my triggers, I fit as many as possible into one vnum (which I call portmanteau triggering) so all the responses are in the same trigger with the trigger phrase in "if %speech%" instead of in trigedit-arg.


You could have MOBs set global variables on each other to make sure the correct responses are given to the correct MOB.

Now things get weirder (if possible). I need to put waits in to give the trigger time to catch up or something. I prefer not to put the waits in because the prompts break up the look of my play. Anybody got any suggestions for me? I thought the triggers worked fast enough that I wouldn't need to wait 1 sec between responses.


I know this is a style preference but personally I don't like the wall of text Smaug, ROM et al present when a MOB, or a couple of MOBs are speaking. I find the pauses more natural, still it is weird that dg requires the minimum 1s pause. Apparently the interpreter isn't very speedy.

Please Log in or Create an account to join the conversation.

  • Parnassus
  • Topic Author
  • Offline
  • Administrator
  • Administrator
More
6 years 3 months ago #5425 by Parnassus
Replied by Parnassus on topic Trigger Timing
Actually, I'm not so fond of the wall of text myself. However, the trick is to use colour codes to break it up.

This is how it looks with wait 1 sec:
Char1: statement1

>promptpromptpromptandsoonandsoforth:
Char2: response1

>promptpromptpromptandsoonandsoforth:
Char1: response2

>promptpromptpromptandsoonandsoforth:
Char2: response3

>promptpromptpromptandsoonandsoforth:

This is how it looks with colour codes:
Char1: statement1

Char2: response1

Char1: response2

Char2: response3
>prompt

I find the prompts tangle in with the lines and detract (and distract) from the feel. I'm considering using Smaug-type colours too, to make the conversations stand out a bit more.

I think if the lines without pauses move too fast for the trigger to identify the lines, globalling veriables would probably have similar timing. I'm going to be trying various formats of triggers to see if some are faster than others or if changing the order of the lines would make a difference. I was just hoping that there was something I was doing wrong and that someone had a trick to make it work.

Please Log in or Create an account to join the conversation.

More
6 years 3 months ago #5427 by Krell
Replied by Krell on topic Trigger Timing

I think if the lines without pauses move too fast for the trigger to identify the lines, globalling veriables would probably have similar timing. I'm going to be trying various formats of triggers to see if some are faster than others or if changing the order of the lines would make a difference. I was just hoping that there was something I was doing wrong and that someone had a trick to make it work.


I think dg is slow parsing displayed strings to and from the room. For example, TRIGEDIT-ROOM-ENTER says "...if you want the actor to see the trigger in the room you must use a wait." I have some MOBs on my test MUD and I use a room trigger to modify their arrive/depart strings and I have to use wait or the actor already in the room can't see the strings.

Though I'm not certain, I think setting variables and checking for them may be fast enough.

Please Log in or Create an account to join the conversation.

  • Parnassus
  • Topic Author
  • Offline
  • Administrator
  • Administrator
More
6 years 3 months ago #5428 by Parnassus
Replied by Parnassus on topic Trigger Timing
Actually, what I'm thinking now is that I'm probably overthinking things. For instance, why do they need to actually reply anyway? Fake replies would be much faster and easier. The only problem I can think of, offhand, is that if the person who walked in kills the person who was supposed to be replying, that would look spooky!

Please Log in or Create an account to join the conversation.

More
6 years 2 months ago #5448 by Krell
Replied by Krell on topic Trigger Timing
I've had a thought. MUDs send specific characters to indicate eol to a client so that the client knows to draw a prompt. If you could figure out what Dikus use you could probably keep the prompt from appearing during the conversation your MOBs are having, even with the waits. Then when your MOBs are done talking you could turn the prompt back on.

Just a thought.

Please Log in or Create an account to join the conversation.

  • Parnassus
  • Topic Author
  • Offline
  • Administrator
  • Administrator
More
6 years 2 months ago #5449 by Parnassus
Replied by Parnassus on topic Trigger Timing
I think its possible to %force% a prompt on or off but that seems invasive to me. Also, I think prompt is a toggle so I'd hate to turn it on instead of off. It's actually one of the things that I was considering.

Please Log in or Create an account to join the conversation.

More
6 years 2 months ago #5452 by thomas
Replied by thomas on topic Trigger Timing
I think I need to clear up a few misunderstandings here.

The parser for DG is actually very fast. The reason for needing a wait on a TRIGEDIT-ROOM-ENTER trigger is that the actual triggering happens BEFORE the player is moved into the room. The reasoning behind this is that the room enter trigger can prevent the move (by returning 0). This would not be possible if the trigger triggered after the move. This means that you need a "wait 1 s" statement so that the move can take place, then you can send to the char[1].

Using a common trigger for all your dialogue, you're running into a different - but related - problem. Some types of triggers cannot trigger if they're already running (to prevent infinite recursion). Adding a short wait statement solves this[1], in that waits allow other scripts to run, and so means the mud won't actually hang even if multiple scripts trigger each other.

There are some ways around your problem, the first being the simplest: Don't trigger multiple triggers off of each other. Instead, use the available "behind the scenes" data to make it plausible. Here's a pseudocode example:
# find my co-actor
set inroom %actor.room.people%
while %inroom%
  if %inroom.vnum% == 1234
    set coactor %inroom%
  end
  set inroom %inroom.next_in_room%
end
if !%coactor%
  say Oh my god, they killed Kenny!
  halt
end
say Kenny, you ok?
%force% %coactor% say Mmmf!
say At one point Kenny even polymorphed the guy into a blue frog...it was total carnage.
%force% %coactor% say Mmmf!
...
This will accomplish what you want, and still prevent a dead guy from speaking.


[1] The current code for "wait" allows three documented forms, "wait until hh[:]mm", "wait X s" and "wait X t", the last being X mud hours. A fourth option would be nice, to avoid the long wait on room entry. Something along the lines of "wait X c" (for cycles), of which there are 20 a second.
This already works, and is an undocumented feature.
The following user(s) said Thank You: Parnassus

Please Log in or Create an account to join the conversation.

  • Parnassus
  • Topic Author
  • Offline
  • Administrator
  • Administrator
More
6 years 2 months ago #5456 by Parnassus
Replied by Parnassus on topic Trigger Timing
Thanks for the explanation and the pseudocode.

[1] The current code for "wait" allows three documented forms, "wait until hh[:]mm", "wait X s" and "wait X t", the last being X mud hours. A fourth option would be nice, to avoid the long wait on room entry. Something along the lines of "wait X c" (for cycles), of which there are 20 a second.
This already works, and is an undocumented feature.


Sorry, this confused me. Would it be nice or does it already work? I don't think I've heard of the t for mud hours so that's interesting to me also.

Please Log in or Create an account to join the conversation.

More
6 years 2 months ago #5457 by thomas
Replied by thomas on topic Trigger Timing
it works already.

Actually all forms of "wait x y" where y != t and y != s means "wait x cycles" due to the way it is implemented.
But, let's stick with "wait x c" so we don't break it in the future ;)

Please Log in or Create an account to join the conversation.

Time to create page: 0.119 seconds