Mudlet: Repair isPrompt() for EOR detection

[Kebap]

I was informed by friendly MUD admin, who does not use the Telnet "Go Ahead" (GA) command for marking a prompt. They instead use "End of Record" (EOR) for over 25 years now.

Unfortunately, Mudlet can only recognise GA, so isPrompt() will not work for this MUD. Would be great if IsPrompt() can receive new optional parameter to inform which kind of prompt should be detected. For example IsPrompt("EOR") and if no parameter is given, IsPrompt() will behave like IsPrompt("GA") to keep backward compatibility.

[SlySven]

Does that MUD admin arrange for their MUD to also negotiate for _Suppress Go Ahead_ RFC858 when it negotiates for _End Of Record_ RFC885? I can see that we will acknowledge requests from the MUD server for HIM to use both when sending to US (despite us not gating our response to SGA according to how Host::mFORCE_GA_OFF has been set instead we just ignore incoming ones when we should actually tell the Server what we are doing with that one..! 🤦‍♂️)

Also both these protocols ("Suppress {i.e. do not __use__} Go Ahead" and "Use End of Record") are usable in both directions - but Mudlet does not send them.

As it happens both incoming GA and EOR commands are detected near the top of (void) cTelnet::processTelnetCommand(const string& command) and that sets the (bool) cTelnet::recvdGA flag which in turn triggers code at the C++ code label MAIN_LOOP_END: to - if enabled by mFORCE_GA_OFF NOT being set - inserts a 0xFF character into the text data and then executes cTelnet::gotPrompt(...) which is some horribly structured code involving a goto to jump to a point inside a loop that cannot be reached otherwise:

void cTelnet::gotPrompt(string& mud_data)
{
    mpPostingTimer->stop();
    mMudData += mud_data;

    if (mUSE_IRE_DRIVER_BUGFIX && mGA_Driver) {
        //////////////////////////////////////////////////////////////////////
        //
        // Patch for servers that need GA/EOR for prompt fixups
        //

        int j = 0;
        int s = mMudData.size();
        while (j < s) {
            // search for leading <LF> but skip leading ANSI control sequences
            if (mMudData[j] == 0x1B) {
                while (j < s) {
                    if (mMudData[j] == 'm') {
                        goto NEXT;
                        break;
                    }
                    j++;
                }
            }
            if (mMudData[j] == '\n') {
                mMudData.erase(j, 1);
                break;
            } else {
                break;
            }
        NEXT:
            j++;
        }
        //
        ////////////////////////////
    }

    postData();
    mMudData = "";
    mIsTimerPosting = false;
}

Such twisty stuff is one reason to let someone else code it - see my #1235 !

[vadi2]

I think what @SlySven is trying to say is that we already handle EOR as a end of prompt marker. What game is this?

[SlySven]

I think what @SlySven is trying to say is that we already handle EOR as a end of prompt marker.

We do _sortof_, but not _properly_ IMHO.

[zesstra]

Sorry for being so late to comment on this, but I was travelling a lot during the last month. I am one of the admins of said MUD and can give you some details about the behaviour.

First, my knowledge of Mudlet's prompt handling is a few years old and also originates from a discussion with one of the authors back then, who told me that EOR is not supported and he regards it ancient and not proper (though not quite in this words, I think). It may well have changed since then. ;-)

In Morgengrauen we send EOR at prompts if the client agrees to it. After connecting, we will offer sending EOR by sending WILL TELOPT_EOR to the client. Only if the client responds with the confirmation DO TELOPT_EOR sending of EORs is activated. If the client does not respond to it or responds by DONT TELOPT_EOR, no EORs are sent at prompts. Of course the client can also preemptively request EORs with DO TELOPT_EOR, which the mud confirms with WILL TELOPT_EOR.

However, since the client does not transmit any prompts, we also ask the client NOT to send EORs itself by sending a DONT TELOPT_EOR to the client (which the client may or may not answer with WONT TELOPT_EOR). Of course the client can also preemptively announce not sending EORs with WONT TELOPT_EOR, which the mud confirms with DONT TELOPT_EOR.

Concerning go-ahead: GA is/was a means of flow-control in half-duplex connections. Since all telnet connections in the internet are full-duplex, nowadays there is never a need to send a GA. The MG mudlib therefore does never emit them (and the gamedriver itself does not do so as well).

I am happy to answer any questions and/or discuss, but my answers may take a few days...

[vadi2]

Hi!

Nothing's changed - both GA and EOR are valid means to signal to the client that the prompt is complete. Many MUDs implement GAs and that is what Mudlet currently utilises on for its prompt detection. We'll investigate the possibility and the consequences of supporting EOR as well.

Thanks for your response!

[zesstra]

Ah, a small addition: Normally I would also negotiate SGA at the start of the connection (since we don't send GAs).
However, we don't do it (and just don't send them) to prevent clients from assuming we would then send GAs for prompts, since I suspect that many would assume that. Whats your pick on this? Do Muds which negotiate SGA then send GA for prompts?

[Kebap]

Reviewing the comments above, isPrompt will not receive optional parameters like originally suggested Instead it should already recognize both GA and EOR style prompts.
For some arcane reason, the EOR is not recognized in the above case however. So that is a bug then. Renaming this issue.

[vadi2]

What is a game where this can be tested?

[Kebap]

Test at: mg.mud.de
Game is German
Log in as guest with
gast
m or w
Speed up intro with: welt
Some commands to trigger prompt: info, schau, aus, tanz, wink

[Kebap]

Did you have a success in testing this or would you require additional support?

[vadi2]

Have not looked into the issue yet - got distracted with the regressions we've had.

[Kebap]

For some reason, this seems to work now. Putting a prompt trigger (select from dropdown) will correctly identify this game's prompt as such. Not sure if game changed or some recent Mudlet change influenced this behavior. Do you have any idea? Looking forward to closing this issue, at best after some explanation is given, for other games to learn from, etc.

[Kebap]

Game did not change anything.

[vadi2]

We didn't change anything in Mudlet either in regards to this :(

[vadi2]

EOR is recognised as a prompt for at 5 years now, according to code history: https://github.com/Mudlet/Mudlet/blame/75114831751e973c553b656015742552b85ddee9/src/ctelnet.cpp#L535

I've logged into that game and the prompt pattern is indeed working right on the > - so I think we can close this.