MXP enhancements, was PR #4200
Posted: Sun Apr 23, 2023 6:06 pm
Hi people,
I've been asked if I wanna revive the 4200 PR, but do it in much smaller chunks, and well, it was done 2 years ago. So, a few tiny things need to be done to it s.t. it fits into the now change development branch.
My main goal is, to get all the fixes of 4200 in first (because then mudlet will become usable for me) than maybe add other things regarding mxp, fix issues other people have, maybe do some further extension (read below).
To achieve that, I've come up with following roadmap for PRs:
1. Make <version> support a style argument. This is a very, very tiny patch. Why do it first? Well, as a 'test balloon or probe' to see how the integration collaboration works out, it is mandatory in the MXP v1.0 definition which Mudlet negotiates and it (kind of) screws setup of my mud.
I already did this as a new branch of development, I'll send a PR right after this post.
2. Make the <bold>, <underline>, <italics>, <strikeout> tags actually work. Again, this is relatively simple, and I'd assume these tags are not so often used since there are good vt100 alternatives. So why do it? Well, they are already parsed and handled by the code (somewhat) but don't have any effect, so I think this should be fixed. Within that patch/pr I'll also add the short aliases <b>, <u>, <s>... of these... because, well these are shorter and kindof the recommended way to used in MXP. <color> BTW, does already work (not sure about setting fonts, but this is not used so often, so no priority for me).
Then the patches will get more complex:
3. <!EN> or entities don't work proper, if I remember right, there are issues with setting and evaluating them. So here I'll put in what I did to fix this. At this point, I think, I should also fix/extent the mxp test code snippets.
4. <!EL> element definitions also had some issues. I need to doublecheck what was exactly broken, but I think there were issues with unnamed parameters (just defined by position) and default values of omitted parameter.
-- if we reach this point, the mxp code will become usable, because normally with MXP, when connecting to the mud, you get a 'style sheet' uploaded with a bunch of <!EL> definitions like how to display an item, or a weapon and what context menu to display with them which will then be used throughout the game, for example with <W>sword</W> and which might make use of some entities or parameters to change details.
5. There are some tiny issues with multiline send menus, for example, they don't display a special 'hover' link right (if one is explicitly specified by the mud)
6. Hints of menus are always displayed all caps. I think, Mudlet should not do that. If the mud wants to have them send in CAPS it should set them in CAPS, I think mudlet should not force everything to caps. Now, this is a style issue. it can be argued, and I'm prepared for people insisting mudlet must enforce all caps.. But well, I think that is wrong.
--- so this is the original content of PR#4200 . For some things, esp. the EN / EL changes, there is some test code too, that I would do when I work on those parts.
After that, other things I noticed and that came to my mind for the future (only ideas, I don't promise anything!) :
a) if you disconnect and just reconnect (not restart mudlet). The MXP state is not reset, not sure if this holds for other terminal states too. But it is bad, of course. For example, if by a bug (maybe wrong MXP code send by the mud), the terminal is screwed up (like black on black colour), disconnecting and reconnecting does not help. You need to close and reopen mudlet... Not good (oh, and this actually already effects the currently released version... remember... <color> already works.)
b) Now this is a really hard thing: MXP defines different modes (open modes, secure modes... etc.). I saw in the discussions here that there are quite different opinions by this, but for one these would define an MXP reset sequence that allows the mud to reset all mxp states at login or maybe in response to something like "stty sane" to counteract runaway tags like in a). Second, they allow to enable automatic closing of tags at the end of line in common situations which removes the issue with runaway tags for most common cases. But... this is (IMHO) a bit more difficult to do. Definitely it would need to add interpretation of more esc sequences and some trigger to the mxp code when a \n is seen. (and for each element we need to define if it is privileged or not)
c) provide some lua access to mxp variables and esp. current room descr and exits which will already be specially tagged by an MXP compliant mud. I think the latter might be very useful for the/a automapper.
d) maybe some way to debug the mxp status might be helpful. Like seeing current entity or elements settings. Not sure yet how to do this (like a special mudlet command, or some button in a menu), but it could be helpful.
e) maybe see if the sound/music tags work and if not make them working.
So, this is my current roadmap. I've to add I'm quite busy at the moment.. So I might/will need my time.
I've been asked if I wanna revive the 4200 PR, but do it in much smaller chunks, and well, it was done 2 years ago. So, a few tiny things need to be done to it s.t. it fits into the now change development branch.
My main goal is, to get all the fixes of 4200 in first (because then mudlet will become usable for me) than maybe add other things regarding mxp, fix issues other people have, maybe do some further extension (read below).
To achieve that, I've come up with following roadmap for PRs:
1. Make <version> support a style argument. This is a very, very tiny patch. Why do it first? Well, as a 'test balloon or probe' to see how the integration collaboration works out, it is mandatory in the MXP v1.0 definition which Mudlet negotiates and it (kind of) screws setup of my mud.
I already did this as a new branch of development, I'll send a PR right after this post.
2. Make the <bold>, <underline>, <italics>, <strikeout> tags actually work. Again, this is relatively simple, and I'd assume these tags are not so often used since there are good vt100 alternatives. So why do it? Well, they are already parsed and handled by the code (somewhat) but don't have any effect, so I think this should be fixed. Within that patch/pr I'll also add the short aliases <b>, <u>, <s>... of these... because, well these are shorter and kindof the recommended way to used in MXP. <color> BTW, does already work (not sure about setting fonts, but this is not used so often, so no priority for me).
Then the patches will get more complex:
3. <!EN> or entities don't work proper, if I remember right, there are issues with setting and evaluating them. So here I'll put in what I did to fix this. At this point, I think, I should also fix/extent the mxp test code snippets.
4. <!EL> element definitions also had some issues. I need to doublecheck what was exactly broken, but I think there were issues with unnamed parameters (just defined by position) and default values of omitted parameter.
-- if we reach this point, the mxp code will become usable, because normally with MXP, when connecting to the mud, you get a 'style sheet' uploaded with a bunch of <!EL> definitions like how to display an item, or a weapon and what context menu to display with them which will then be used throughout the game, for example with <W>sword</W> and which might make use of some entities or parameters to change details.
5. There are some tiny issues with multiline send menus, for example, they don't display a special 'hover' link right (if one is explicitly specified by the mud)
6. Hints of menus are always displayed all caps. I think, Mudlet should not do that. If the mud wants to have them send in CAPS it should set them in CAPS, I think mudlet should not force everything to caps. Now, this is a style issue. it can be argued, and I'm prepared for people insisting mudlet must enforce all caps.. But well, I think that is wrong.
--- so this is the original content of PR#4200 . For some things, esp. the EN / EL changes, there is some test code too, that I would do when I work on those parts.
After that, other things I noticed and that came to my mind for the future (only ideas, I don't promise anything!) :
a) if you disconnect and just reconnect (not restart mudlet). The MXP state is not reset, not sure if this holds for other terminal states too. But it is bad, of course. For example, if by a bug (maybe wrong MXP code send by the mud), the terminal is screwed up (like black on black colour), disconnecting and reconnecting does not help. You need to close and reopen mudlet... Not good (oh, and this actually already effects the currently released version... remember... <color> already works.)
b) Now this is a really hard thing: MXP defines different modes (open modes, secure modes... etc.). I saw in the discussions here that there are quite different opinions by this, but for one these would define an MXP reset sequence that allows the mud to reset all mxp states at login or maybe in response to something like "stty sane" to counteract runaway tags like in a). Second, they allow to enable automatic closing of tags at the end of line in common situations which removes the issue with runaway tags for most common cases. But... this is (IMHO) a bit more difficult to do. Definitely it would need to add interpretation of more esc sequences and some trigger to the mxp code when a \n is seen. (and for each element we need to define if it is privileged or not)
c) provide some lua access to mxp variables and esp. current room descr and exits which will already be specially tagged by an MXP compliant mud. I think the latter might be very useful for the/a automapper.
d) maybe some way to debug the mxp status might be helpful. Like seeing current entity or elements settings. Not sure yet how to do this (like a special mudlet command, or some button in a menu), but it could be helpful.
e) maybe see if the sound/music tags work and if not make them working.
So, this is my current roadmap. I've to add I'm quite busy at the moment.. So I might/will need my time.