Width Negociation

I didn't have this problem with previous versions, but it would appear that with 4.94, Width no longer gets negotiated right?

http://i.imgur.com/DVHO86I.png?1


Note that I've checked other peoples' width, who aren't using MC, and their width stat is just fine: it doesn't appear to be the Code Base (PennMUSH)

Do you have "Negotiation about window size" checked in the output configuration? There was a bug fixed in 4.92 where it would turn NAWS on when the server queried if it was on or not. Now you have to make sure you turn it on in output configuration.

I... didn't actually realize that was a thing. It might be best suited to Default as 'on'. But that aside;

I wish I could state that was the problem. Even including closing connection and re-opening it, it would appear the problem persists:

http://imgur.com/loSxI4X

The wrapping column and window size aren't necessarily the same. The NAWS reports how wide the window is.

If you have NAWS option on, and then get IAC DO NAWS



Then it echoes the window size as it changes.

Like this:



A bit of testing reveals I had it backwards. It reports the wrap column not the actual window width. However it does report the actual window height.

Reporting column width is desired behavior, so that's fine.



-------------- MUSHclient summary --------------

MUSHclient version: 4.94
Compiled: Jul 28 2014.
Time now: Saturday, October 18, 2014, 1:50 AM
Client running for: 6d 13h 07m 53s
World opened for: 1d 11h 33m 35s
World connected for: 0d 10h 02m 16s
Operating system: Unknown (Platform 2, Major 6, Minor 2)
Libraries: Lua 5.1.4, PCRE 8.35, PNG 1.5.14, SQLite3 3.8.4.3, Zlib 1.2.8
World name: 'Eldar World Online - Inception', ID: 5883386224cafc62e73b4b4d
-- Scripting --
Script language: Lua, enabled: yes
Scripting active: yes
Lua sandbox is 127 characters, DLL loading allowed: yes
Scripting prefix: ''. External editor in use: NO.
Scripting for: 0.000441 seconds.
-- Triggers, aliases, timers, variables --
** Triggers: 0 in world file, triggers enabled: yes.
0 enabled, 0 regexp, 0 attempts, 0 matched, 0.000000 seconds.
** Aliases: 0 in world file, aliases enabled: yes.
0 enabled, 0 regexp, 0 attempts, 0 matched, 0.000000 seconds.
** Timers: 0 in world file, timers enabled: yes.
0 enabled, 0 fired.
Timers checked every 0.1 seconds.
** Variables: 0.
-- MCCP --
MCCP not active.
-- Plugins (Processing order) --
** Plugins: 0 loaded, 0 enabled.
-- Comms --
Connect phase: 8 (Open). NAWS wanted: yes
Received: 4719356 bytes (4608 Kb)
Sent: 202716 bytes (197 Kb)
Received 647 packets, sent 10 packets.
Total lines received: 50064
This connection: Sent 9 lines, received 161 lines.
Telnet (IAC) received: DO: 18, DONT: 0, WILL: 12, WONT: 0, SB: 6 [Telnet]
-- MXP --
MXP active: NO, Pueblo mode: NO, Activated: On command
MXP tags received: 96
MXP entities received: 8
MXP errors: 0
-- Commands --
Commands in command history: 1000
Speed walking enabled: NO. Speed walking prefix: #
Command stacking enabled: NO. Command stack character: ';'
Accelerators defined: 0
-- Miniwindows --
** Miniwindows: 0 loaded, 0 shown.
-- Output window --
Output pixels: width 1511, height: 561, font width: 8, font height: 15
can show 188 characters, wrapping at column 188, height 37 lines.
Output buffer: 4982 of 5000 lines.
-- Miscellaneous --
Logging: NO, tracing: NO
** SQLite3 databases: 0
Sound buffers in use: 0

---------------------- End summary ----------------------

You're welcome to look at the negociation that happens on the target game - but this is an issue both on M*U*S*H as well as the target game.

( twilightdays.org 2005 )

Guests can use 'th width(%#)' to see their own width.

By the way, that annoying bleeding in the output can be corrected by using a global preference -> General -> Bleed background colour to the edge. (Turn it off).

---

I turned NAWS on in the client, and connected.



The client is sending IAC WILL NAWS.

The server makes no response. Thus the client does not negotiate window sizes. It needs to respond IAC DO NAWS.



Then terminal sizes are sent.

See here for example:

http://mud-dev.wikidot.com/telnet:negotiation

The client can't just send telnet sequences without permission.

I'll check with PennMUSH folk and see why confirmation isn't being sent.

From the Link Provided by you:

----

If the server you are connected to makes use of the client window in ways that are linked to its width and height, then is useful for it to be able to find out how big it is, and also to get notified when it is resized.


>> That's pretty much it. Once the server has asked the client to do NAWS, and the client has confirmed it will, subnegotiation events come in with the window sizes. <<

It is worth noting that while clients like Putty will send these events immediately, Windows Telnet will only send it as it sends the next input from the user. This does not allow for the best user experience in terms of updated window contents, but it is better than nothing of course.

---

PennMUSH sends the IAC DO NAWS early. It should not need to send it afterwards.

No, it doesn't. I turned on packet debug, then connected. The only reference to NAWS was outbound (first packet):



After that, nothing. You can try, search the buffer for "1f" - it doesn't occur again.

What you can do is trick the client into thinking the server responded. In the Immediate window (Ctrl+I) enter this:



That is making it think the server replied IAC DO NAWS. Then it sends the window sizes.

After that, if I change the wrap column to 90, and do:



I get:



You could make an alias to do it for you:

Incoming packet: 3 (12 bytes) at Saturday, October 18, 2014, 5:45:34 PM

ÿý.ÿý.ÿû*ÿûF ff fd 18 ff fd 1f ff fb 2a ff fb 46

Note:
ff fd 1f
255 253 31
IAC DO NAWS


Full Log: http://pastebin.com/Z1NBQej7


---


In my previous post I pointed out that your following line doesn't make sense as per protocol:

---
The client is sending IAC WILL NAWS.

The server makes no response. Thus the client does not negotiate window sizes. It needs to respond IAC DO NAWS.
---

As it should be the other way around.
Does that matter at all?

I don't know if this is related, but activating window-size negotiation also seems to kill MC's ability to detect the Pueblo announcement string - or at least abiding to it.