Page 1 of 3

Open protocol support

Posted: Thu Apr 29, 2010 11:36 am
by KaVir
I noticed that Mudlet-1.1.1 now supports the Aardwolf channel 102 protocol. That makes sense, as Aardwolf has a lot of players - but there are smaller muds with their own protocols as well, and I can't imagine you'd want to spend the time adding support for all of them.

Another client I use also added support for 102, but recently decided to add more generic functionality by providing OnPluginTelnetRequest() and OnPluginTelnetSubnegotiation() functions. These functions can be overloaded by plugins, allowing people to quickly and easily add support for protocols that aren't already built in to the client.

Is it possible to do something like this with Mudlet (my searches came up blank but perhaps I missed it)? If not, would you consider adding it?

This would allow users to easily add their own support for things like MSP, ZMP, MSDP, MSSP, etc. If a protocol became widely used you could later choose to build it into the client, but this would save you investing time and effort into protocols that are seldom used.

Re: Open protocol support

Posted: Thu Apr 29, 2010 1:17 pm
by Vadi
This was discussed before ATCP came in and it was a firm no for performance reasons - doing low-level processing is a no-no against Mudlets policy of being real fast. Instead, popular protocols will be added to the core itself and have the additional advantage of not requiring the user to download any additional content to make use of them.

Re: Open protocol support

Posted: Thu Apr 29, 2010 2:28 pm
by KaVir
The amount of low-level support required would be comparable with implementing a very simple protocol within the client. And if performance were the main issue, I would be more concerned about having built-in support for specialised protocols that are only used by one mud (and isn't Aardwolf dropping 102 in favour of ATCP anyway?). Better, in my opinion, to make it part of the "Powerful Scripting" Mudlet lists among its features - this isn't really much different to any other trigger, after all.

There is certainly an advantage in not requiring additional downloads, but only if the protocol is actually supported. MSP was discussed over a year ago, for example, and it's still not been added - given a choice between "slightly slower support" and "no support at all", I would choose the former every time (it's clearly fast enough for other scripts).

It's a bit of a Catch-22 situation. Mudlet has some nice features, but if it can't utilise the protocols supported by my mud then the majority of my players won't use it. But I doubt you'd bother adding support for the protocols I use when only 1.2% of my active players use Mudlet. Now if I could add that support myself through a simple script, and the popularity of Mudlet among my players suddenly shot up, it might reach the point where you decided it was worthwhile after all.

Re: Open protocol support

Posted: Thu Apr 29, 2010 2:31 pm
by tsuujin
Vadi wrote:This was discussed before ATCP came in and it was a firm no for performance reasons - doing low-level processing is a no-no against Mudlets policy of being real fast. Instead, popular protocols will be added to the core itself and have the additional advantage of not requiring the user to download any additional content to make use of them.
In all honesty, I disagree with this decision. While it doesn't matter in the end to me (ATCP is in there, and I play the IRE games) it seems like shooting your own foot to outright say that mudlet will only offer full support for certain games. You've just cut your userbase down; partly by excluding some games that your users might play, partly because many powerusers will not use a product that doesn't offer them the customization (even if they don't intend on using it).

Re: Open protocol support

Posted: Thu Apr 29, 2010 3:22 pm
by Vadi
I don't quite agree with it myself, but power users, or MUD admins if they're really vested, are welcome to submit a patch that adds the support - this is an open-source project, after all.

We just don't want to introduce mass avenues of inefficiency, not against adding one protocol or another. It's simply that demanding things should be done in C++ - for example, see the mapper + pathfinding. Calculation, rendering and UI is done in the core, all other work in Lua.

Re: Open protocol support

Posted: Thu Apr 29, 2010 3:39 pm
by KaVir
Vadi wrote:We just don't want to introduce mass avenues of inefficiency, not against adding one protocol or another. It's simply that demanding things should be done in C++ - for example, see the mapper + pathfinding. Calculation, rendering and UI is done in the core, all other work in Lua.
But that's true of scripting in general, it's not specific to protocols. All I'm proposing is that scripts have the option of receiving and transmiting out-of-band data - what they do with that data is up to them. You could provide the exact same functionality in-band as well, it just wouldn't be as pretty.

Re: Open protocol support

Posted: Thu Apr 29, 2010 11:57 pm
by tsuujin
Vadi wrote:I don't quite agree with it myself, but power users, or MUD admins if they're really vested, are welcome to submit a patch that adds the support - this is an open-source project, after all.
True, although I admit that I've yet to tinker with the code of Mudlet at all, because I know the devs are keeping copies of new stuff off of GIT, and I am not willing to write code that may be clobbered or obsolete in the next update.

Re: Open protocol support

Posted: Fri Apr 30, 2010 12:19 am
by Vadi
That's not an issue because the code you'd write will be merged into the main trunk. The reason why git isn't always updated fully is because, frankly nobody else is writing anything and so heiko doesn't always push to it (he's really tight on time, and doing administrative work for no reason means slower mudlet dev). He'd be more than happy to merge patches as he does.

Re: Open protocol support

Posted: Sun May 30, 2010 1:04 am
by KaVir
I've been having a look at ATCP today, and I'm not particularly impressed with it, but unlike protocol 102 it does at least appear to be generic enough that I could force my own data down its throat, and the client should be capable of regurgitating it at the other end.

I'd start off with the initial handshake as normal:

Server: IAC DO ATCP
Client: IAC WILL ATCP

Then I'd then need the client to pass a message to my mud via a custom plugin, like this:

Client: IAC SB ATCP "MSDP" IAC SE

That's basically telling my mud to start using MSDP data pairs, but to send them down the ATCP channel (my mud would simply ignore any other ATCP sequences). The client could then send data requests in exactly the same way as MSDP, for example if someone wanted to be informed about HEALTH and MANA updates they could send:

Client: IAC SB ATCP "\1REPORT\2HEALTH\2MANA" IAC SE

The mud would then send the variables whenever they changed, eg:

Server: IAC SB ATCP "\1HEALTH\2500\1MANA\2100" IAC SE

Or perhaps it would just send one, if only that one variable had changed:

Server: IAC SB ATCP "\1HEALTH\2500" IAC SE

Now my question is, is it possible to read this with Mudlet? I'd need to get everything between IAC SB ATCP and IAC SE, then I could parse it myself easily enough.

From reading the manual it appears I'd need to trigger on some particular message, but could I just trigger on any ATCP sequence, or would I need to make up a new module name to prefix all my messages with?

Re: Open protocol support

Posted: Sun May 30, 2010 2:03 am
by Vadi
Client: IAC SB ATCP "MSDP" IAC SE
I believe sendATCP "MSDP" will do this for you.

Mudlet automatically categorizes events into the atcp key-value table, with keys being the message name sans the connecting dot (Room.Num becomes atcp.RoomNum). I'm not sure how the parser will deal with "\1HEALTH\2500\1MANA\2100", my recommendation would be to at least have it as
HEALTH 2500
MANA 2100
If it helps, here's the script I have for Mudlet that accepts status update messages from atcp and stores them in Lua tables. Messages are sent in the format of
Vadi.Affs affname #
So to answer your question, your event handler would need to have a list of all the possible event names it'd like to trigger on.