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:
Code:
# 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.
