Non-\n\r Trigger Breaking

There is a problem in MUClient's (hey, I may as well be up to date) trigger
mechanism on lines that don't have a terminating \n\r and command echo.

Assume I have a simple hunger trigger as follows:


<trigger
enabled="y"
match="You are hungry."
sequence="100"
>
<send>eat food</send>
</trigger>


So, the mud is lagging a bit, or for some other reason only part of the line
"You are hungry." is sent. Meanwhile I'm sending commands as per normal.
Bold will resemble INCOMING data, while underline will resemble the Command
Echo, or OUTGOING data in the following example:


You are hany command hereungry.


MUClient will NOT execute the trigger in this case as one would assume it
would. However, if Command Echo is turned OFF, it works as per normal.

Nick, does MUClient somehow do triggering from the World's Output Window,
instead of from the incoming packets, and if so, could this possibly be fixed?
This bug actually occurs quite a bit for me, and I would like to see an end
to it. Thanks.

Dave

Yes.. Common problem. Nick, just a suggestion, maybe changing this behaviour so commands get sent, but do not actually display until 'after' a line break is recieved? That would still allow commands to be shown as they are being sent, but would eliminate this minor annoyance. While the option of only allowing command to show up on prompt lines is useful it has odd side effects that result in the command displaying not on the next line as expected (when you sent it), but often several lines later, this can be very confusing. Simply forcing the command to the next available new line (by itself) would solve both these problems.

As I commented elsewhere I think, if I delayed until a linebreak was received, then for prompt lines (ie. most of them) there would be a pause (which would be annoying) because the \n\r is part of the start of the line after the prompt.

That is, you would type something and hit Enter, but no echo would happen until a second later, which would make it look like the client was really slow.

There is also another problem. With the latest version if a line that should trigger occures without a newline, then not only does it not trigger sometimes if there is a delay in recieving new data or even when you type a command. As long as new data is coming in at a continuous rate everything works, but if the data 'ends' with a complete line and no LF is recieved it never triggers. I noticed this while idling yesterday and is probably why some people report their triggers not going off when they actually should have...

It is not something that may not have been noticed before, since most times channels activities, other people wandering through and even user commands, which do cause a firing if following the reception of that like immediately, all tended to keep the delay to a minimum.

Ok.. I am ammending my previous post.. Seems the trigger is going off but not always calling the scripts. :p

[sales] Kaster: any poison for sale?
HP: [1243/1243] CONC: [2473/2473]
[sales] Sparhawk: 234 int, 10k/vial
Your body clock is back to normal. <<<<<
[sales]: Kaster waves his hand in disapproval and goes 'bah'.
[sales] Sparhawk: try to find as good cheaper...
body clock
You begin concentrating.
Fri Aug 2 03:07:21 2002 Ex = 16416095>
Your blessing of Godspeed is lifted from your body.
xxXX Godspeed XXxx

The line above marked with <<<<< should have done:

Your body clock is back to normal.
xxXX Body Clock XXxx

However.. In the above case it failed to do so, but did play the ticking clock sound I had set. Thus the trigger worked, but somehow the script never got called. The trigger and script in question follow:

<triggers>
<trigger
enabled="y"
match="^Your body clock is back.*"
name="Body_Clock"
regexp="y"
script="PartyTellIt"
sequence="99"
sound="C:\My Documents\MUD Files\Clock Ticks Loudly.wav"
>
</trigger>
</triggers>


This is very odd... :p

I've made a note of this thread. I don't believe the latest version changes trigger matching, but - whatever.

There is a bug in 3.23 (the plugins version) where if one line caused multiple triggers to be invoked, and more than one called a script, then the additional scripts would not be called.

This was caused by the inadvertent re-use of a loop variable inside the script processing loop (added for plugins) - it is a wonder the program did not crash altogether.

This is fixed in 3.24. Sorry.

Just nice to know us Beta testers aren't going nutty: seeing spots, gremlins, and other imaginary delusions. :)

Thanks for looking into, and fixing it. :)

Quoting Shadowfyr's post on Wed 31 Jul 2002 11:42 PM:


I don't know if this is related but I have noticed this same type of non-newline trigger breaking with script tells.

I have a script that measures the time a MUCK takes to perform it's database save. When it's all done, the script reports how long the save took, using a tell(). I use a tell() because a note() makes an extra blank line. Since the tell() does not end with a newline, any text received after that would normally trigger a trigger, doesn't.

I should note some things:
- the text is displayed correctly, with the tell() on it's own line and the incomming text on it's own line.
- the trigger fails to fire because of a missing newline on the previous line.
- the trigger is not a RegEx designed to match a specific text, using ^.

I was about to fix this, but can't actually reproduce it.

Careful testing with debugging feeding in half-finished lines, and then using a world.tell, or typing a command, seems in each case to match a trigger on the previous line, whether or not it has a newline.

Update - there is a problem in the way that MUSHclient handles triggers IF you have "keep commands on the same line" checked (in versions 3.28 and earlier).

A line like this:


<5/5hp 100/100m 100mv 820xp> look


Where most is from the MUD, but "look" is something you typed, is considered to be an command line and not scanned for triggers.

However without the "look" it is considered a MUD line.

This is fixed in 3.29, so you should not keep having these inconsistent results.