stop \r also echoing \n

[quentinnuk]

I am using a MU* that uses \r as a line ending to make a carriage return (CR) to allow for simple ascii animation and other simple effects like a spinner. Mudlet seems to always do \r->CR LF rather than \r->CR which messes up the output. EG:

Code: Select all

Attempting buffer overrun against port 90...  
/ - \
 | / -
 \ |
 / - \
 | /
 - \ |
 / -
 \ | /
 - 

Whereas, on telnet this would be a spinner at the end of the first output line.

Is there a way to get Mudlet to display this kind of behaviour as intended?

[SlySven]

Technically no, not as the Server sending that data intends as Mudlet - because it is a GUI client - does not allow the Server to change anything that it has previously sent and which Mudlet has subsequently processed (through it's trigger engine and then displayed in the main console). Hopefully the Server is not just sending \r as that is a Telnet no-no. Either it should be sending \r\n (Carriage-Return followed by Line-Feed) or \r\0 (Carriage-Return followed by Null). Anyhow Mudlet cannot do that - draw something on the screen and then remove it and replace it with something else - and the Server should not be assuming it can {it should know what type of client it is talking too and behave accordingly}.

OTOH Does the Server offer Go-Ahead (or End-Of-Record) signalling - if it does - and it puts one of those after each of the different characters that it is animating then clients like Mudlet (and indeed TinTin++) can use that to know that it can immediately display the text it has received without waiting for a timeout (used to be 0.3 Seconds on Mudlet but it can now be tweaked to be between 0.05 and 0.5 seconds) to detect that no more characters are due and to go ahead and draw the text. After that it is relatively simple to manipulate the Mudlet display to fake the effect with a trigger that detects those individual characters and then manually remove the previous one and replace it with the next one on the same line.

In the absence of GA/EOR signals such a trigger might still work but it won't be as reliable or seamless as those timeouts will prevent the detections of each animation character in time if they are sent more rapidly than one every twice that timeout...

I cannot think of the exact formation of the trigger to do this but I have seen one at least on here or in our Discord Guild...