13 Nov, 2015, SlySven wrote in the 61st comment:
Votes: 0
Can I ask (again) about the meaning of Proxies {"Client is a proxy allowing different users to connect from the same IP address."}? What does this mean - is users a reference to:
  • multiple different (presumably Human) individuals using the "Client" as a concentrator (my initial impression) so that say, the Client is on multi-user machine (a *nix box) with one IP address and more than one player is logged into it and using the same client to connect to the same Mud simultaneously {seems a bit unlikely, but hey, this Universe is probably big enough for this to be possible}.
  • The same person running more than one "Character" on the Mud Server (so called Multi-playing) at the same time, via multiple logins to that Server.
The second case seems more likely to be possible in practice, it is certainly something that both Clients I am familiar with can do {TinTin++, Mudlet} but if that is what is meant; at what point does it become something to report via MTTS: EITHER on login of the first character as an advisory of a general capability of the Client even though it is not (yet) active; OR on login of the second or subsequent character to ANY Mud Server as an advisory of, well something; OR on login of the second or subsequent character to THE SAME Mud Server as an heads-up of, multi-playing?

Also, what happens if there is a state change in the Client that changes this or other values - e.g. the number of "Users"/"Characters" drops down to unity, or a Screen Reader is activated after login or there is a change in Utf-8 support by virtue of the Client's user changing something whilst logged in. Is the Client to initiate a "IAC DONT TTYPE" renegotiation?
14 Nov, 2015, Tyche wrote in the 62nd comment:
Votes: 0
I believe it means the client is a proxy like the TMC web client.
26 Nov, 2015, SlySven wrote in the 63rd comment:
Votes: 0
Ah, so it IS like somewhat like the first of the two possibilities I posited - in hindsight that actually starts to make sense given the context of that there TMC thingamabob…! smartas
26 Nov, 2015, quixadhal wrote in the 64th comment:
Votes: 0
It's fairly common these days for people to embed telnet clients into their web sites, but unless you do something clever, that means the MUD sees all connections made from that web page client as coming from the address of the web server, not the address of the actual player's browser.

I know there's a patch for at least one java telnet client that will pass an extra parameter to a dead souls mudlib based MUD containing the client's IP address, so the MUD can correctly display that instead of the connection's address.
09 Dec, 2015, Griatch wrote in the 65th comment:
Votes: 0
As a server developer not using standard C-snippets (Evennia uses Python), finding out what is actually used in the telnet swamp is really hard. The tintin++ homepage is one of the few good collected resources on some of the mud-specific things (and while the supported for them in the wild is in itself unclear, this is part of why I use tintin++ as a baseline for testing telnet).

Evennia has its own html5 webclient which is exempt from all of this (it uses our own JSON-based protocol), but we support telnet in parallel. For example we implement MTTS as described on the tintin++ page, including the screen reader instruction. The client info obtained this way very much informs what kind of features a given connection enables. But TTYPE is fiddly and even so we have just had to assume at least ANSI-color support as a standard fallback since so many clients simply don't do TTYPE whatsoever.

As for clients, we assume people use the latest versions of a given client and currently hard-code exceptions for a bunch of clients that we can identify and which, according to their homepages, support xterm-256 even though most of them don't bother actually reporting such specifically. Even so I know there are still weird behavior in the handshakes with several clients.

As server devs we try to stay aligned with standards as much as possible (whenever such standards are even discernable). And when it comes to Evennia users (mud developers/coders) they are generally quite accepting of the fact that some clients are simply crap when it comes to standards and should not be used.

But as mentioned in this thread, the client will not be blamed when a old-time player connects and finds an Evennia-based game not working well with their non-standard-abiding but trusty telnet client. We (as in the Evennia devs) really feel a need to try to set up a grid of more formal testing against legacy/modern telnet mud clients to really iron out some of the issues we see, probably with custom exceptions. This is still something on the agenda. It's mainly a devtime/resource/motivational issue - we get surprisingly few complaints on it since most new evennia users just seem to do all their testing in the web client anyway.