I have a tricky problem related to #split and #echo.

[dzpao]

I've run into a tricky problem. I'm playing a game with tintin (yes, it's a Chinese game with utf-8 encoding). I used #split 0 1 and #echo to record some content I'm interested in and use them as my status bar. Whenever I'm in a multiplayer battle, a lot of content tumbles off the screen, and some of it runs inside my input line.

I know I probably need to provide a minimal working example to illustrate my problem, but when I try to simulate a battle scene with #loop and #tick outputting a lot of text, I can't catch the error anymore.

Maybe I should try #prompt, but I've done some wrapping of #echo before, and porting them to #prompt is not an easy task. I'm also analyzing the source code based on what I've observed and trying to make some changes to fix the problem, but apparently I haven't made any progress yet.

Anyway, please help me, if it is possible.

[scandum]

The most likely explanation is packet fragmentation. Have you tried setting #config packet_patch 0.5 ?

[dzpao]

I have set #config {packet patch} {0.8}, and it usually appears to be working properly.

[PACKET PATCH  ] [        0.80] Seconds to try to patch broken packets

I suspect that this problem is caused by incorrectly setting the current position of the cursor when updating the buffer. It seems to always update the latest text repeatedly to the bottom line of the screen, which is the place I should be using to enter commands. But if I stop updating the status bar, the problem gets better. The more often I update the status bar, the more likely the problem is to occur.

[dzpao]

I feel like when I write an alias that updates the status bar with #echo -2, and then if the server sends over two lines of text, and the first line of text is triggered by my trigger capture and calls the alias I just described, then the second line of text could easily run to the last line.

[scandum]

Another thing worth trying is to save all the changes to a variable and updating the status line all at once.

Also worth checking out if the problem persists with another terminal emulator.

Without an easy way to reproduce the problem there's not much I can do.