Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ Bug reports ➜ Non-\n\r Trigger Breaking
Non-\n\r Trigger Breaking

It is now over 60 days since the last post. This thread is closed.     Refresh page

Posted by Dave   Australia  (93 posts)  Bio
Date Sat 13 Jul 2002 08:59 PM (UTC)
Message
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
Top
Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #1 on Sat 13 Jul 2002 10:31 PM (UTC)

Amended on Sat 13 Jul 2002 10:32 PM (UTC) by Shadowfyr

Message
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.
Top
Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #2 on Thu 01 Aug 2002 12:33 AM (UTC)
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #3 on Thu 01 Aug 2002 07:42 AM (UTC)

Amended on Thu 01 Aug 2002 07:50 AM (UTC) by Shadowfyr

Message
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.
Top
Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #4 on Fri 02 Aug 2002 (UTC)

Amended on Fri 02 Aug 2002 12:02 AM (UTC) by Shadowfyr

Message
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>
sub PartyTellIt (name, output, wildcards)
  dim temp, temp2
  temp = world.getvariable("InParty")
  temp2 = Replace(name, "_", " ")
  'world.note name
  'world.note temp2
  if temp = "True" then
    world.send "party tell xxXX " & temp2 & " XXxx"
  else
    world.colournote "#FFE188","#0","xxXX "& temp2 & " XXxx"
  end if
end sub


This is very odd... :p
Top
Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #5 on Fri 02 Aug 2002 05:35 AM (UTC)
Message
I've made a note of this thread. I don't believe the latest version changes trigger matching, but - whatever.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #6 on Sun 04 Aug 2002 01:59 AM (UTC)
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #7 on Sun 04 Aug 2002 03:43 AM (UTC)
Message
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. :)
Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top
Posted by 1of10   Canada  (54 posts)  Bio
Date Reply #8 on Sun 29 Sep 2002 12:14 AM (UTC)

Amended on Sun 29 Sep 2002 12:19 AM (UTC) by 1of10

Message
Quoting Shadowfyr's post on Wed 31 Jul 2002 11:42 PM:
Quote:
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...


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 ^.
One of Ten
Secondary Adjunct of Unimatrix Z03
Top
Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #9 on Wed 23 Oct 2002 06:02 AM (UTC)
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #10 on Sun 27 Oct 2002 08:51 PM (UTC)
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

33,515 views.

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home