Bugs in MXP implementation, is this work in progress?

Post Reply
freshman
Posts: 3
Joined: Mon Oct 05, 2020 9:56 pm

Bugs in MXP implementation, is this work in progress?

Post by freshman »

Hello Developers,

I'm wondering if the MXP module is still being worked on. Comparing with what I remember when I last tried, it seems to have improved, since I can now login to my mud and there is 'some' kind of (MXP) functionality. Still, there are two major bugs that render the MXP functions quite useless to us:

1) There is no (working) support for entities (<ENTITY ...> or <!EN ...>
(re)defining 'entities' &customname; )

2) When defining elements, parameters for embedded commands are apparently transformed to uppercase, example:

<!EL ITI '<SEND "examine &ID;|drop &ID;" HINT="examine|drop">' ATT='ID'>

(btw entities as element args seem to work..)
When used, the hint menu shows EXAMINE and DROP. Oddly enough, w/o an element, directly using <SEND>, it works.

with those two issues - esp. 1) - fixed, MXP could start to be useful. There are additional issues too:

3) It is very irritating if the whole command menu pops up as a hint when hovering over a multiline menu like ITI above, but you can not click it,
as it is a hint only. It should give some hint you need to right click or there is more. Actually, giving n+1 hint texts, mud should be able to
specify the 'menu' hint text anyway.

4) &text; doesn work in element definitions. Of course, I assume this is
due to the total lack of entity support (see 1)).

5) No support for 'EXPIRE'

6) Sending unclosed strings from the mud (try, no don't): <!el red '<color red>> crashes the client. Same holds for not closing elements with </name>. Now for !el this is difficult, as it can be used in locked secure mode and can theoretically span over hundreds of lines... still some watchdog etc. to bail out and reset would be helpful. If you lockup mudlet with it, you need to close the app and reopen. Just reconnecting to reset the terminal won't help... Oh.. how about responding to the muds \e[3z ... to reset the mxp interpreter.. hmm?0

Now, you can say, !el is a secure tag, so you can trust the mud not to misuse it. But not closing open tags does the same, though open mode should reset at each \n by MXP standards.. (cite: Also, when in OPEN mode, any unclosed OPEN tags are automatically closed when a newline is received from the MUD.) Well, it seems to me, there is no support for the MXP line tags at all.

7) When using <VERSION> it seems a '\n' is also send to the screen or main window..
Not too bad, but it disturbs my loading/init screen...

I didn't dig any deeper for now. All this above is mandatory MXP, btw. There are no optional parts in this. Honestly, none of the clients out now is fully v1.0 compatible. But claiming MXP=1.0 in <VERSION> even w/o <!EN> is... well... bold.

Now, I'd like to know if someone is really working on this, or if I'd have to code this myself and convince you to include it, s.t. mudlet is another option for our plys . I had recoded the whole MXP thing of mudportal to be 1.0 compliant (admittedly w/o user(!) defined line tags and <var>s (since none
are displayed in the gui anyway)), so I don't really feel like doing all this again (and just adding our mud to the default list given in mudlet might not suffice as a motivation). Also I've little interest to code in W10, though that's the version most needed. Now.. after a quick glance over your instructions a W10 rebuild seems a doable task, though I'm yet unsure if its C++, C#, Java or else (probably it doesn't matter anyway).

P.S. Talking about stability, sending something like \e]2;Cool Title\a (which sets the window title in xterm) does also lockup mudlet. Again, even reconnect does not help. Mudlet must be closed.

Now, you didn't claim xterm support (nor vt100 with line graphs, double sized characters and printer support..), still.. some random esc sequence should not lockup the client, IMHO. Some garbage chars and then has to recover..

Regards,
Freshman.

freshman
Posts: 3
Joined: Mon Oct 05, 2020 9:56 pm

Re: Bugs in MXP implementation, is this work in progress?

Post by freshman »

Well, well. as we say in Germany: No answer is also an answer.

In the meantime (among other unrelated things), I managed to make my own W10 build of mudlet. I also had a (quick) look at the source.
To my surprise the MXP modules looks pretty well organized, it even actually does some quite elaborate handling of entities and variables, and stuff.
Alas, there is not the slightest attempt to use the entities so well organized in memory.

I really don't understand this. It seems untypical to me to have a very elaborate code to scan even the complexed options of entities but not use them
in the rest of the code - even for testing. Anyway, I'll now try to dig in deeper and solve issues 1 & 2). I'm yet unsure, but w/o 4) our mud might have one issue or the other. I'm not sure if I can address 3. For the rest.. probably noone except me will care.. and my priorities are different.. so.. well, we'll see.

Everything is nicely encapsulated in countless objects, hence it will need quite some time to understand the global structure of operations and get things going.

Stay tuned for updates, but I'll have to take my time.

breakone9r
Posts: 24
Joined: Sun Jul 26, 2020 1:39 am

Re: Bugs in MXP implementation, is this work in progress?

Post by breakone9r »

I know the devs would be really happy to have another person familiar with MXP working on it. I dont think it's been touched in ages except in response to a couple of issues I had, namely the addition of supporting MSP thru MXP, and working around what appears to be a bug in the MXP code of the mud I frequent.

User avatar
SlySven
Posts: 977
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Bugs in MXP implementation, is this work in progress?

Post by SlySven »

TBH Very few persons fully understand MXP - I don't (and I sometimes wonder about Zugg!) - the Mudlet MXP code did get a major refactoring recently - if you can use Git you can look back through the history and see that @gcms on GitHub has made some substantial changes a few months back: https://github.com/Mudlet/Mudlet/pull/4016 . From what I do know about our handling I'd have put it at only Version 0.3 or 0.4 but that was before that person really cleaned up the MXP stuff. For the record Mudlet is a largely C++ application (though there is some C code as well). It also supports a Lua user-scripting system and some Lua is used at runtime (and during compilation so you will want a Lua installation in your build environment as well). It is multi-OS and uses Qt libraries which aides with getting the code to run on all those OSes.

At present we offer prebuilt 64-bIt MacOs and GNU/Linux binaries and a 32-Bit Windows 8.0-10 one - we've officially dropped supporting Win 7 as that is now EOL - I do not know if it is possible to still compile a compatible application with the current generation of tools/development environments as at least some parts do not work now with Win7.

I compile and run Mudlet on Linux and FreeBSD and I am currently developing in a 64-Bit Windows 10 environment and I am trying to construct a build system that will compile both 32 AND 64 Bit Windows versions - since Qt do not provide a 64Bit SDK for Windows in their On-line installers I have installed, and am suggesting others switch to using, a MSYS2/Mingw-w64 environment instead of using the direct offering of Qt - I am largely the author of Compiling on Windows 7+ (MSYS2 Alternative).

If you wish to chat about this (or any other aspect) of Mudlet you may find you get a quicker respond in our Discord Guild this link should get you there: https://discord.com/invite/kuYvMQ9 .

User avatar
Vadi
Posts: 4854
Joined: Sat Mar 14, 2009 3:13 pm

Re: Bugs in MXP implementation, is this work in progress?

Post by Vadi »

The MXP implementation for the most part satisfies most games' usage of it and we're happy with that level. It did get rewritten recently as pointed out above, gaining a few features in the process. Thanks for checking this out!

freshman
Posts: 3
Joined: Mon Oct 05, 2020 9:56 pm

Re: Bugs in MXP implementation, is this work in progress?

Post by freshman »

Well, I won't call myself an MXP expert as I read above, but I digged a bit into it from the mud view some ten years ago.

With some wild or maybe educated guessing, I already made some progress - more than I expected. I hope C++ covers all con/destruction and memory management issues well, because I don't have a clue yet. - Seems to work though. I also tend to have a more archaic coding style tending to use overloaded operators ( + [] implicit casts and stuff) which might not be to everyones taste. Mostly since I don't know all the existing member functions by heart, but I know which operator just does it.

I was wrong: Actually MXP entities are resolved, the !EN tag handler - though looking nice - was still broken. It also seems &text; works, I dunno why it failed during my first tests (but see below on resolving to last char only).

I could also resolve the all CAPS mxp send menu hints. They were deliberately forced all CAPS when used in SEND. Why? The muds send an explicit hint text to use and it is always forced all CAPS? I guess someone loves it this way and will burn me... but if the Mud requests an explicit text it should be used, or? I also managed to support setting the menu hint itself (the mouse hover tooltip of a multi-choice menu) through MXP, independent of the individual command hints. I don't know where the link menus are all used in mudlet, it also seems there is a lua function. While even the lua function might benefit from the changed hint handling, I aimed to change ONLY the behaviour of the MXP send menus.

Ah, I forgot to mention: Using entities within the send cmd/hint definition didn't work right when the entity contained '|'

From that point on the majority of our muds mxp code started to work.

I also had to hack !EN to support setting entries to empty strings. I've the slight feeling positional args are generally not handled well when there is an empty string arg "" among them, but I have no current use case except setting an entity to empty string.

Right now I noticed default arguments like (example from original MXP specs):
<!ELEMENT boldtext '<COLOR &col;><B>' ATT='col=red'>
<boldtext>This is bold red</boldtext>
<boldtext col=blue>This is bold blue text</boldtext>
<boldtext blue>This is also bold blue text</boldtext>

don't work as specified.

[Yeah, there is no working 'B', try <!ELEMENT boldtext '<SEND><COLOR &col;>' ATT='col=red'> for demo instead]. Apparently mudlet defines
a parameter tag named "col=red" instead. You must use ATT='col' but then there is no red default setting, I think (need to doublecheck) &col; might even resolve to &col; or col; then.

That's what I'm looking at right now.

BTW, I use Cmud and Mushclient in parallel to compare behaviour and to deduce what a 'common sense' interpretation of MXP is. I don't count in my enhanced mudconnector version, since that does it how I think it should be done... hence is strongly biased)

-

What I stumbled upon and is very annoying though not MXP related: You cannot just hit return, empty lines are not send to the mud. Very annoying if you page something with "more" or even want to use the ed inline editor (need to check <tab> some time). Again, I'm sure not everyone will like to have it changed... What do you think?

It also seems MXP entities used outside of MXP elements are not handled right, they just resolve to the last character... This is only a first impression, I need to check further. Talking about entities, std entities, say &frac12; seem to resolve to UTF-8 proper - but the default charset cannot display them right (on W10). Any idea/hint how to make it work?

Finally, I'm a bit scared on trying to implement the different MXP line modes and reset escape sequences. Though all works in a permanent secure mode, our players can send any tags in says and tells in open mode (as the MXP standard suggests), and if the mud client doesn't stop it by enforcing open tags only, they can screw up other peoples clients - not good. They can even send a non closed open tag and screw mudlet. So... well.. we'll see.

You are probably very curious on what I'm coding there, but I need much, much more testing.. Each flaw I fix directly leads to the next issue (say default args) above..

Regarding discord, I don't use it.. I'm more into async communication, and have to.

User avatar
SlySven
Posts: 977
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Bugs in MXP implementation, is this work in progress?

Post by SlySven »

Finally, I'm a bit scared on trying to implement the different MXP line modes and reset escape sequences. Though all works in a permanent secure mode, our players can send any tags in says and tells in open mode (as the MXP standard suggests), and if the mud client doesn't stop it by enforcing open tags only, they can screw up other peoples clients - not good. They can even send a non closed open tag and screw mudlet. So... well.. we'll see.
The primary issue you are going to have with so-called "secure" tags is that that only really makes sense in a closed source client - anyone can take our code (or indeed any other open source MUD client) and hack it to inject rogue sequences - the only sure fire means to prevent harmful behaviour is in the Server... at least in my humble opinion.

(Similarly for that stupid "REGISTERED" attribute in the <VERSION> tag - it is pointless for a non-proprietary client - though I have only just noticed it was optional in http://www.zuggsoft.com/zmud/mxp.htm!)

Post Reply