Open protocol support

User avatar
KaVir
Posts: 86
Joined: Mon Feb 08, 2010 8:38 pm
Contact:

Open protocol support

Post 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.

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

Re: Open protocol support

Post 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.

User avatar
KaVir
Posts: 86
Joined: Mon Feb 08, 2010 8:38 pm
Contact:

Re: Open protocol support

Post 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.
Last edited by KaVir on Thu Apr 29, 2010 3:17 pm, edited 3 times in total.

User avatar
tsuujin
Posts: 695
Joined: Fri Feb 26, 2010 12:59 am
Location: California
Contact:

Re: Open protocol support

Post 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).

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

Re: Open protocol support

Post 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.

User avatar
KaVir
Posts: 86
Joined: Mon Feb 08, 2010 8:38 pm
Contact:

Re: Open protocol support

Post 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.

User avatar
tsuujin
Posts: 695
Joined: Fri Feb 26, 2010 12:59 am
Location: California
Contact:

Re: Open protocol support

Post 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.

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

Re: Open protocol support

Post 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.

User avatar
KaVir
Posts: 86
Joined: Mon Feb 08, 2010 8:38 pm
Contact:

Re: Open protocol support

Post 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?

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

Re: Open protocol support

Post 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.
Attachments
clientinfo-mudlet-atcp.xml
(1.59 KiB) Downloaded 669 times

Post Reply