Mudlet features and API requests

[Widjet]

Oh, I didn't realise. Thanks!

The command line functions are
appendCmdLine
printCmdLine
clearCmdLine
for anyone who's wondering.

[Vadi]

An event for when the map is reloaded (from having it be downloaded, or just loaded). So in case of downloads, mapper scripts can re-lock areas and such.

[chris]

I need this too, so sure, i'll code it in.

[Omit]

I have 2 hopefully simple requests reguarding MXP. (MXP is very broken, not by mudlet but as a standard)

!st is that commands sent to the mud using the send() function go directly to the mud. (currently they are being sent through mxp and never make it.) This would allow those that play muds that require the <supports ...> tag to send it in scripting.

2nd is that the trigger varible "line" be passed the complete line...mxp formating and all. This would allow us to "fix" the inconsistanties of mxp in scripting. Even replacing the line with reprased mxp if needed. (quite a few muds send the &Text tag.... it would allow us to fix the behavior ourselves.)

[chris]

I threw in a few events, sysMapLoad for the initial map load,sys2DMapLoad for the 2d map initialization, sys3DMapLoad for the 3d map initialization.

[Omit]

I have 2 hopefully simple requests reguarding MXP. (MXP is very broken, not by mudlet but as a standard)

!st is that commands sent to the mud using the send() function go directly to the mud. (currently they are being sent through mxp and never make it.) This would allow those that play muds that require the <supports ...> tag to send it in scripting.

2nd is that the trigger varible "line" be passed the complete line...mxp formating and all. This would allow us to "fix" the inconsistanties of mxp in scripting. Even replacing the line with reprased mxp if needed. (quite a few muds send the &Text tag.... it would allow us to fix the behavior ourselves.)

Never mind on the first issue.... it appears that if you add a space after the mxp tag you can send the supports tag.
This DOES NOT work: send("<supports +a +send +gauge>")
But this does: send("<supports +a +send +gauge> ")

I would still love access to the raw mxp data somehow. (events would be great but is likely alot more work than should be put into it.) Including the mxp data in the "line" varible seemed to be best to me.

Any chance on this? MXP is currently unusable becuase of the differances in implimantation, I should be able to "fix" it with this change in place.

[Heiko]

The MXP standard explicitly states that implementations on both client and server end have to take care that MXP secure tags cannot be sent by users in order to prevent nasty user scripts that could mess up other players MUD output if they happen to use ZMud or CMud. You can use the sendSocket() function in Mudlet to send binary data over the telnet stream. Then you need to send the proper MXP telnet escape sequences along with the support tag.

I don't support the support tag because there is no agreement on the parameters whatsoever as Mush and ZMud send different data here afaik. I can send your tag however, if this makes your server happy. Mudlet only supports MXP links & menus in all known MXP implementation variants (I've done it in such a way to work with the biggest MXP implementations that I could find and there aren't many MUDs that use MXP. If your server implementation doesn't work with Mudlet then we should look at what your server does and see if this can be fixed client side. I'll post a simple server howto on how to make a simple MXP implementation that works with ZMud, Mush and Mudlet as this seems to be a major problem for server devs. Mudlet's MXP implementation is not yet a 3rd interpretation of the MXP "standard", but I've looked at how MXP is actually being used on 7 major MUDs that use MXP in any significant ways and supported all of the variants that I could find.

The &text placeholder is supported.

MXP data cannot be triggered on because this would introduce big useless performance problems for everybody and only a tiny minority of expert users would be able to take advantage of such a feature - effectively to do superfluous work that should be either done by the server admins or by me. I've tried to build a fast MXP parser and this isn't exactly easy because MXP introduces a huge pile of superfluous junk on top of the regular telnet data just to display links and menus (all other capabilites of MXP are basically either usesless and unused or superseded by GMCP/ATCP). If Mudlet's MXP implementation cannot handle certain servers, these servers need to be fixed or Mudlet needs to be made to take yet another MXP usage variant.

[SomeDude]

This request is predicated on the premise that the event listing here is fully up-to-date and includes all existing events:

Add events sysOnConnect and sysOnDisconnect (or whatever names) that are automatically raised upon successful connection to and disconnection from the MUD, respectively.

[Omit]

I would like to request a new function(if this isn't already there)
getRoomChar(ID)

It would allow checking if the map is aligned (by comparing a map generated by the mud to what is stored in mudlet) as well as the ability to use this info in a miniwindow (user created map widget).

[Heiko]

This already exists: (string)char = getRoomChar(roomID)