Mxp issues

  • insanesnwbrdr
  • insanesnwbrdr's Avatar Topic Author
  • Offline
  • New Member
More
17 Dec 2015 07:50 #1 by insanesnwbrdr
Mxp issues was created by insanesnwbrdr
Hey could you please take a look and see if this is something easy to fix?

When Mxp is turned on I get no output from the game in scroll view but I can see it in the console.

Game.aftermathrpg.com:5555

Please Log in or Create an account to join the conversation.

More
17 Dec 2015 15:52 #2 by plamzi
Replied by plamzi on topic Mxp issues
When a player enters the game, there seems to be an MXP package without a closing tag.

In the dump below, notice that there's an ESC [ 6 z, but nothing of the kind when the package ends and user-visible output begins.

if you didn't know already, adding &debug=1 to your app url helps troubleshoot such issues in the browser console log. For example, in this case you will see a console message: "mxp split protection waiting for more input: 1". This means the client is waiting for a closing tag to arrive.
[6z<!-- Elements to support the Automapper -->

<P>

<SUPPORT destination iframe>

<!ELEMENT RName '<B>' FLAG="RoomName">

<!ELEMENT RDesc EMPTY FLAG='RoomDesc'>

<!ELEMENT RExits '<FONT COLOR=Blue>' FLAG='RoomExit'>

<!-- ********************************************************************* -->

<!-- The next element is used to define a room exit link that sends the exit direction to the MUD if the user clicks on it -->

<!ELEMENT EX '<SEND HREF="&text;|LOOK &text;|OPEN &text;|CLOSE &text;|LOCK &text;|UNLOCK &text;" hint="Right-Click to affect the exit|&text;|LOOK &text;|OPEN &text;|CLOSE &text;|LOCK &text;|UNLOCK &text;">'>

<!ELEMENT MEX '<SEND HREF="ENTER &text;|LOOK &text;|OPEN &text;|CLOSE &text;|LOCK &text;|UNLOCK &text;" hint="Right-Click to affect the exit|ENTER &text;|LOOK &text;|OPEN &text;|CLOSE &text;|LOCK &text;|UNLOCK &text;">'>

<!-- ********************************************************************* -->

<!-- tags dealing with room items -->

<!ELEMENT CRItem '<SEND HREF="GET &quot;&text;&quot; from &quot;&container;&quot;" hint="Click to get from object|GET &text; from &container;">'>

<!ELEMENT CMItem '<SEND HREF="GET &quot;&text;&quot; from &quot;&container;&quot;" hint="Click to get from object|GET &text; from &container;">'>

<!ELEMENT MItem '<SEND HREF="WEAR &text;|DROP &text;|LOOK &text;|DRINK &text;|EAT &text;|HOLD &text;|READ &text;" hint="Right-Click to use this object|WEAR &text;|DROP &text;|LOOK &text;|DRINK &text;|EAT &text;|HOLD &text;|READ &text;">'>

<!ELEMENT EItem '<SEND HREF="REMOVE &text;|LOOK &text;" hint="Right-Click to use this object|REMOVE &text;|LOOK &text;">'>

<!ELEMENT RItem '<SEND HREF="GET &name;|LOOK &name;|DRINK &name;|READ &name;" hint="Right-Click to use this object|GET &name;|LOOK &name;|DRINK &name;|READ &name;">' ATT='name'>

<!ELEMENT RMob '<SEND HREF="CONSIDER &name;|LOOK &name;|KILL &name;" hint="Right-Click to affect this creature|CONSIDER &name;|LOOK &name;|KILL &name;">' ATT='name'>

<!ELEMENT WItem '<SEND HREF="LOOK &name;|READ &name;" hint="Right-Click to use this object|LOOK &name;|READ &name;">' ATT='name'>

<!-- ********************************************************************* -->

<!-- miscellaneous tags -->

<!ELEMENT FIGHT EMPTY FLAG='Fight'>

<!ELEMENT HELP '<SEND HREF="HELP &text;" hint="Click to view the help entry.">'>

<!ELEMENT HELPNAME '<SEND HREF="HELP &name;" hint="Click to view the help entry.|HELP &text;">' ATT='name'>

<!ELEMENT SHOP '<SEND HREF="VIEW &quot;&text;&quot; &quot;&shopkeeper;&quot;|BUY &quot;&text;&quot; &quot;&shopkeeper;&quot;" hint="Right-Click to use this object|VIEW &quot;&text;&quot; &quot;&shopkeeper;&quot;|BUY &quot;&text;&quot; &quot;&shopkeeper;&quot;">'>

<!ELEMENT Health EMPTY ATT='name'>

<!ELEMENT HealthText EMPTY ATT='name'>

<!ELEMENT TELL '<SEND HREF="TELL &name;" PROMPT hint="Click to reply.|TELL &name;">' ATT='name'>

<!ELEMENT SAY '<SEND HREF="SAY &quot;&name;&quot; " PROMPT hint="Click to reply.|SAY &quot;&name;&quot;">' ATT='name'>

<!ELEMENT WHISPER '<SEND HREF="WHISPER &quot;&name;&quot; " PROMPT hint="Click to reply.|WHISPER &quot;&name;&quot;">' ATT='name'>

<!ELEMENT GTELL '<SEND HREF="GTELL" PROMPT hint="Click to reply.|GTELL">' ATT='name'>

<!ELEMENT CHANNEL '<SEND HREF="&name; " PROMPT hint="Click to reply.|&name; ">' ATT='name'>

<!ELEMENT CHANNELS '<SEND HREF="&extra;&text;" hint="Click to toggle on/off.|&extra;&text;">' ATT='extra'>

<!ELEMENT JRNL '<SEND HREF="READ &text; &quot;&name;&quot;" hint="Click to read.|READ &text; &quot;&name;&quot;">' ATT='name'>

<!ELEMENT MENU '<SEND>'>

<!ELEMENT CLAN '<SEND HREF="CLAN &text;" hint="Click for info.|CLAN &text;">' >

<!-- ********************************************************************* -->

<GAUGE hp Max=maxhp color=green Caption="Hit Points">

<GAUGE mana Max=maxmana color=yellow Caption="Mana">

<GAUGE move Max=maxmove color=white Caption="Movement">

<GAUGE vichp Max=vicmaxhp color=red Caption="Enemy Damage">

<!-- ********************************************************************* -->

<!-- here are some archon tool elements -->

<!ELEMENT LSTROOMID '<SEND HREF="GOTO &quot;&text;&quot;" hint="Click to goto.|GOTO &text;">' >

<!ELEMENT LSTUSER '<SEND HREF="SNOOP &text;|BOOT &text;|BAN &text;|MULTIWATCH ADD &text;" hint="Right-Click to use.|SNOOP &text;|BOOT &text;|BAN &text;|MULTIWATCH ADD &text;">' >

<!ELEMENT LSTQUEST '<SEND HREF="MODIFY QUEST &text;" hint="Click to start/stop.|MODIFY QUEST &text;">' >

<!-- ********************************************************************* -->

<!-- the next elements deal with the MUD prompt -->

<!ELEMENT Prompt FLAG="Prompt">

<!ELEMENT Hp EMPTY FLAG="Set hp">

<!ELEMENT MaxHp EMPTY FLAG="Set maxhp">

<!ELEMENT Mana EMPTY FLAG="Set mana">

<!ELEMENT MaxMana EMPTY FLAG="Set maxmana">

<!ELEMENT Move FLAG="Set move">

<!ELEMENT MaxMove EMPTY FLAG="Set maxmove">

<VERSION>

<SUPPORT image send gauge font b image.url sound.u>

</P>



[1;36mNew Room[0;37m [1;37m

[1;37mBrand new database room! You need to change this text with the MODIFY ROOM

command.  If your character is not an Archon, pick up the book you see here

and read it immediately![0;37m[0;37m
The following user(s) said Thank You: insanesnwbrdr

Please Log in or Create an account to join the conversation.

  • insanesnwbrdr
  • insanesnwbrdr's Avatar Topic Author
  • Offline
  • New Member
More
18 Dec 2015 01:47 #3 by insanesnwbrdr
Replied by insanesnwbrdr on topic Mxp issues
Thank you soo much for the help and in case you dont get it enough thank you for this project

Please Log in or Create an account to join the conversation.

More
24 Jul 2016 21:36 #4 by Splork
Replied by Splork on topic Mxp issues
Any chance there has been changes to MXP? I noticed today when I logged in via Mudportal Client that all of our room exits mxp are displaying the full string content. We havent altered this code in years and other clients are still showing correctly. This is taken from SlothMUD.
Attachments:

Please Log in or Create an account to join the conversation.

More
09 Aug 2016 14:53 #5 by plamzi
Replied by plamzi on topic Mxp issues
This is fixed, though in the quickest, not best, way possible

Please Log in or Create an account to join the conversation.

More
08 Mar 2019 00:47 #6 by aldie
Replied by aldie on topic Mxp issues
(did I hid submit the first time?)

Hi there, admittedly my first thought was that MXP is successfully negotiated and enabled using the telnet protocol.
I know realized that the portal app basically does not support any of the MXP tags we are using.

We are making excessive use of the !EL and !EN tags, but they are not understood. Maybe these shorter aliases could be allowed
too? I'm also surprised the <VERSION> tag is not understood. Unfortunately this screws (well, aborts) our MXP setup routines.

I'd thought <version> is a kinda mandatory mxp tag to support?

Finally, it would be a great thing if unknown/unsupported MXP tags were just silently ignored. As basically none of the MXP
primitives we use is supported, they are all printed out to the user which totally screws the text window. I think you should
just ignore unknown tags. I know, we can check for each one with <support>, but it is a bit complicated to adjust the mxp routines
at a per element level. At least when very basic ones like <VERSION>, <!EN>, <!EL> are missing.

Talking about <support>, screen shots show gauge but <support> say it has no <gauge> command. Is the output of the <support>
element correct?

Before you spent too much time here, there might be other issues and I'm not sure if fixing the above would already allow us to use
mxp in the portal app.. Though it certainly were cool.

Please Log in or Create an account to join the conversation.

More
09 Mar 2019 17:08 - 09 Mar 2019 17:10 #7 by plamzi
Replied by plamzi on topic Mxp issues
I've tweaked the MXP.process method to accept <!EL as a variant of <!ELEMENT. Both <!EN and <!ENTITY should be acceptable so I'm not sure what the issue is there. If you have JS chops, try to override the Config.mxp.process function with your own and do some debugging. You know the web app lets you run your own code, and it also lets game admins publish code that modifies the entire experience for their game. It's always been part of the plan to build something flexible.

If you can figure out how to override Config.mxp.process, you may also be able to figure out how to respond to <VERSION>. Let me know what the response you think should be and I'll try to plug it in on my next pass (but these are incidental, so you may need to wait a while).

Unsupported tags are not going to be stripped if we haven't negotiated MXP successfully in the first place, so once that is fixed, my guess is they will be. Or maybe something more complicated is going on, but honestly, I won't have the time to fire up a debugging session against your MUD, so I'm going to have to rely on your input about that.

The screenshots show an HTML/CSS web app module called MistyBars. It is documented here: www.mudportal.com/forum/api-documentation/61-api-mistybars The idea is to be able to drive these bars in multiple ways, sending vitals via MXP being only one of them. So I didn't list GAUGE in supported tags. This was so long ago, I'm not even sure GAUGE was on the menu back then.
Last edit: 09 Mar 2019 17:10 by plamzi.

Please Log in or Create an account to join the conversation.

More
30 Jun 2019 23:39 - 30 Jun 2019 23:40 #8 by aldie
Replied by aldie on topic Mxp issues
Hi there.
You thought I gave up? Fate would have spared you further comments from me?
Well honestly.. Occasionally I was close to this point. I realized that the whole existing structure of MXP.js will never be able to parse real MXP.
Also.. RL deeds needed to be done.

When I refer to the standard, I mean www.zuggsoft.com/zmud/mxp.htm . I also refer to reference implementations, those are CMUD and Mushclient. Both have the most complete implementations, although each has some feature the other doesn't implement (right).
ZMUD had more flaws than CMUD (its successor) and slightly differed, but I don't have a working version (this is no longer maintained). These are the definitive references for MXP, nothing else.

Attached find the first, seemingly completely working version (for ME and with what I tried in a hour or so). This is work in progress!!!!!!! It contains countless debug msgs and code and it also contains no longer needed old stuff! I'm just so happy it works, I thought I'd share.

Still, it never was or will be my intention to provide a client for my mud, I want to support the standard as much as possible!

What it does (I hope I don't forget something):
  • proper support for open,secure,locked mode (one line and locked), also can do temp secure mode out of locked mode. In locked mode all MXP codes are printed, otherwise unsupported tags are silently ignored.
  • generally, proper parsing of tags & arguments. The code understands the protocol. It does not do any text replacements MXP->HTML that work in a few specific and fail in most other situations.
  • working text formatting tags (Thinks like <B> won't work in a modern browser)
  • Fully supported <version> <support>, odd - maybe uncommon synonyms like: <I> <ITALIC> <EM>.
    Full support means that things like <version 'styleversion'> <support send.*> work as described and mandatory(!) for the MXP protocol and reply back to the mud.
    It does not mean they are silently ignored and just don't screw the output
  • SEND now also supports the PROMPT parameter. I also changed the semantics to be MXP compatible: For SEND menus, left click executes the default command, right click opens the menu where the default command (always the first, rather boring) is printed in bold.
    Hints work proper with send menus, you can change the mousehover text independently from the command hints.
    Digits were just removed from hint texts? Why?
  • Fully working EXPIRE to deactivate SEND and A MXP tags when you leave their scope in your mud.
  • IMAGE enhanced with the formatting specs from MXP.
  • working !EN(tity). It also worked before, however, the defined entities had no effect at all.. Doh! Note: Here I deviate from the standard, it claims
    <!en start <B>><!en end </B>>&start;bold&end; would work and does not explicitly say what <!en en1 &en2;><!en en2 &en1;>&en1; would do.
    I would have been prepared to implement some range of recursive replacement of entities, however the reference implementions don't do it at all, so
    the value of entities is not further interpreted by mxp. Also supports ADD REMOVE DELETE attributes.
    I saw entities had no effect, maybe a mud specific module may use them to set the value of a gauge or similar through the event mechanism. But in
    mxp itself: no effect.
  • working !EL(ement). And I mean complex usage like <!EL ITX '<SEND HREF="examine inv##&ID;|take inv##&ID;" EXPIRE=&EX;><B>' ATT="ID EX=LO"><ITX ID=2>a sword</ITX>
    Oh, and I saw elements were immediately forgotten after each call to MXP.process? Huh? I thought they are meant as mud-wide abbreviations? Can also DELETE elements.
    The predefined elements cannot be modified.. Also you can define EMPTY, OPEN, SECURE elements.. and this has the desired effect..
    You can also refer to &text; within an element definition.
  • working !ATT(list) I think it is not very useful, the ATT attribute of element does it already.. but old muds may use it, or people may want to redefine default arguments of elements.

Missing features / Todos:
  • Frames and DEST: The reference implementations of them are poor (too poor to use reliably), I have not much code to test it.
    I will add at least a superset of what was there next, but in this code snapshot they are not yet implemented.
  • closing open OPEN tags at \n, make \e[3z close tags, make Socket close open tags and reset MXP status when the mud does not properly close tags in time.
    I have a plan how to do this, but it is not yet there.. misbehaved MXP code can screw the terminal.
  • Generally: I have no clue (in my personal measurement scale) about JS, CSS, DOM, jQuery. I do coding since 30 years (at least) maybe 35 in virtually all languages, many OS', also several types of machine code though, also linux kernel coding.
    But only as a hobby/at univ. Never as a paid for coder (if you don't count the algorithms I designed as a maths researcher at univ). I'm learning, playing around, nothing more, nothing less. My style changes as I discover more clever ways to do things..
    I'm sorry for that. but if it works...
  • !TAG and the TAG attribute of !el are unsupported, and I have no plans to add them. I dunno if the reference implementations actually allow for user defined line tags and I have no code that uses them.
  • The flag attribute of !el does not work, or well: it is parsed and stored, but has no effect. This is complex, client depended and there is no module that uses it.
  • That said, new entities/elements do not yet fire Events. Already planned for in the code, but just not there. I'll do this in a backwards compatible way, though that will likely not allow the listeners to use all mxp features.
  • <VAR> not there, and I have no plan to do it: I don't use it and more importantly, there is no module in the portal that uses it.
  • when mixing ANSI codes with MXP, the modules may (well:will) produce improper html code, not closing <span> proper, for example. However, the browser / Scrollview wings it together the right way.. I might just leave it, but I may also fix it.

Next Steps:
  • Testing..testing..testing (and fixing bugs)
  • add Frames,closing open tags as described above.
  • Also test with Firefox,Chrome,Edge (I think IE won't work, or will it?). I know of one display glitch where a control char gets through to the screen already (affects Chrome).
  • Make new elements / entities fire events at definition in a backwards compat way.
  • upload the modules to the portal as code snippets too.
  • Generally I think mudportal should just be telnet/termtype/mxp standards compatible, but I now see, muds implement some subset of a standard and the portal is designed to somehow work in this/their specific use case only. Adding standard compatible protocols might break something. I'm happy to try/assist to find a fix, but I may not be able to do it. And noone may want to risk breaking something
  • Hence, I'll also add a personal loader for my mud to make the portal work for it. I'll also have to change some css definitions to make it perfect, but I see
    there are ways.

    I'm just so happy about how it works, I wonder if I should make a vid how you click through rooms, inventories, directories.. but then.. I guess nobody cares.
    Thinking about the complexity of the code, I'm also satisfied that it is still working in a usable speed even though it is a script.

    Freshman.
Attachments:
Last edit: 30 Jun 2019 23:40 by aldie. Reason: typos changing the meaning of the text.. I guess there are many others.. sorry.

Please Log in or Create an account to join the conversation.

More
09 Jul 2019 20:42 #9 by aldie
Replied by aldie on topic Mxp issues
Ok, I think I call this a release. Attached is a zip file (did I forget that in my previous post?). Note that you need the colorize patches for it too work, the diffs are relative to it. Zip also includes the full file, but you need ScrollView from my colorize patch.

I finished all the open staff in my previous post. TAG VAR and any meaning of FLAG are still not supported.

Frames are there and work. However, some tiny changes: <FRAME> did always empty an existing window, as if EOF were given (not part of the standard). I changed it to empty the window only when asked too, as it clashed with some of my use, and there is no way to ask for the mud if the frame is (still) open, so you tend to open it again and again to be sure. This change also allow to redefine a frames title (also for _top) or size from the mud. Alignment can also be changed, but it seems not to interact well with previous alignment.. I don't need it, so I didn't dig in deeper. DEST still lacks EOF and EOL support and X/Y are interpreted different than in the standard.

There is one glitch with the frames: If a title is changed, some time is needed until the tab at the bottom of the screen updated. Worse: if a user closes a frame, the tab remains for a while. If you interact with the non-exist frame, an error may occur.

BTW, the idea to push MXP in the html doc, let the browser try to scan it, then reread this back with DOM is interesting, it replicated some code I did for the other tags and worse it did not normalize capitalization. The old code had a tendency to case-sensitive lowercase in many places (not just the element names), but the standard promotes uppercase. I tried to make it accept both for system elements. Selfdefined ones are generally case-sensitive.

I already loaded the modules up to the ARTICLES/SCRIPTS section for anyone to use. I did also manage to make the portal load and use them in my init script.

So I ended up doing exactly the opposite from what I really wanted: Rather than patching the whole program to be more standard compliant work for as many as possible muds, I made a specific client for our mud.

I will do further testing and using the module, I might fix bugs I encounter.
Attachments:

Please Log in or Create an account to join the conversation.

More
09 Jul 2019 20:55 #10 by aldie
Replied by aldie on topic Mxp issues
Fellow Mud Admin,

If you come across this message, because there are massive compatibility issues of the portal with your mud, garbled colors, mxp non working...

Maybe my code will help you. Get an Admin/Coder account. Go to Forum>Portal App>Tutorials>Getting Started and follow the instructions to customize your own mud. However, do not use Bedlam-init.js as the source of your copy, use Aldebaran-init.js instead.

Change/add/remove any customization, background between the

// ADD YOUR PERSONAL MUD STYLE BELOW HERE

and

// LEAVE THE REST UNTOUCHED TO GET BETTER ANSI COLOURS AND MXP SUPPORT

comments.

Even when you did all right, Plamzi has to set you up as an 'official admin' for the mud for your module to load for all players (will work as long as you are logged in to the portal though). If you wonder, in Keywords give a comma-sep list of hosts/ports like: fqdn1:port1,fqdn2:port2

But, apparently only one alias fqdn can be used by all players to load the custom file.

Maybe my changes will help to support your mud.

Enjoy.

Please Log in or Create an account to join the conversation.

More
11 Jul 2019 23:27 #11 by aldie
Replied by aldie on topic Mxp issues
BTW B4 you ask: I somehow wondered/guessed that the MXP menus where opened by click due to restrictions on tablets. Apparently the
tablet vendors (at least one of them) did not add a way to open a contextmenu in their browsers.. I now added a touchend event. So touching the button long and releasing it opens the menu. If you are really quick, a click will exec the default command. That's the expected semantics.
Still for my taste, text is too small on a small tablet and active fields to difficult to enter.
I changed the uploaded scripts.
To upload as a zip, the patch is too minimal for now. I expect more bugs to show up.

Please Log in or Create an account to join the conversation.