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 ➜ General ➜ Trigger match failed for the sequential of wait.regexp() and Execute()

Trigger match failed for the sequential of wait.regexp() and Execute()

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

Pages: 1 2

Posted by

Zhenzh China (68 posts) Bio

Date

Sat 20 Jul 2019 04:38 PM (UTC)

Message

Sometimes, I find my trigger(whhich has successfully worked for hundreds times) doesn't work thought the output from the screen has matched the trigger. And it will get work again when a new line includes matched string comes.

I guess there may some issue during mush client pass the exact data to the trigger form back-end such as interrupted by some unexpected ASCII character.

Is it possible to print out those back-end data which is used for trigger matching before they are processed and shown in front-end screen by mush client?

Posted by

Fiendish USA (2,535 posts) Bio Global Moderator

Date

Reply #1 on Sat 20 Jul 2019 04:42 PM (UTC)

Message

Try: Edit menu -> Debug Packets

https://github.com/fiendish/aardwolfclientpackage

Posted by

Nick Gammon Australia (23,140 posts) Bio Forum Administrator

Date

Reply #2 on Sat 20 Jul 2019 09:32 PM (UTC)

Message

Template:version

Please help us by advising the version of MUSHclient you are using. Use the Help menu -> About MUSHclient.

See https://www.gammon.com.au/scripts/showrelnote.php?version=5.06&productid=0 -> point 13.

Also see: http://www.gammon.com.au/forum/bbshowpost.php?id=13797

- Nick Gammon

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

Posted by Zhenzh China (68 posts) Bio

Date Reply #3 on Sun 21 Jul 2019 04:45 PM (UTC)

Message

I have found out the root cause of my trigger issue. It should be caused by the new line not being separated.

Here's the data received when trigger works


Incoming packet: 450 (968 bytes) at 星期一, 七月 22, 2019, 12:24:53 上午

.[1;36m.........   1b 5b 31 3b 33 36 6d c4 e3 b4 f3 ba c8 d2 bb c9
................   f9 c1 a2 ca b1 ce e4 b9 a6 d5 d0 ca c6 c6 e6 bb
................   c3 ce de b7 bd a3 ac b5 b6 bd a3 d5 d0 ca c6 c4
......
0m )...[0;0m> ..   30 6d 20 29 0d 0a 1b 5b 30 3b 30 6d 3e 20 ff f9
................   c4 e3 b4 d3 cf d6 d4 da c6 f0 d3 c3 d0 fe cc fa
................   bd a3 b7 a8 d7 f7 ce aa bb f9 b1 be bd a3 b7 a8
...............[   b5 c4 cc d8 ca e2 bc bc c4 dc a1 a3 0d 0a 1b 5b
0;0m> ..           30 3b 30 6d 3e 20 ff f9

Incoming packet: 451 (40 bytes) at 星期一, 七月 22, 2019, 12:24:53 上午   (the line to be matched by the trigger)

................   0d 0a b5 d2 bf f8 ee b8 b5 b9 d4 da b5 d8 c9 cf
................   a3 ac d5 f5 d4 fa c1 cb bc b8 cf c2 be cd cb c0
........           c1 cb a1 a3 0d 0a 0d 0a

And here's the data received when the trigger doesn't work


Incoming packet: 13787 (583 bytes) at 星期日, 七月 21, 2019, 10:39:21 下午

...[0;36m.......   0d 0a 1b 5b 30 3b 33 36 6d c4 e3 b5 b1 d0 d8 c6
................   bd c6 bd b4 cc b3 f6 d2 bb bd a3 a3 ac ca b5 d4
................   da ca c7 ba c1 ce de c8 ce ba ce b1 e4 bb af a3
......
..............(    bd a6 b5 c3 c2 fa b5 d8 a3 a1 a3 a1 0d 0a 28 20
.......[0;31m...   d3 a2 ce ed bc b0 1b 5b 30 3b 33 31 6d d2 d1 be
................   ad cf dd c8 eb b0 eb bb e8 c3 d4 d7 b4 cc ac a3
................   ac cb e6 ca b1 b6 bc bf c9 c4 dc cb a4 b5 b9 d4
......[0;0m )...   ce c8 a5 a1 a3 1b 5b 30 3b 30 6d 20 29 0d 0a 0d
................   0a d3 a2 ce ed bc b0 b5 b9 d4 da b5 d8 c9 cf a3
................   ac d5 f5 d4 fa c1 cb bc b8 cf c2 be cd cb c0 c1
.......            cb a1 a3 0d 0a 0d 0a

Compare the two data, I find the match line "b5 b9 d4 da b5 d8 c9 cf a3 ac d5 f5 d4 fa c1 cb bc b8 cf c2 be cd cb c0 c1 cb a1 a3 0d 0a 0d 0a" which is expected to be a single line was not successfully separated to a new line by the mush client. Which may cause the trigger match failure.

How's the mush client judge a new line from data sent by the mud server?

Posted by

Nick Gammon Australia (23,140 posts) Bio Forum Administrator

Date

Reply #4 on Sun 21 Jul 2019 09:42 PM (UTC)

Message

Did you read this thread?

http://www.gammon.com.au/forum/?id=13797

It looks like your match is failing when there is an ANSI code in the middle of the packet: \[0;0m

Are you using Unicode (UTF8) or Big5?

- Nick Gammon

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

Posted by

Nick Gammon Australia (23,140 posts) Bio Forum Administrator

Date

Reply #5 on Mon 22 Jul 2019 06:13 AM (UTC)

Message

Zhenzh said:

How's the mush client judge a new line from data sent by the mud server?

When it gets a newline character (0x0A). Any wrapping you see on the screen is "soft" wrapping that should not affect triggers.

- Nick Gammon

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

Posted by

Nick Gammon Australia (23,140 posts) Bio Forum Administrator

Date

Reply #6 on Mon 22 Jul 2019 06:15 AM (UTC)

Message

Zhenzh said:

which is expected to be a single line was not successfully separated to a new line by the mush client. Which may cause the trigger match failure.

What do you mean by "successfully separated to a new line"?

- Nick Gammon

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

Posted by

Zhenzh China (68 posts) Bio

Date

Reply #7 on Mon 22 Jul 2019 04:10 PM (UTC)

Message

The word "separated to a new line" I mentioned may not accurate, it should be thought as a new incoming packet, isn't it?

As I pasted, the good trigger received the match line as a individual packet, head with "Incoming packet: 451 (40 bytes)", while the bad trigger merge the match line with previous output in one packet. That's the only difference I found between the good and bad cases.

I used to think that's the root cause. But I don't think so now. As I find no metter a match line in a new packet or not, both good and bad case may happen.

Posted by

Zhenzh China (68 posts) Bio

Date

Reply #8 on Mon 22 Jul 2019 04:18 PM (UTC)

Message

I'm using GB2312.

I have read the link http://www.gammon.com.au/forum/bbshowpost.php?id=13797 and find there is a plugin help to processing ANSI color codes. Seems it's for big5 only?

I have never considered the issue is caused by some ANSI color code. Though some color cod such as "[0;0m )" appear in my Chinese MUD, the line used for my trigger matching do not contain any color code.

Anyway, I can have a try to see if the color_remove plugin helps fixing such issue if a version supports GB2312 is available.

Posted by

Nick Gammon Australia (23,140 posts) Bio Forum Administrator

Date

Reply #9 on Mon 22 Jul 2019 10:05 PM (UTC)

Message

The client is designed to ignore packet breaks. The underlying TCP/IP system may break packets anywhere. Therefore there is a state machine that seamlessly handles data, whether or not it is in the same packet.

- Nick Gammon

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

Posted by Zhenzh China (68 posts) Bio

Date Reply #10 on Thu 25 Jul 2019 12:37 PM (UTC)

Message

After some test, I have isolated the issue.

The issue only occurs at trigger created by wait.regexp.

I have two triggers created for the test. One is manually created from trigger menu and the other is created by wait.regexp. The manually created trigger works every time while the wait.regexp trigger has chance get trigger failure.

I guess it may caused by the point of time the trigger is created.

I used to use wait.regexp like below:


Execute("say it is a test")
wait.regexp("it is a test")

The manually created trigger definitely exists before the match line coming. So it's able to work every time.

While the wait.regexp creates the trigger just after the match line is generated. There is a chance that the match line comes while trigger has not been created by wait.regexp.

Posted by

Zhenzh China (68 posts) Bio

Date

Reply #11 on Thu 25 Jul 2019 12:52 PM (UTC)

Message

I know using DoAfter over Execute() may be a work around to solve such issue. There still be a chance the wait.regexp can not create the trigger in time for some network issue.

Is there a better way to use the wait.regexp() to ensure the trigger will always be created before the match line generated by Execute()?

Posted by

Nick Gammon Australia (23,140 posts) Bio Forum Administrator

Date

Reply #12 on Fri 26 Jul 2019 06:17 AM (UTC)

Message

I can’t help thinking this is an XY Problem.

What are you really trying to do here?

You are saying “this is a test” and then afterwards you are making a trigger to detect that. Why not make the trigger before?

wait.regexp basically sets up a trigger.

- Nick Gammon

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

Posted by

Zhenzh China (68 posts) Bio

Date

Reply #13 on Fri 26 Jul 2019 06:55 AM (UTC)

Amended on Fri 26 Jul 2019 06:57 AM (UTC) by Zhenzh

Message

If do wait.regexp first, the script will be paused to wait the match line coming so that the next action, Execute() will not be happened until the regexp detecting the match line or timeout.

While the problem is the match line is generated by the action of Execute(). So the regexp will never be triggered as the action to generate match line is held by regexp itself.

Posted by Zhenzh China (68 posts) Bio

Date

Reply #14 on Fri 26 Jul 2019 07:10 AM (UTC)

Amended on Fri 26 Jul 2019 08:26 AM (UTC) by Zhenzh

Message

Such case may be happened in some MUD's job system.
User asks job npc some questions, and the npc reply you information about the job he will provide. Base on the answer of the npc, the user will decide the next action like go to some place or kill someone.

I my use case, it looks like:


Execute("ask harry about job")                                     <- this action will get the npc answer your question, in
                                                                      which job information is included. For example, the
                                                                      answer may be: Harry said: please go to the room 1.
l,w = wait.regexp("Harry said: please go to the room (.*)", 10)    <- in this step, I'd like to match the answer line and
                                                                      capture the room number.
Execute("go to room w[1]")                                         <- then do the next action based on the trigger capture

You can find if I do wait.regexp first, the action "ask harry about job" will be held as wait.regexp is waiting for the match line, "Harry said: please go to the room 1" coming. While the npc's answer will never come for the ask action has not been done.

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.

50,417 views.

This is page 1, subject is 2 pages long: 1 2

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

Go to topic: Search the forum

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