Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ MUSHclient
➜ General
➜ IRE muds: no linebreak at the end of prompt
IRE muds: no linebreak at the end of prompt
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
Posted by
| Cadari
(25 posts) Bio
|
Date
| Fri 29 Jun 2007 01:43 PM (UTC) |
Message
| 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. | Top |
|
Posted by
| Zeno
USA (2,871 posts) Bio
|
Date
| Reply #1 on Fri 29 Jun 2007 04:11 PM (UTC) |
Message
| Could you turn on debugging and show us the packets when it sends the extra line? |
Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org | Top |
|
Posted by
| KP
(24 posts) Bio
|
Date
| Reply #2 on Fri 29 Jun 2007 04:35 PM (UTC) |
Message
| 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:
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. | Top |
|
Posted by
| Cadari
(25 posts) Bio
|
Date
| Reply #3 on Fri 29 Jun 2007 04:38 PM (UTC) Amended on Fri 29 Jun 2007 04:42 PM (UTC) by Cadari
|
Message
| 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. | Top |
|
Posted by
| KP
(24 posts) Bio
|
Date
| Reply #4 on Fri 29 Jun 2007 05:17 PM (UTC) Amended on Fri 29 Jun 2007 05:23 PM (UTC) by KP
|
Message
| 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:
| Top |
|
Posted by
| Tsunami
USA (204 posts) Bio
|
Date
| Reply #5 on Fri 29 Jun 2007 05:52 PM (UTC) |
Message
| 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. | Top |
|
Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
Date
| Reply #6 on Fri 29 Jun 2007 09:27 PM (UTC) |
Message
| 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.
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| KP
(24 posts) Bio
|
Date
| Reply #7 on Fri 29 Jun 2007 09:49 PM (UTC) Amended on Fri 29 Jun 2007 09:53 PM (UTC) by KP
|
Message
| 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. | Top |
|
Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
Date
| Reply #8 on Fri 29 Jun 2007 10:04 PM (UTC) |
Message
| 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
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
Date
| Reply #9 on Fri 29 Jun 2007 10:07 PM (UTC) |
Message
|
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. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Cadari
(25 posts) Bio
|
Date
| Reply #10 on Sun 01 Jul 2007 09:59 AM (UTC) |
Message
| 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. | Top |
|
Posted by
| Worstje
Netherlands (899 posts) Bio
|
Date
| Reply #11 on Mon 02 Jul 2007 06:05 AM (UTC) |
Message
| 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>
| Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
36,380 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
top