Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD General Discussion
kinnoinen
Beginner


Joined: 30 Jan 2005
Posts: 26

PostPosted: Wed May 06, 2009 11:38 am   

Own command breaks trigger pattern
 
I have a trigger like:

#trigger {^Your group consists of:} {#say blahblah}

But when that line is received from mud sometimes my own commands can come in the middle, so the output looks like:

Your group conslook
ists of:

And so the trigger won't fire. Ofc this can happen with any trigger. Is there any way to force triggers to ignore my own input? Atleast there should be. :) There is the "echo commands" option which can be switched off, but I'd really like to see all the commands that I send to mud.
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Wed May 06, 2009 5:00 pm   
 
This problem comes because of the way MUDs signal that a line is a prompt. Namely, that many MUDs don't. A normal line ends in the characters CR and LF, which collectively mean to start a new line. A line that's a prompt doesn't end with these characters, because you want your command to end up on the same line as the prompt and not on the next one.

There are characters that a MUD's supposed to use to signal that a line is a prompt - I believe you can use EOR or GA - but many MUDs don't bother. They just end the packet with no characters at all and expect the client to fill in the blanks.

The problem comes because breaks between packets can come at any time. They can easily be in the middle of lines, or in the middle of control codes, or anything. So if the MUD isn't using the proper characters to end the line, then CMUD has no idea whether or not there is more text to come on that particular line, or if it's a prompt. It decides that sending your command is more important than waiting for a packet that might never come, and that causes this problem.

There was talk about a few ways around this, but I'm not sure if anything was ever done about it. I know there were plans, when a MUD does end its prompts correctly, to force CMUD to wait until it receives those prompt-ending characters before it sends any commands, but I can't remember if that's been done yet or even if it's still part of the plan. And if your MUD isn't following the standard and isn't using those characters correctly, then that's not much help to you.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
kinnoinen
Beginner


Joined: 30 Jan 2005
Posts: 26

PostPosted: Wed May 06, 2009 9:17 pm   
 
But shouldn't triggers fire on text received from mud, not on text that is shown on screen? Could handle those two things totally separately.
Reply with quote
shalimar
GURU


Joined: 04 Aug 2002
Posts: 4662
Location: Pensacola, FL, USA

PostPosted: Wed May 06, 2009 9:38 pm   
 
USE #PRINT instead of #SAY or #ECHO if you dont want it to trigger your triggers

Oh i misread the problem... in such a scenario the only think i can think of... is dont send extra commands to the game if the last command you send is likely to fire triggers. or send them both at the same time before it can start doisplaying output
_________________
Discord: Shalimarwildcat
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Wed May 06, 2009 10:21 pm   
 
kinnoinen wrote:
But shouldn't triggers fire on text received from mud, not on text that is shown on screen? Could handle those two things totally separately.


But then that would cause problems when the unterminated line really is a prompt. For example, if you received LINE ONE<packetbreak>LINE TWO<CRLF>, you have no way of knowing if "line two" is meant to be appended to line one or not. If you're ignoring commands from the user, then you'll always assume that it isn't a MUD prompt, which would break a trigger with a pattern "^LINE TWO" and would also cause what seems to be a graphical problem, where a line is incorrectly appended to the prompt. It's a knotty problem.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
kinnoinen
Beginner


Joined: 30 Jan 2005
Posts: 26

PostPosted: Thu May 07, 2009 4:58 am   
 
I don't really understand what you mean... Of course line two is appended to line one if there is no CRLF. And those graphical problems happen all the time, that is not a problem, can make smart trigger patterns to match the start of line or after prompt (in the mud I play I often use ^{|* >}).

At the moment I just have the "echo commands" disabled and everything works fine, but sucks that I can't see what commands I send.
Reply with quote
shalimar
GURU


Joined: 04 Aug 2002
Posts: 4662
Location: Pensacola, FL, USA

PostPosted: Thu May 07, 2009 6:15 am   
 
#ONINPUT {(*)} {#WIN CommandLog %params}
_________________
Discord: Shalimarwildcat
Reply with quote
kinnoinen
Beginner


Joined: 30 Jan 2005
Posts: 26

PostPosted: Thu May 07, 2009 9:00 am   
 
That doesn't work so great either, because I can't scroll back the main window and see when each command was sent, which is needed if I want to debug some trigger's behaviour.

I guess I could log the main window and add my commands to the logfile with that #oninput. But meh.... not really a good way to do it. In my opinion the triggers should just fire from mud output.

Can run into same problems with multiline triggers, like if have a trigger: #trigger {^(*)$(*)$Obvious exits} {do stuff}
If you happen to send a command between the first line and "Obvious exits" then %1 or %2 will have the command in it and not the line that mud actually sent. So currently multiline triggers are basically useless, can't trust them.
Reply with quote
kinnoinen
Beginner


Joined: 30 Jan 2005
Posts: 26

PostPosted: Fri May 15, 2009 6:44 am   
 
I have talked with another mud client coder about this problem and now understand it a bit better. Seems that to completely fix this problem CMUD would have to use a different kind of regexp parser, a one that handles data one character at a time, or that the mud I play starts using GA. I don't expect CMUD to change its parser, so I'm OK with this.

But there is still definitely also a bug in CMUD that is clearly seen in multiline triggers. To clarify the example I wrote in last post, this is the normal mud output:

Hall of Gathering
You have difficulty moving around here
Obvious Exits: [north] [east] [west]

So to catch the room name I can do a trigger: #trigger {^(*)$(*)$Obvious exits} {RoomName=%1}

But if I happen to for example type 'east' between those lines then it gets screwed:

Hall of Gathering
east
You have difficulty moving around here
Obvious Exits: [north] [east] [west]

Which results in: RoomName=east

Or is this a wanted feature? :)
Reply with quote
Rahab
Wizard


Joined: 22 Mar 2007
Posts: 2320

PostPosted: Fri May 15, 2009 1:31 pm   
 
It is a desired feature because cmud has to be able to check your own mud commands to see if they fire triggers. So, cmud cannot ignore your commands to the mud.
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Fri May 15, 2009 2:19 pm   
 
Don't use a multiline trigger, use a multistate trigger. They're better than multiline in every way possible :P

Though for this particular problem, it might be better to use a single trigger on the Obvious Exits line, that then uses %line1 and %line2 to refer to the preceding lines.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
kinnoinen
Beginner


Joined: 30 Jan 2005
Posts: 26

PostPosted: Fri May 15, 2009 2:49 pm   
 
Rahab wrote:
It is a desired feature because cmud has to be able to check your own mud commands to see if they fire triggers. So, cmud cannot ignore your commands to the mud.


How do you make a trigger that fires from your own command?

#trigger {testcase} {#say matched!}
#send testcase

Nothing happens. So CMUD _can_ ignore your commands and normally it will.
Reply with quote
kinnoinen
Beginner


Joined: 30 Jan 2005
Posts: 26

PostPosted: Fri May 15, 2009 2:54 pm   
 
Fang Xianfu wrote:
Don't use a multiline trigger, use a multistate trigger. They're better than multiline in every way possible :P

Though for this particular problem, it might be better to use a single trigger on the Obvious Exits line, that then uses %line1 and %line2 to refer to the preceding lines.


I know my way around this particular problem just fine (an ansi trigger in this case), but don't you think there still is a bug?
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Fri May 15, 2009 4:27 pm   
 
There is a "Trigger on Commands" option in the Preferences to control whether a command fires a trigger.

When using a MultiLINE trigger, the trigger processor is just fetching the previous text lines from the screen and has no idea if a line on the screen came from the MUD or came from a command. It's all just text. That is why MultiLINE triggers are less useful than MultiSTATE triggers as Fang mentioned.

Also, now you are seeing why writing a completely trigger-based map parser is very difficult and why CMUD uses more of an AI routine that is already set up to handle cases like you are mentioning with commands coming in the middle of the text.
Reply with quote
kinnoinen
Beginner


Joined: 30 Jan 2005
Posts: 26

PostPosted: Fri May 15, 2009 5:43 pm   
 
Zugg wrote:
There is a "Trigger on Commands" option in the Preferences to control whether a command fires a trigger.


Ah my bad, didn't remember this one. :)
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD General Discussion All times are GMT
Page 1 of 1

 
Jump to:  
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

© 2009 Zugg Software. Hosted by Wolfpaw.net