|
ReedN Wizard
Joined: 04 Jan 2006 Posts: 1279 Location: Portland, Oregon
|
Posted: Thu Jan 28, 2010 3:40 pm
[3.12] Sending text to Mud in error when done from an MXP Prompt trigger |
Prior to having an MXP Prompt trigger I had a normal pattern trigger that would raise the Prompt event when it saw a prompt. Recently I switched to having an MXP Prompt trigger which raises the Prompt event. This will not function properly because commands that were sent during the Prompt event (raised by the MXP Prompt trigger) fail to be sent properly. Strange things that I've seen when trying to do this are commands being jumbled together when they were meant to be sent sequentially, for example:
Command1
Command2
Command3
These three commands were on 3 separate lines and should be able to be sent sequentially just fine, but during an MXP trigger they'd be all jumbled together like this:
Command1Command2Command3
In addition to this the #sayp text that I'd print out would be jumbled in with the commands I'm trying to send and they wouldn't be received properly by the Mud.
This seems similar to to when I tried to do #say/#sayp statements in an ATCP trigger. Is there some limitation in Cmud that prevents printing and sending commands during an MXP Prompt trigger? |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Thu Jan 28, 2010 5:32 pm |
In general, MXP triggers are not designed to display any text on the screen. You can use the #SENDRAW command to send raw data to the MUD, but you shouldn't do anything that causes text to appear on the screen. The reason for this is that when running an MXP trigger, CMUD is still in the middle of processing the MXP tag. The original purpose of MXP triggers was to allow you to change the arguments of the MXP string before CMUD was finished parsing it. If you print any text at this point, it confused the MXP parsing engine.
As a temporary workaround, try raising your event in a short alarm. So within your MXP PROMPT trigger, try:
#ALARM +0.01 {#RAISE onPrompt}
and see if that helps. If this works, then it might be time for me to add the planned #QEVENT command which will "queue" an event for processing when CMUD returns to the main application thread. So let me know if the alarm trick works or not. |
|
|
|
ReedN Wizard
Joined: 04 Jan 2006 Posts: 1279 Location: Portland, Oregon
|
Posted: Thu Jan 28, 2010 5:54 pm |
I seem to run into this over and over again, first with ATCP and now MXP.
I'll give your workaround a try when I get back home from work tonight. |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Thu Jan 28, 2010 6:28 pm |
Yes, that is because both ATCP and MXP are low-level triggers happening in the middle of data parsing. This is exactly why normal text triggers are *not* "raw" triggers because this is the kind of problems you end up running into.
If you were using a command like #SAY or #ECHO to send text to the screen, these commands already "delay" the text display until CMUD is done with it's current parsing. But using #SHOW interrupts the parsing, as does the special commands like #SAYP or #SUB which attempt to modify the current line being processed. |
|
|
|
ReedN Wizard
Joined: 04 Jan 2006 Posts: 1279 Location: Portland, Oregon
|
Posted: Fri Jan 29, 2010 2:44 am |
Your code sometimes worked, but not in all cases. It had the additional negative side-effect of making it studder.
|
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Fri Jan 29, 2010 5:42 am |
I'll play with this again tomorrow if I have time, but when I was fixing the %mxp.data bug in the other post about the PROMPT MXP trigger, I was using #SAYP without any problem within the trigger. I'd suggest using #SENDRAW to send actual commands to the MUD. That will ensure that they don't get jumbled and confused with the screen output.
Also remember that you can use the Script Debugger window to see the Raw Output of commands that are actually sent to the MUD. Always use that to determine if commands are being sent in the correct order or not. The screen output is not necessarily reliable, especially within these kind of low-level triggers.
Finally, as always, if you continue to have trouble, please post the exact script so that we can all try to reproduce the exact problem. |
|
|
|
ReedN Wizard
Joined: 04 Jan 2006 Posts: 1279 Location: Portland, Oregon
|
Posted: Sat Jan 30, 2010 7:57 am |
I expected to still see this same issue in 3.13, but strangely I haven't experienced it. With the correction of the %mxp.data bug I was able to consolidate all my prompt triggers down to just the mxp trigger. I raise events in this trigger and those events do both #sayp and execute commands. However this doesn't seem to be an issue anymore.
|
|
|
|
|
|