Mudlet: IRE server does not negotiate for MXP

That might explain the original code - but they could be not the only ones, and we can't break things by default and add workarounds for every game out there.

True; however, then the problem will fall back on Evennia and other MUD games that do negotiate for it too, @vadi2 :laughing: so you might be playing with the hot potato. :man_shrugging:

According to Evennia, mushclient works for them! It might not have to be a choice.

Interesting. so we just default MXP to be on going forward? (and to put comment somewhere in there to reference this issue...)

Well, no, we have to find a solution that works for both Evennia and IRE. For Evennia not to escape <> before MXP is negotiated and for IRE to somehow make MXP work without them negotiating it.

This is the hard thing we've gotta do. Users don't care if it works on one or another, they want Mudlet to just work :man_shrugging:

maybe create a Lua function that can enable mxp on for the user. I have noticed that we don't have Lua (lazy) functionality that allows us to turn off or on mxp directly. with that idea, we could couple them in a profile.

while same time, it is useful to have that functionality so mud coder(s) and a mudlet user(s) can create an alias to turn off and on to observe it easily.

That's still a workaround then for IRE users. How does MUSHclient do it - and does it actually work for both Evennia/ChatMUD and IREs out of the box?

I should note that it was 'on command' by default in mush client.

Ah ok, so it has IRE broken out of the box.

I'm thinking of trying to implement something similar in mushclient in form of:

1) 'yes/no/on command'
2) also it should provide useful tooltip explains which option is suitable to which server. for example, for 'yes':
"It is recommended to select this option if you are playing IRE games(achaea, aetolia, starmourn, etc).

3) implement this into XML option(don't abandon forced_mxp_negotiation option) instead use it to import option to new variable. this is converting the old profile to a new profile in an update.
4) each default profiles will have XML option that can be either of those options enabled/disabled/command tailor to each respective game.

This won't do, we can't have a complicated client that requires more knobs and fobs as it grows just to keep things working (and not add any new features).

What about we auto-detect MXP and enable it?

So we want to detect mxp in form of [#z and also detect the negotiation?

Yeah. Basically, add a workaround in for IRE (until they fix it).

I'm surprised they don't negotiate it given how extensive their MXP implementation is - you're super sure that's the case?

mushclient or IRE?

IRE

from what I gathered it can be enabled by their config. although, they don't negotiation implement for mxp as of yet. as I directly communicated with Tecton about this, he says it might be implemented in the next rapture engine update. (in which I don't know when it will be the next update).

Okay - let's add an auto-detect option for the cases where an engine starts forcing it (like we had before... ha)

we had this auto-detect before this or that same code before i modify them?

Nah, remember we assumed MXP was on without the server negotiating for it - and that's why IRE's worked.

then
1) by default, we leave mxp on(with mMxp to false on init) obviously IRE can turn it on by (esc)[4z
2) if and should any mud server negotiated, then mMXP will be flipped to true. (AKA code 0 open line)

good?

I think so - you're saying MXP can be turned on either by proper negotiation or by us scanning for the magic string. Otherwise it's off and <, > show up OK. Sounds good.

magical auto-detect. :p i'll makes a magical patch PR tomorrow.

Remember there are MUDs out there that don't even know/care about MXP so mangling their output if they happen to use < > for say, some form of highlighting of one value in a list so that from an HTML/XML point of view it looks like a tag is just not on. What oh! Or, at least, it should NOT be ON by default...! :see_no_evil:

You should be able to fire the auto-detect magic by putting something in TBuffer::translateToPlainText(std::string& data, const bool isFromServer) after the line:

                case static_cast<quint8>('z'):

that will intercept ALL the MXP control code sequences but only act on them if the conditions are right. You should, perhaps gate the firing with the isFromServer so that only the Server data (and corresponding Replays) tickle your code - doing that will prevent false positives from feedTriggers(...) calls by the user's/packager's scripts... :smiling_imp:

@SlySven thanks. I will look into it.