I've noticed that sometimes when my perl-scripts crash, any text that come in after the crash won't be displayed once I remove the error-message displayed by MUSHc, unless I'm really fast removing the error-message.
This isn't very good, I can accept that the text on my screen isn't correct when these things happen, but I'd very much like my logs to be correct when it comes to the world-output at least, and this bug affects the log too.
It should be fairly easy to reproduce this bug:
<world-input>
aaaaaaaaaaaa
bbbbbbbbbbbb
cccccccccccc
dddddddddddd
eeeeeeeeeeee
ffffffffffff
</world-input>
<perl-script>
sub crash {
die("I've crashed!");
}
</perl-script>
As you can see, entire lines disappear, which isn't too hot. Is there a way to avoid this right now, and if not, would it be possible to implement something? (My current MC is v3.42, fyi.)
I can't reproduce this. Using your "crash" subroutine, and sending the lines you specify, and matching on the "bbbbbbbbbbbb" line, and colouring it (and calling the script) I see this in the output window:
It is possible that you need to input more data than just the few lines I provided, and wait for that data to arrive before removing the error-message. If more data isn't enough, I'll look into duplicating the error and describing it step-by-step, allright?
My gut-feeling for this error is that something prevents MC from reading and handling new packets/data properly while the error is displayed, causing some of the older packets/data to be dropped as some buffer somewhere fills up. Is that possible?
I guess I could have a dodgy version of perl, but even if I did it seems strange that it would have this effect on MC's displaying and logging.
In a glorious new twist, I've discovered a new 'feature' I'm getting from this bug. It's displacing text in a strange fashion, it's like some of the text that comes after(in the same packet) as the text that causes the error-message will not get displayed until after I click away the error-message, while other text coming in a bit later(in another packet?) will be shown.
Right now, it's rather late over here, but if you're having trouble making sense of this issue right now, leave it until I make another post. I'll whip up a detailed step-by-step tomorrow, for clarity.
I've got it a perfect way to reproduce the bug I'm having now, along with a pretty good guess of what's happening. :)
Allright, so forget anything I wrote previous to this, the bug doesn't actually -loose- any text per-se, but it -displaces- the text in a strange fashion!
Allow me to demonstrate! This all takes place on a linux-box using telnet, a trick you taught me earlier I believe. :)
<main.txt>
aaa
bbb
ccc
</main.txt>
<main2.txt>
111
222
333
</main2.txt>
The trigger is on 'bbb', calls Crash, which is a sub in a perl-script.
<Crash>
sub Crash {
die("I've crashed.");
}
</Crash>
Input the following command, in one line.
cat main.txt;sleep 1s;cat main2.txt
The error will occur, but do not click it away until you've seen it output main2.txt on the screen. You will get output somewhat similar to this, after removing the error-message.
This differs from the output you'd expect:
aaa
bbb
ccc
111
222
333
And I'll tell you why! It seems likely(ie, I'm guessing..) that MC takes each incoming packet, grabs the data and starts processing every full line it can out of that packet against it's triggers, and if something bad happens(the script returns an error), it pauses output to tell you this. Then, a moment later, another packet arrives, and while the output from the previous packet is still frozen, the second packet's data is processed and outputted! Then once you click away the error-message displayed, the first packet's data-processing resumes, causing it's lines to be printed after the lines contained in the second packet, thus messing up both the display and log!
I hope this helps in finding the bug, and I very much hope it's possible to fix it in a way that won't cause the text to be displayed and logged erroneously. :)
Making the error-message 'non-blocking' might be the best solution, to prevent a flood of text just being crammed down the screen once the error is dismissed, if it has been left there for say, an hour or more.
I had a similar problem a while back, where if an error box was open strange things happened. What I think happens is that while the error dialog is visible the program puts it into a different thread, and then when another packet arrives from the network it calls the main processing routine, which - in your case - still has more work to do from the original packet.
I'm not sure of a sure-fire fix - considering I didn't actually write this "put it into a thread" code, but which comes with the MFC libraries that MUSHclient is written with.
However what will probably work quite well it would be to do one of these two things:
* put error messages like this into a separate place, eg. a notepad window, like is done with MXP errors; or
* put script error messages into the main output window - however this still might cause problems in the sense that you may get the error message in the middle of an incoming line.
It might be worth commenting that the problem goes away if you don't have script errors, so a debugged script shouldn't cause too many issues like this.
I suppose what wouldn't be too much work would be to offer the option to users:
1. Keep current behaviour
2. Use notepad window
3. Use output window
Properly-debugged scripts are a sound idea in theory, but since I'm doing this in my spare time, just for the fun-factor these scripts will give me, I'm not willing to dedicate the time to really debug the scripts I make. They can end up rather complex, and I'll debug them when I see the bugs, otherwise I'll just leave it alone.
A choice of outputting the errors to a notepad-window sounds perfect. It won't be quite as readily apparent when something goes wrong, but if it's a conscious choice on the behalf of the user to get this behaviour, that won't be a problem. I would really like to see that.
The bug aside, I have to say that I've been very impressed every time I've posted questions to this board, the replies are prompt and factual. It's really very nice, and if I had to choose, I'd name that as the 'feature' that really drove me to register. :)