This forum is a read-only archive of the Gammon Software forum (2000–2026). No new posts can be made. Search the archive.

IRE muds: no linebreak at the end of prompt

Posted by Cadari on Fri 29 Jun 2007 01:43 PM — 12 posts, 49,765 views.

Cadari #0
Hello, everyone. I'm experiencing a simple problem using MUSHclient with IRE muds, namely Lusternia. When you type something, say 'QL', the output looks like:

362h, 648m, 708e, 0p ex-The battleground atop Smoke Mountain.
You see exits leading northeast, southeast, south, and northwest.

Note the absence of linebreak at the end. If I do CONFIG PROMPT ADD LINEBREAK (Lusternia internal command), it starts behaving as it should:

362h, 648m, 708e, 0p ex-
The battleground atop Smoke Mountain.
You see exits leading northeast, southeast, south, and northwest.

Almost. Now everything else looks like:

538h, 648m, 708e, 0p ex-

You hold no "fink".
538h, 648m, 708e, 0p ex-

You hold no "fink".
538h, 648m, 708e, 0p ex-

I.e. it adds an extra linebreak, where it shouldn't. zMUD handles this situation correctly without any tweaking.

Any help would be appreciated.
Zeno USA #1
Could you turn on debugging and show us the packets when it sends the extra line?
KP #2
This seems to be a general problem with all IRE MUDs.
Instead of your solution, you could also use MUSHclient's own aid by enabling "Convert IAC EOR/GA to newline" under World Options -> Output, but that won't solve the 'spammy' empty lines. You could gag them, if you wish.

To go a bit into detail, I've spent some time looking at the way Nexus (IRE's own Java client) deals with that, and it seems that Nexus simply 'cheats' around it. Not only it appends your command to the prompt (thus creating the newline), it also caches the next command until the new prompt arrives. Basically, every response to a user-triggered action (like your 'QL'), comes without a newline in the beginning, but world events, like weather or attacks on you, come with a newline in front of them. Seeing that MC lets you send out multiple commands without waiting for response (which is a good thing), you will sometimes get two replies 'stuck' together. In your case, it seems that you completely omit your command from the output, thus creating no newline at all. My own solution was tinkering with incoming packets, exchanging GA for '\r\n' and removing the '\r\n' from the beginning of the packet. If you follow the same path, remember that some world events may come coloured, in which case there is an ANSI colour sequence before the newline.
Here is a regex that would always catch that newline:
 ^(\e[[0-9;]+m)*?\r\n

It was tested in perl, but should work with any other language too.

Maybe Tsunami, one of the most active people playing with IRE MUDs around here, has another idea.
Cadari #3
It happens only when you're sending commands fast. Not really ultra fast, just a bit faster than one per second - i.e. 90% of time.

1. EAST 2 times. Slow.
Output:

1235h, 878m, 878e, 0p ex-
There is no exit in that direction.
1235h, 878m, 878e, 0p ex-
There is no exit in that direction.

Packets:

Sent  packet: 186 (6 bytes)

east..             65 61 73 74 0d 0a

Incoming packet: 185 (96 bytes)

There is no exit   54 68 65 72 65 20 69 73 20 6e 6f 20 65 78 69 74
 in that directi   20 69 6e 20 74 68 61 74 20 64 69 72 65 63 74 69
on....[32m1235h,   6f 6e 2e 0d 0a 1b 5b 33 32 6d 31 32 33 35 68 2c
.[37m.[32m 878m,   1b 5b 33 37 6d 1b 5b 33 32 6d 20 38 37 38 6d 2c
.[37m.[32m 878e,   1b 5b 33 37 6d 1b 5b 33 32 6d 20 38 37 38 65 2c
.[37m 0p ex-..ящ   1b 5b 33 37 6d 20 30 70 20 65 78 2d 0d 0a ff f9

Sent  packet: 187 (6 bytes)

east..             65 61 73 74 0d 0a

Incoming packet: 186 (96 bytes)

There is no exit   54 68 65 72 65 20 69 73 20 6e 6f 20 65 78 69 74
 in that directi   20 69 6e 20 74 68 61 74 20 64 69 72 65 63 74 69
on....[32m1235h,   6f 6e 2e 0d 0a 1b 5b 33 32 6d 31 32 33 35 68 2c
.[37m.[32m 878m,   1b 5b 33 37 6d 1b 5b 33 32 6d 20 38 37 38 6d 2c
.[37m.[32m 878e,   1b 5b 33 37 6d 1b 5b 33 32 6d 20 38 37 38 65 2c
.[37m 0p ex-..ящ   1b 5b 33 37 6d 20 30 70 20 65 78 2d 0d 0a ff f9


2. EAST 2 times. Fast.
Output:

1235h, 878m, 878e, 0p ex-
There is no exit in that direction.
1235h, 878m, 878e, 0p ex-

There is no exit in that direction.

Packets:

Sent  packet: 189 (6 bytes)

east..             65 61 73 74 0d 0a

Sent  packet: 190 (6 bytes)

east..             65 61 73 74 0d 0a

Incoming packet: 188 (96 bytes)

There is no exit   54 68 65 72 65 20 69 73 20 6e 6f 20 65 78 69 74
 in that directi   20 69 6e 20 74 68 61 74 20 64 69 72 65 63 74 69
on....[32m1235h,   6f 6e 2e 0d 0a 1b 5b 33 32 6d 31 32 33 35 68 2c
.[37m.[32m 878m,   1b 5b 33 37 6d 1b 5b 33 32 6d 20 38 37 38 6d 2c
.[37m.[32m 878e,   1b 5b 33 37 6d 1b 5b 33 32 6d 20 38 37 38 65 2c
.[37m 0p ex-..ящ   1b 5b 33 37 6d 20 30 70 20 65 78 2d 0d 0a ff f9

Incoming packet: 189 (98 bytes)

..There is no ex   0d 0a 54 68 65 72 65 20 69 73 20 6e 6f 20 65 78
it in that direc   69 74 20 69 6e 20 74 68 61 74 20 64 69 72 65 63
tion....[32m1235   74 69 6f 6e 2e 0d 0a 1b 5b 33 32 6d 31 32 33 35
h,.[37m.[32m 878   68 2c 1b 5b 33 37 6d 1b 5b 33 32 6d 20 38 37 38
m,.[37m.[32m 878   6d 2c 1b 5b 33 37 6d 1b 5b 33 32 6d 20 38 37 38
e,.[37m 0p ex-..   65 2c 1b 5b 33 37 6d 20 30 70 20 65 78 2d 0d 0a
ящ                 ff f9


EDIT: Thanks for info, KP! I'll try to use your solution as well.
Amended on Fri 29 Jun 2007 04:42 PM by Cadari
KP #4
One more note:

If you dont want to mess with packets, just gagging the empty lines could create more trouble. Have a look at the last post in the following thread instead:

http://www.gammon.com.au/forum/?id=7916

EDIT:
Oh, and the forum software here messed up my regex a bit. ;]
It should look like this:
 ^(\e\[[0-9;]+m)*?\r\n

Amended on Fri 29 Jun 2007 05:23 PM by KP
Tsunami USA #5
Stripping the newlines from the beginning of packets is a great idea KP, wish I'd thought of it earlier. I'll be using it now! Previously I'd been gagging the first empty line, but this seems more efficient. I'll be adding it to my ATCP code.

I would hypothesize that the reason there is a difference between sending the commands slow and fast, is that if you send them fast, the server batchs the commands and assumes that both commands will have been displayed client side before the server response is recieved. Therefore, the second packet is prepended with a newline.
Nick Gammon Australia Forum Administrator #6
I am investigating this, meanwhile I suggest you look at this thread:

http://www.gammon.com.au/forum/?id=7716

The extra newlines could just be because you are seeing the "prompt" newline adjacent to the "MUD" newline.
KP #7
I think both solutions are equally good, if done right. And regarding the server responses, it doesn't seem that the server cares how many commands you have sent, its separate packets anyway. The only difference there is:

case 1: the action was user-triggered (you've sent a command)
-> the answer won't have a newline prepended.

case 2: the action was not triggered by you (someone moved/attacked/chatted, weather changed, you regained balance etc)
-> the answer will have a newline prepended (and maybe an ANSI colour sequence before that).

rare case 3: you've sent too many commands and got too much 'out of sync'
-> up to two answers will be 'glued' together in one packet.


Because of case 3, you have to exchange all 'GA's in the packet to '\r\n's. And there is another small trap. Max length for a packet is 999 characters (to be honest, I'm not sure if that is an IRE server limit or telnet limit, but it's definitely 999 chars on all IRE servers), so you might want to check the packet length and set some variable to "don't remove the newline from the next packet", if the length is 999 chars and there is no newline or GA at the end of it (the reason is self-evident I think). Just remember to check the length of the -original- packet, before you start removing ATCP stuff from it. The complete fail-safe psedocode would look like

SET dontremovethis = dontremovenext

IF LENGTH(packet) == 999 AND packet DOES_NOT_MATCH ('\r\n$' OR '{IAC_GA}$') THEN
  SET dontremovenext = 1
ELSE
  SET dontremovenext = 0
ENDIF

IF dontremovethis == 0 THEN
  REMOVE_PREPENDED_NEWLINE(packet)
ENDIF


I hope you get the idea.
Amended on Fri 29 Jun 2007 09:53 PM by KP
Nick Gammon Australia Forum Administrator #8
This plugin should remove a leading carriage-return/newline:


<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE muclient>

<muclient>
<plugin
   name="Remove_Leading_Newline"
   author="Nick Gammon"
   id="daf9ac419a5c05e082ea8d78"
   language="Lua"
   purpose="Removes a leading newline from a packet"
   date_written="2007-06-30 06:50:00"
   requires="3.82"
   version="1.0"
   >

</plugin>

<!--  Script  -->

<script>
<![CDATA[
function OnPluginPacketReceived (s)
  local col = string.match (s, "^\r?\n().")
  if col then
    return string.sub (s, col)
  end -- if starting with newline

  return s
end -- function OnPluginPacketReceived
]]>
</script>

</muclient>


What this is doing is looking for an optional carriage-return at the start of a packet, followed by a newline, followed by something else. The "something else" is designed to allow packets which are simply newline packets through (eg. blank lines in a help listing).

If found, it strips the carriage-return/newline from the start and returns the modified packet, otherwise the unmodified packet is returned.
Nick Gammon Australia Forum Administrator #9
Quote:

And there is another small trap. Max length for a packet is 999 characters (to be honest, I'm not sure if that is an IRE server limit or telnet limit, but it's definitely 999 chars on all IRE servers)


You could batch together packets until you get a newline - a plugin I did a while ago did that. This may cause other problems - you may not see your prompt, however if prompts always have the IAC_GA in them, this may not be a big deal.
Cadari #10
Great thanks for all the input to everyone. Now it'll be fixed, for sure :) Just didn't have spare time to try it yet.
Worstje Netherlands #11
This is a common issue. I have written a plugin (heavily inspired from these forums, so I am not sure for how much of it I can take claim) several years ago. Basically, it involves triggering the prompt, triggering the empty line that follows it and gagging that. It 'solves' dirty hacks (in my opinion, anyhow) of doing things on the packet-level.

Looking at the plugin as I wrote it for Aetolia, I realize some function names are in need of 'nicifying' since they were literally stolen from another plugin that I may or may not have written. Oh well. :) Use it as you see fit.

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE muclient>

<muclient>
<plugin
   name="PromptCleanUp"
   author="Mygale"
   id="2d63e3c55b2faec463c4e891"
   language="Lua"
   purpose="Fixing blank lines directly after a prompt."
   save_state="y"
   date_written="2007-02-28 21:34:19"
   requires="3.70"
   version="1.0"
   >

<description trim="y">
<![CDATA[

While the Configuration, Output, "Convert IAC EOR/GA to new line" setting makes
it possible to trigger on the prompt in MUSHclient, it also creates extra blank
lines as a by-product. This plugin fixes that.

Note: The option "Regular Expressions can match on an empty string", which can
be found under the "Global Preferences" General tab needs to be checked for
this plugin to work.

]]>
</description>

</plugin>

<triggers>
 <trigger
  enabled="y"
  keep_evaluating="y"
  match="^H\:([0-9]+) M\:([0-9]+) E\:([0-9]+)\% W\:([0-9]+)\% B\:([0-9]+)\% [(.*?)]"
  regexp="y"
  script="SetPromptStats"
  sequence="0"
 >
 </trigger>
</triggers>
<triggers>
 <trigger
  keep_evaluating="y"
  match=".*"
  name="got_other_line"
  regexp="y"
  script="GotOtherLine"
  group="prompt_cleanup"
  sequence="2"
 >
 </trigger>
 <trigger
  match="^$"
  name="empty_line"
  omit_from_output="y"
  regexp="y"
  script="GotEmptyLine"
  group="prompt_cleanup"
  sequence="1"
 >
 </trigger>
</triggers>

<!--  Script  -->

<script>
<![CDATA[

function SetPromptStats(name, line, wildcs)
	world.EnableTriggerGroup("prompt_cleanup", 1)
end

function GotEmptyLine(name, line, wildcs)
	world.EnableTriggerGroup("prompt_cleanup", 0)
end -- GotEmptyLine

function GotOtherLine(name, line, wildcs)
	world.EnableTriggerGroup("prompt_cleanup", 0)
end -- GotOtherLine

]]>
</script>

</muclient>