27 Apr, 2009, jamez wrote in the 1st comment:
Votes: 0
Hello,

I run fuskermud which is a diku gamma 0.0 derivative. Running for 16 years now. I have been reading up on Intermud lately and was wondering how difficult it would be to add it to my mud server. Has anyone ported Intermud to Diku before? Any insight would be greatly appreciated.

Thanks.
27 Apr, 2009, Banner wrote in the 2nd comment:
Votes: 0
It works fine in SWR and SMAUG, deriviates of DIKU, so I don't see why it'd be that overly hard to make functional in DIKU.
27 Apr, 2009, ghasatta wrote in the 3rd comment:
Votes: 0
I think it depends a bit on what you mean by 'porting'. There are some existing client libraries out there - I would imagine these would not be terribly hard to adapt for your diku-rivative. The basic data structures should be the same, meaning you will merely need to smooth out any inconsistencies in the code – rather than thinking about design (or redesign).

On the other hand, implementing the protocol from scratch is a bit trickier. I have been working on a custom IMC2 client implemented from scratch. The documentation here on mudbytes is not bad, but not complete either. Expect this to be a bit of work, if this is what you are after.
27 Apr, 2009, quixadhal wrote in the 4th comment:
Votes: 0
Poking at this a bit on my own Diku-derived fossil, I can say it gets slightly more complicated if your player load/save routines do the funky char_to_store() silliness. Also, you may have to do some work to get socials working over it…. later muds broke socials off into their own table, whereas mine has them all lumped together.

I should also note that I'm working on the old I3 code that Samson had for AFK/Smaug. If you want to be on the IMC2 network, that's a whole different bit of code which I haven't even looked at.

Of course, all the usual const char * fun applies as well. :)
27 Apr, 2009, Kelvin wrote in the 5th comment:
Votes: 0
Worse case, as mentioned, implementing it from scratch is not difficult, just time consuming. I'm not sure it'll help, but you can look at my Python implementation in my codebase for a hopefully easier-to-read look at how I approached it.
29 Apr, 2009, Guest wrote in the 6th comment:
Votes: 0
quixadhal said:
I should also note that I'm working on the old I3 code that Samson had for AFK/Smaug. If you want to be on the IMC2 network, that's a whole different bit of code which I haven't even looked at.

Of course, all the usual const char * fun applies as well. :)


Heh. You're actually still using that old broken I3 code? :P

The IMC2 code shouldn't be any more or less difficult to work with. In fact it might be easier since the packets don't require a bunch of nonesense with brackets and stuff.

Quote
The documentation here on mudbytes is not bad, but not complete either.


What's not complete about it? The packet formats were all captured live during a development session and I don't recall anything new being added beyond what's in there already. If something is missing, and you know it's missing, feel free to edit the article to reflect it. That's why I put that in there :) It would obviously be nice to know when something gets changed so that those of us lurking in the shadows will be aware of it.
29 Apr, 2009, Cratylus wrote in the 7th comment:
Votes: 0
Samson said:
The IMC2 code shouldn't be any more or less difficult to work with. In fact it might be easier since the packets don't require a bunch of nonesense with brackets and stuff.


Them's fightin words!


Samson said:
What's not complete about it?


Just a note..not bashing, not..whatever. In making the imc2 <-> i3 translator, I did have to make
some educated guesses in some cases as to what was meant. And it turned out that there were
some people who had problems due to the translator missing some stuff that the spec seemed
to assume would be obviously understood.

It was long enough ago that I don't remember the details, and I'm not trying to bash anyone. I
had the same problem when dealing with the i3 protocol, and that was designed and implemented
by a bunch of uber guys who knew how to develop a network spec (one of whom went on to
be VP of security at McAfee and another chairman of the Apache Foundation). Comm protocols
are complicated and it's hard to think of everything that needs documenting and how to document it
in a readable way. Heck, one of these days read the FTP rfc and see how long it takes you to work out
how the passive ports are calculated.

I'm up to my eyebrows in my own project at the moment so I can't promise to contribute updates
to the spec, but I just wanted to confirm from my own experience that ghasatta is not incorrect in
his assessment.

-Crat
http://lpmuds.net

EDIT: clarified the nature of the i3 guys
29 Apr, 2009, Guest wrote in the 8th comment:
Votes: 0
Wasn't saying he was incorrect. It would simply be nice to know what's missing. The IMC2 protocol has been around longer than I've been involved, and the documentation that's been assembled was mostly reverse engineered from the code and from monitoring live packets. With Alsherok on one end and Xorith's old PHP Mud on the other. It's entirely possible we missed something.
29 Apr, 2009, Kelvin wrote in the 9th comment:
Votes: 0
I've had little trouble with it in writing Evennia's IMC2 connector. It took a while to get my mind wrapped around, but it was easy enough to learn and implement.
0.0/9