31 Mar, 2014, lilmike wrote in the 1st comment:
Votes: 0
Hi,
I am looking at implementing i3 into a mud I'm working on, based on aspen mud (http://code.google.com/p/aspenmud), but am not quite sure where to start looking for some example code or anything for i3.
I looked for things under i3, intermud, and imc on this site under code repository, but didn't find much that wasn't part of a full mud.
Any idea on where I should start looking for help on connecting my mud to i3?
Thanks,
-Michael.
31 Mar, 2014, quixadhal wrote in the 2nd comment:
Votes: 0
You can find a C implementation here… https://github.com/quixadhal/wileymud/bl...

That's from a very old implementation of AFKMUD, and some features aren't implemented since my MUD doesn't have them (DikuMUD alfa based). Basic channel messages and emotes work, remote tells work, as does mudlist and remote who functions. That's about all I ever use. :)

There's also one for SmaugFUSS, https://github.com/quixadhal/SmaugFUSS

It may have a bug or two, not very well tested.

There are, of course, multiple LPC mudlibs you can download that do a better job… but then you have to understand how the mudlib works, and if you're using a C++ codebase, the way it works is likely very different from your coding style.

Finally, there's the I3 specs. Just be aware that the router doesn't follow the specs exactly, so if you try to stick rigidly to them, some things may not work. The router is, itself, an LPMUD.

http://wotf.org/specs/i3.html
31 Mar, 2014, KaVir wrote in the 3rd comment:
Votes: 0
I had a similar issue (as discussed in this thread) when I looked at adding support for IMC2. I still fancy adding some sort of intermud chat, and i3 looks like the best candidate, but the snippets are either bound to the Diku licence or in a language I'm not familiar with, and even the specification seems to be geared towards LPC.

A concept I considered at one point would be to create a separate application running on the same machine, and have it communicate with the mud using MSDP or some other protocol. The other application could even literally be a DikuMUD, although it would be stripped down - all it would need to do is act as a proxy server, allowing the real MUD to communicate over i3.

That would avoid the licencing issues, and also be significantly easier to implement (and if the hooks were added into my protocol snippet, it could make it an effort-free feature for anyone using the snippet). I don't see any pressing reason why the intermud protocol should need to be compiled into the same executable as the rest of the MUD, anyway (a stripped-down DikuMUD would obviously be a temporary workaround).
31 Mar, 2014, quixadhal wrote in the 4th comment:
Votes: 0
I3 was implemented by and for LPMUDS, and specifically for the MudOS driver. I believe the same people who worked on the driver also designed the spec, and thus it takes advantage of things that make it very simple in LPC.

The big thing is the "mudmode socket", which is simply tcp sockets that expect messages to be a binary length word (32-bit I believe, in network byte order), followed by an LPC data structure (which is very similar to JSON).

I wrote part of this in Perl a while ago, and you're welcome to use that as a general template. It might not be bug free, but between that, the spec, and glancing at various other implementations, it shouldn't be hard to write it again in the language of your choice.

Note that the perl version actually uses the JSON serialization code and just modifies it to do LPC instead. That code is under the artistic license, and so the LPC serializer must also follow suit.

http://pastebin.com/abBReqd7
31 Mar, 2014, lilmike wrote in the 5th comment:
Votes: 0
Hey,
Thanks for all the snippets listed. They should be helpful in implementing this.
-Michael.
0.0/5