New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GMCP/GA text being suppressed on login #2286
Comments
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 |
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... 😱 |
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. |
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 ? |
🤔 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. 😉 |
You can try this issue by connecting to Login as a guest with name like |
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. 💭 What I think would be helpful in the Mudlet side would be to have a temporary set of methods in the |
Thanks for looking! Ok, I'll give it a go then. |
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 Now in all following attempts, you do not see the line |
Got it, thanks! |
🤔 😖 🤷♂️ |
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 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: |
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). 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. |
Brief summary of issue / Description of requested feature:
We have enabled GMCP and attempting to enable GA using LDmud 3.3.495. In order to make this happen in LDmud you have to enable the H_PRINT_PROMPT hook in the lib's master.c and provide the lib with the functions to print to the screen, which includes forcing the Go Ahead prompt. This function is working just fine in the player object and in Mudlet, you can see the GA section increment.
The first time we connect to the mud, our username and password prompts are displaying properly, but if you quit the mud and without restarting Mudlet, hit the reconnect button, none of the prompts are displayed to the users. I did a packet trace and I DO see the username prompt delivered to the client, but Mudlet will not show the prompt. To add complexity, if I take that same username/password prompt and add an \n at the end of the prompt, Mudlet WILL show it, but for some reason, it's not printing without forcing a line return (which is not something I want to do on a user-input).
Steps to reproduce the issue / Reasons for adding feature:
Error output / Expected result of feature
The Username and Password prompts are not printed on the screen, but the user can input their user name and password in the blind. Once both fields are input, Mudlet will display the cached prompts
Extra information, such as Mudlet version, operating system and ideas for how to solve / implement:
If we post-pend the prompts with \n, Mudlet will display the prompts properly, but forces a carriage return, which is sub-optimal. Mudlet should be able to print the prompt normally as it does the first time we connect to the MUD.
I have done a packet trace and confirmed that the prompt is being sent to Mudlet, it's just not displaying the prompt. I have also posted a screen shot in Discord in the #help channel.
Using Mudlet 3.16.1 on Windows 10
The text was updated successfully, but these errors were encountered: