Trigger causes text to display out of order
KildClient is a powerful MUD client with a built-in Perl interpreter
Brought to you by:
ekalin
Menu
▾
▴
#43 Trigger causes text to display out of order
If a trigger is used to highlight text, the text will be displayed before other text appearing at the same time.
Example:
A trigger is set to highlight the pattern "^2" (highlight a line starting with '2').
Suppose the game displays this text:
- Go north.
- Go south.
- Go east.
But Kildclient will display this instead:
2. Go south.
- Go north.
- Go east.
I couldn't reproduce this.
To look further, I'd need the exact trigger definition. The easiest way would be to use the "export" function.
My trigger is one in a series of triggers. The operative trigger in this example is the middle one named "My action" intended to put my own game actions in a different color:
I believe it's important that the game prints the multi-line text in a single "output" blob, a single message. In this example, I have created an object whose description has multiple lines of output:
This particular MUCK recognizes the {nl} tag to mean "new line" to force a line break in the text.
So, when the player looks at the item, four separate lines of output are sent to the client all at once. The lines that are printed, however, are misordered:
I hope this is helpful in demonstrating the problem.
I still can't reproduce. You could try only with "My action" enabled, as it seems to be the only one that is relevant, but I don't think it's going to make a difference.
The only think I can think of is that the server is doing something funny with the newlines and maybe they aren't really newlines. You could try using the --rawdump command-line option to capture what the server sends.
I have determined that this is an interaction with the "channels" plugin. If I disable that plugin, I no longer see this misordered text behavior.
I had not done any configuration of the channels plugin. I was intending to learn more about how to use it effectively, so the plugin was enabled, but no hooks or triggers had yet been set up to use it.
So, for some reason, enabling this plugin causes text to be delivered out of order when a trigger matches it.
That plugin adds a trigger that captures every line and supresses normal processing, instead passing lines through the plugin.
The exception are your own triggers, which are processed normally and never reach channels. (By default after a trigger matches no further triggers are tried.)
Nevertheless, I suppose that processing of Perl scripts in response to triggers should not alter the order in which lines are processed. But it's probably not an easy fix, and I don't know when I'll be able to look at this problem.
I've looked again at this issue and, as mentioned before, the problem is that channels adds a trigger that captures every line, suppresses normal processing, and feeds it to a Perl function (that in most cases prints the line). Your trigger is run before the channels trigger, and it only changes the styling of the line, which is printed using the regular line-processing code (that is, receive the line and print it.)
(The fact that it's a highlight is not important - the same problem can be seen with a trigger that sends something back to the server, or even a trigger that uses Perl, as long as it's not a gag trigger.)
Some years ago some big changes were made to make KildClient more responsive by using multiple threads. This unfortunately can add some concurrency problems such as this one. Not having to use Perl as a trigger action means that the line matched by your trigger finishes processing earlier and is printed out of order.
Unfortunately changing that would require some very extensive and complicated changes, so I'm marking this as won't fix. But there is a workaround, even if you need the channels plugin or a similar functionality : if you use Perl in your trigger, it'll use the same processing pathway as the other lines, and everything will be in proper order again.