 |
Securis
Newbie
Joined: 03 Nov 2010
Posts: 5
|
 Posted: Sun Jan 17, 2016 10:59 pm
Prompt trigger triggering "too soon"
|
For my MIP trigger (which I used on 3Kingdoms), in certain cases my prompt trigger triggers "too soon".
Perhaps this is best illustrated by this debug logging (newlines added for clarity):
| Code: |
c 3Kingdom |[1] 3Kingdoms Comline : start :
a 3Kingdom |look
j 3Kingdom >look
d 3Kingdom |[1] 3Kingdoms Comline : stopped
a 3Kingdom |
a 3Kingdom | -O-
a 3Kingdom | |
a 3Kingdom | -O-
a 3Kingdom | |/| | |
a 3Kingdom |Dark Forest (e,n,w) O-@-2-1
a 3Kingdom | /
a 3Kingdom |
a 3Kingdom |This part of the forest seems much darker and is much more eerie.
a 3Kingdom |You can hear the howling of wolves and the rustle of leaves. Perhaps
a 3Kingdom |you shouldn't stay here too long.
a 3Kingdom | There are three obvious exits: east, north, west
a 3Kingdom ]#K%31831008DDDe~n~w#K%31831038HABnoun~forest~forest~exa #N/search #N#K%31831060HAAnpc~Wolf~Small wolf~exa #N/say hi, #N/consider #N/kill #N#K%31831060HAAnpc~Wolf~Small wolf~exa #N/say hi, #N/con
f 3Kingdom |Pattern: #K\%(?:@MIP/Vars/mipcode)(\d{3})(\a{3})(.*) : (%1=008, %2="DDD", %3="e~n~w#K%31831038HABnoun~forest~forest~exa #N/search #N#K%31831060HAAnpc~Wolf~Small wolf~exa #N/say hi, #N/consider #N/kill #N#K%31831060HAAnpc~Wolf~Small wolf~exa #N/say hi, #N/con")
c 3Kingdom |[295] 3Kingdoms Trigger : start : Pattern "prompt_miptrigger" : //(?:^)?\#K\%(?:@MIP/mipcod...
d 3Kingdom |[295] 3Kingdoms Trigger : stopped
g 3Kingdom =[1;33m There are three obvious exits: east, north, west [0m
a 3Kingdom |sider #N/kill #NSmall wolf {2}.
|
Notice that the last line, "sider #N/kill #NSmall wolf {2}."
That should've been part of the prompt trigger. Instead, it's simply printed to the screen as is. So it seems like the prompt trigger fired earlier than I wanted it to.
This is the output with triggers turned off:
| Code: |
c 3Kingdom |[1] 3Kingdoms Comline : start :
a 3Kingdom |look
j 3Kingdom >look
d 3Kingdom |[1] 3Kingdoms Comline : stopped
a 3Kingdom |
a 3Kingdom | -O-
a 3Kingdom | |
a 3Kingdom | -O-
a 3Kingdom | |/| | |
a 3Kingdom |Dark Forest (e,n,w) O-@-2-1
a 3Kingdom | /
a 3Kingdom |
a 3Kingdom |This part of the forest seems much darker and is much more eerie.
a 3Kingdom |You can hear the howling of wolves and the rustle of leaves. Perhaps
a 3Kingdom |you shouldn't stay here too long.
a 3Kingdom | There are three obvious exits: east, north, west
a 3Kingdom ]#K%31831008DDDe~n~w#K%31831038HABnoun~forest~forest~exa #N/search #N#K%31831060HAAnpc~Wolf~Small wolf~exa #N/say hi, #N/consider #N/kill #N#K%31831060HAAnpc~Wolf~Small wolf~exa #N/say hi, #N/con
a 3Kingdom |#K%31831008DDDe~n~w#K%31831038HABnoun~forest~forest~exa #N/search #N#K%31831060HAAnpc~Wolf~Small wolf~exa #N/say hi, #N/consider #N/kill #N#K%31831060HAAnpc~Wolf~Small wolf~exa #N/say hi, #N/consider #N/kill #NSmall wolf {2}.
a 3Kingdom |Hp: 256/256 Sp: 178/170 Gp1: 0 Gp2: 0
|
Now, the same output but only with the "Raw input/output data" logging:
| Code: |
i 3Kingdom <<CR><LF>
-<ESC>[36;1mO<ESC>[0m- <CR><LF>
| <CR><LF>
-<ESC>[36;1mO<ESC>[0m- <CR><LF>
|/| | | <CR><LF>
<ESC>[32;1mDark Forest (e,n,w) <ESC>[0m <ESC>[36;1mO<ESC>[0m-<ESC>[33;1m@<ESC>[0m-<ESC>[35;1m2<ESC>[0m-<ESC>[35;1m1<ESC>[0m <CR><LF>
/ <CR><LF><CR><LF>
<ESC>[33mThis part of the forest seems much darker and is much more eerie.<CR><LF>
You can hear the howling of wolves and the rustle of leaves. Perhaps<CR><LF>
you shouldn't stay here too long.<ESC>[0m<CR><LF>
<ESC>[33;1m There are three obvious exits: east, north, west <ESC>[0m<CR><LF>
#K%31831008DDDe~n~w#K%31831038HABnoun~forest~forest~exa #N/search #N#K%31831060HAAnpc~Wolf~Small wolf~exa #N/say hi, #N/consider #N/kill #N#K%31831060HAAnpc~Wolf~Small wolf~exa #N/say hi, #N/con
i 3Kingdom <sider #N/kill #NSmall wolf {2}.<CR><LF>
|
What seems to happen is that Cmud receives the raw data (up until "sider #N/kill #NSmall wolf {2}.") and then receives the rest in the next buffer update.
So my question is, is there a way to 'delay' prompt triggers for a few milliseconds upon receiving data in case more is coming, or do they work only on buffer flushes?
Or is there anyone else who might have had this problem and found a (semi-) reliable way to work around it? It doesn't have to be pretty 
Thanks in advance! |
|
Last edited by Securis on Sun Jan 17, 2016 11:17 pm; edited 1 time in total |
 |
|
|
shalimar
GURU
Joined: 04 Aug 2002
Posts: 4702
Location: Pensacola, FL, USA
|
Posted: Sun Jan 17, 2016 11:16 pm
|
You could account for the fact that it is on more than one line in your pattern or with another trigger state.
I don't think #WAIT is likely to help much. |
|
_________________
Discord: Shalimarwildcat |
|
|
|
Securis
Newbie
Joined: 03 Nov 2010
Posts: 5
|
Posted: Sun Jan 17, 2016 11:18 pm
|
Edited the post with raw session input/output data. I think that's where the problem lies.
|
|
|
|
|
shalimar
GURU
Joined: 04 Aug 2002
Posts: 4702
Location: Pensacola, FL, USA
|
Posted: Mon Jan 18, 2016 12:01 am
|
Show us the trigger you use to capture it.
|
|
_________________
Discord: Shalimarwildcat |
|
|
|
Securis
Newbie
Joined: 03 Nov 2010
Posts: 5
|
Posted: Mon Jan 18, 2016 6:37 am
|
The capture regex:
| Code: |
| #K\%(?:@MIP/mipcode)(\d{3})(\a{3})(.*) |
|
|
|
|
|
Securis
Newbie
Joined: 03 Nov 2010
Posts: 5
|
Posted: Mon Jan 18, 2016 3:45 pm
|
As a follow up: I've confirmed that it's due to the trigger adhering to network packet boundaries.
When I capture some MUD traffic in Wireshark, I see that the network packet boundary coincides with the exact point that is excluded from the prompt trigger.
In my case, the packet's payload is 1024 bytes; everything that doesn't fit in that, is sent in a next packet.
When I eliminate some traffic (like turning off ANSI or disabling the map), everything fits within the same packet, so the triggers work perfectly. |
|
|
|
|
Securis
Newbie
Joined: 03 Nov 2010
Posts: 5
|
Posted: Mon Jan 18, 2016 4:47 pm
|
Well, I've seemed to work around it reliably.
Sorry that this has turned out into a monologue, but I'll post my solution here in the hope that it might be useful for someone else in the future.
For reference, this is the "broken up" MIP string:
| Code: |
#K%31831060HAAnpc~Wolf~Small wolf~exa #N/say hi, #N/con
<next network buffer>
sider #N/kill #NSmall wolf {2}.
|
In my case, luckily, the MIP protocol contains a 'length' parameter. The '060' in the header denote that 60 characters should follow in this MIP message.
That makes it rather trivial to check if we have a "broken up" MIP message (ie. %len(mipmsg) != expectedlength).
Once such a message has been detected, I can put the message back in the screen buffer using #SHOWP, and the next time triggers are evaluated, the trigger will trigger again, this time successfully and with the complete message.
| Code: |
#if (%len($mipCodeAndMsg) != $miplen) {
#SHOWP $unparsedMipString
#CMD refresh
}
|
Thanks for your time, and have a good one! |
|
|
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
