Mudlet: GMCP/GA text being suppressed on login

This predates a fix I put in recently (since the 3.16.1 release version) to finally allow for the Server to negotiate telnet option 1 (ECHO) and take over echoing on the Mudlet screen of text that Mudlet sends to the Server back to Mudlet - so that, if done correctly, passwords that the user types into the Mudlet command line do not show on the main profile screen afterwards if they have the "echo what I type onto my screen" option set - so I am minded to discount that as a cause without more information.

Do you have any idea if this is a recent change or has Mudlet alway been like this?

To be honest it sounds like we are not resetting something that we should in our (void) cTelnet::reset() method - I just do not know (yet) what it might be - any ideas anyone...?

The only thing I would say is that if I disable the H_PRINT_PROMPT hook in master.c, the problem does not occur on 2nd login attempts, however, the fact that they show up the first connection with the hook enabled, but fail only on subsequent connections, despite the fact that the text is being sent to Mudlet, I have difficulty throwing the problem at the mud lib or driver. The fact that adding the n in the user name and password prompt cause Mudlet to display the prompt makes me think there's an issue in Mudlet. (i.e. this works: input_to("get_name", INPUT_PROMPT, "By what name do you wish to be known?n" ); but causes a line return after the prompt and input is then on the next line)

Also, we do not see this same issue on any other tested client (telnet, tintin++)

Does that help at all?

We have this issue on StickMUD too. @mfczureal and I spent a good many hours trying to get around it through the game, but it does feel like this one is Mudlet related.

Confirmed with LDmud 3.5.1 and Mudlet 3.17 - but this has been in Mudlet for quite some time. I am pretty sure I noted the issue somewhere before, but can't find it spontaneusly. Thanks for reporting the details!

Well what I have heard does sound like we are not resetting something when the Server disconnects - all we have to do is work out what is different the second time around and change it back to how it was the first time... :scream:

I tried recording a replay for comparison, but it is different than the original. First connection: Display is fine. Following connections: Display is off. Playing replay at this time: Also wrong display during first connection.

Here is an example of the behavior upon first login and successive logins. GA's being sent from the game.

I see this is marked still as "need more info". What can I provide to help you move this issue along? This issue is preventing us from moving forward with deploying GA into our production MUD and we'd really like to work with you guys on getting this fixed. Thanks

@SlySven ?

:thinking: Humm, a replay file might not be enough because it may not reflect the disconnect/reconnect behaviour - so I'll need to log into a MUD that does display this issue and monitor a few variables - I have some suspicions but live testing is really going to help. Can I get a login into either of your MUDs @mfczureal / @mpconley ?

Well, you've been on my mud recently troubleshooting the Discord thing, so try Darkwind? :)

Ah, but I didn't know that @mfczureal on GitHub was ZureaL on Discord. :wink:

You can try this issue by connecting to mg.mud.de:23

Login as a guest with name like gast then reconnect.

Just checking to see if there's been any follow-up on this? Still holding up our ability to implement GA in prod and I'd really like to be able to put this to bed. Thanks!

We need to get the need more info label off this and the high priority one back :)

Done! I'm not sure what @SlySven's plans for investigating this are though. If you can, try digging into Mudlet code as well to see where's it's going wrong.

I did try to look into this but I could not really be sure I was experiencing what you are reporting. I don't really get how the GA stuff works so am not sure how the IRE Bugfix stuff and all that factors into it all. I tried to log in to Darkwind but was having really weird things going on with the downloadable UI (which was getting installed both as a package and a module and taking an age to do so each time I started) TBH I could not tell whether I was having the problem you are reporting - I am not even sure I had all the knobs in the right position.

:thought_balloon: What I think would be helpful in the Mudlet side would be to have a temporary set of methods in the Host and cTelnet and possibly main TConsole and it's TBuffer instance that gathers and returns the state of all the possibly relevant bool flag members in those classes and have them report just after the login has completed (or when that different behaviour is shown with the prompts). This would be to see which flags are in a different state after the first login (where things are correct) and the second and repeated ones (where they are not) - I strongly suspect that one of those flags (at least) needs to be reset/set in cTelnet::reset() - like I found was necessary with the Host::mIsRemoteEchoingActive one that I recently added...

Thanks for looking! Ok, I'll give it a go then.

Not seeing it with mg

Not seeing it in Darkwind either (had to _really_ dig to find the connection info - please provide it in the report next time!)

Nothing in Stickmud:

Add the exact steps to reproduce the issue (preferably without having to trawl through character creation) and we'll have another look at this. Thanks guys!

Right now we have GA disabled in our prod and dev instances due to these issues. One of our admins is going to spin up a new instance of the dev MUD so that I can re-enable GA and can be an absolute playground for testing how GA works in LDMud. Should be up later this evening and I'll provide an update when it's ready

@vadi2 @SlySven Please use stickmud.com 7680 or the StickMUD link in Mudlet. Connect as a player OR to login as Guest type 'visit' on the login and pass the captcha. After you connect, you can lua disconnect() and repeat the above process. On the second connection and thereafter you will not see the 'Give your name' prompt as it was on the first connection until after you enter a player name or 'visit'.

The example you tried from mg does indeed display the defect just fine. Let me explain:

Notice how in the first connection attempt Wie heisst Du denn ("neu" fuer neuen Spieler)? is sent BEFORE you answer gast and only after answering that question you are asked Bist Du maennlich oder weiblich: - The rest of login procedure is irrelevant for this issue.

Now in all following attempts, you do not see the line Wie heisst Du denn before answering gast. Instead, you need to answer before seeing the question, and will then see both questions in the same line.

Got it, thanks!

:thinking: :confounded: :man_shrugging:

Ah, I have a sneaking suspicion that the status whenever GA is enabled or not is not reset upon reconnecting... so Mudlet still thinks its enabled, when the game has not enabled it yet (like mg.mud.de doesn't enable it until you type in gast).

When GA is not enabled, Mudlet waits a bit before giving up and showing the text, but with it on, it only shows the text when a GA comes. So here - GA never comes - Mudlet waits forever to show the text.

Let me know if this fixes the issue:

• linux: https://transfer.sh/guark/Mudlet-3.17.1-testing-PR2366-5f62ffd-linux-x64.AppImage.tar
• osx: https://transfer.sh/olHMX/Mudlet-3.17.1-testing-PR2366-5f62ffd.dmg
• windows: https://ci.appveyor.com/api/buildjobs/6adm501x5iimk8bn/artifacts/src%2Fmudlet.zip

hi @vadi2 this works for me on OSX with StickMUD. Thanks!

Nice. This fixes it on Mudlets side. A better fix would be to enable GA on connection right away (so you don't see No GA like in mg. Haven't tested stickmud)

So far we are enabling GA as soon as we confirm it is the Mudlet or Grapevine clients - otherwise, players could toggle it on if they need it. GA must not be handled well in some clients.

Technically GA is part of the NVT (Network Virtual Terminal) model i.e. something that a default terminal is supposed to provide as part of the half-duplex model that Telnet implies. Suppress Go Ahead is not an option that Mudlet ever agrees to, so actually the other end is required to provide GA signals. I hadn't fully realised this before...

This seems to improve the experience in connecting to mg.mud.de 👍

Comments on the need (or no need) for GA were discussed in #1252 a bit more in depth, and MG seems to work fine with Mudlet by just sending EOR instead of GA which seems obsolete.

Kebab pointed my attention to this issue and I would like to comment about GA/SGA a bit. I am not sure, where else, so be it here...

You are fully right. GA is a (historic) means of flow control. And unless SGA is negotiated, standard-compliant communication partners need to send GA when the other partner is allowed to send (i.e. nowadays probably after each output). But by the same argument, the partners must only send once they received a GA... (which nobody does I think)

From my point of view, the only reasonable way to deal with this and to be standard-compliant is to always negotiate SGA and get rid of the superfluous GA.

This is the reason I am not a friend of using GA as a means for prompt detection (marking of prompts). To do this, you need to enable Suppress-go-ahead to disable the GA as a means of flow control in telnet. Only then you could use it with some other meaning in the layer above telnet (marking prompts in MUD output). Even if you ignore the telnet standards here, you could otherwise get GA for prompts and eventually for a lot of other, non-prompt outputs).
One problem is, that there is no nice way to negotiate if a MUD uses GA for prompt detection.

Additionally, SGA is AFAIR intertwined with other telnet options like NOECHO mode and CHARMODE/LINEMODE. This inter-dependence complicates matters even more.

Morgengrauen uses EOR for marking of prompts if TELOPT_EOR is negotiated (it does not mark prompts otherwise) and does not fiddle around with SGA (because that would make the telnet negotiation behaviour of the mudlib significantly more complicated - in this case, the Mudlib has to take care of TELOPT_ECHO, TELOPT_SGA, TELOPT_COMPRESS and TELOPT_COMPRESS2 which I don't want to do, this is stuff for the driver) and leaves all the issues of flow control to the telnet machine of LDMud. That means, Morgengrauen has the default behaviour of MUDs using LDMud for GA/SGA.

Concerning the default behaviour of the LDMud I am currently not really sure, but @amotzkau could certainly tell more details about it.

The default implementation of LDMud is to give no indication about a prompt (that may have historic reasons, formerly the prompt was written before calling input_to, so the driver didn't have any indication what a prompt is either).

And LDMud uses SGA to indicate char mode, that has also history reasons. Without SGA the communication partners are urged to only speak when they have received the GA from the counterpart and signal with GA when they have finished speaking. So this sequence of 'command, GA - answer, GA' effectively constitutes a line-mode-style. And agreeing to SGA is then seen by many clients as char-mode, because the client is now free to send the characters as they are entered. And that's why SGA is not negotiated at the beginning.There is a LINEMODE telnet option that could do the same, but that is not as widely adopted by the clients as SGA.

In response to @SlySven that every server is required to send GA if SGA is not agreed to, that is technically correct, but that also means that the client is not allowed to send anything again, after having sent GA and not received GA. And the server would only be allowed to send a single response before having to wait for a user command again. Any out-of-band messages (events, actions by other users) must be buffered until the user did another command. No MUD client or server adheres to that, as far as I know.

Using GA for prompt indication would follow that old process (server finishes its response with GA, the last thing in the response is the prompt), but nobody does the rest of this process anymore, so that doesn't serve as a good rationale. And whenever SGA is agreed (so this does not concern Mudlet) GA shall not be sent and ignored when received. Therefore other clients might ignore the prompt indication in char-mode.