04 Jan, 2009, BleaS wrote in the 1st comment:
Votes: 0
Pre-ramble:
So, having learned the fundamental ins and outs of codes and playing a MUD got me curious into seeing how one works. At this moment in time I don't intend to actually run a MUD, I wouldn't consider myself a competent enough coder, don't have the funds or resources to support one, and while I have plenty of great ideas for a MUD, making one yourself isn't really the best way to go about it unless you know you can get a dedicated user base. In any case, I do want to compile some MUDs to look at and possibly (time allowing) get into editing the code and playing around a bit as I've always learned well that way.

Actual Problem:
I've successfully compiled Circle MUD 3.1, and it was interesting to look at the code for that game. I've also compiled SMAUG 1.4 successfully, also interesting. I wanted to look at some of the more recent stock MUD codebases, and that's one of the places I'm getting lost since recent seems to be very relative for any of the stock codebases, even if there there are still other MUDs based on them that continue on to this day.

I decided to try out ROM 2.4b6 but I'm getting errors during the compiling process. I don't get an output file, and even if I did, I suspect it might not be supported very well since the websites I've seen for it havent been updated in years. But here's the errors I get:



Any help I could get, including possible links to more modern MUD code stock would be neat.
05 Jan, 2009, Kline wrote in the 2nd comment:
Votes: 0
Look at lines 54 and 56 in your db.c file. Your standard included libs have already defined a 'random' and 'srandom' function for you while ROM is trying to implement its own. Also I'd suggest poking around here for the latest link to the 'RaM' project as they're just taking the ROM 2.4 you're using, fixing bugs, and making it a little bit more modern.
05 Jan, 2009, BleaS wrote in the 3rd comment:
Votes: 0
Is it at a point where I can use it (RaM) or? And would that be the most modern stock code-base we're looking at? Thanks for the help :)
05 Jan, 2009, Zeno wrote in the 4th comment:
Votes: 0
I assume RaM > Rom.

Most modern? No, I assume something like SmaugFUSS or TBA has had more time to evolve compared to RaM.
05 Jan, 2009, BleaS wrote in the 5th comment:
Votes: 0
For line 54 and 56 I just see pointers that do not seem to be doing anything with random.

from db.c said:
/* externals for counting purposes */
extern OBJ_DATA *obj_free;
extern CHAR_DATA *char_free;
extern DESCRIPTOR_DATA *descriptor_free;
extern PC_DATA *pcdata_free;
extern AFFECT_DATA *affect_free;
05 Jan, 2009, quixadhal wrote in the 6th comment:
Votes: 0
Zeno is correct. RaM is still in the egg, as it were. I'd like to think the code is cleaner and somewhat easier to read than stock ROM, but I won't yet claim much else. :)

If you don't mind the bugs, QuickMUD is probably about where RaM will be in another month or three… feature wise.

If you aren't set on a ROM-style base, do check out both SmaugFUSS and TBA. They're both very solid places to start.

I don't know, perhaps your cygwin gcc is getting the line numbers wrong? The errors are from something in ROM code declaring a prototype for the system routines random() and srandom(), and THOSE have different types than your standard library's headers. It's generally not a good practice to hand-prototype anything that isn't part of your own code, since it can (and will) change over the years.

I'd grep for random/srandom and comment out the prototypes. We removed ALL of that kind of thing from RaM.
05 Jan, 2009, Tricky wrote in the 7th comment:
Votes: 0
Somewhere near the top of db.c with all the other #include's put this line…
#include <stdlib.h>

It probably is there already so yoiu may not have to add it. Then just delete the offending extern srandom and extern random lines.

Tricky
05 Jan, 2009, BleaS wrote in the 8th comment:
Votes: 0
quixadhal said:
Zeno is correct. RaM is still in the egg, as it were. I'd like to think the code is cleaner and somewhat easier to read than stock ROM, but I won't yet claim much else. :)

If you don't mind the bugs, QuickMUD is probably about where RaM will be in another month or three… feature wise.

If you aren't set on a ROM-style base, do check out both SmaugFUSS and TBA. They're both very solid places to start.

I don't know, perhaps your cygwin gcc is getting the line numbers wrong? The errors are from something in ROM code declaring a prototype for the system routines random() and srandom(), and THOSE have different types than your standard library's headers. It's generally not a good practice to hand-prototype anything that isn't part of your own code, since it can (and will) change over the years.

I'd grep for random/srandom and comment out the prototypes. We removed ALL of that kind of thing from RaM.


Right after you posted I did a grep and found the srandom and random in the file but haven't had time to remove them. Thanks to you and Tricky for the help, hopefully it will work.

As far as style, I like the style set forth by the MUD I play which is based off of Merc MUD with snippets from SMAUG and of course credits ROM and Diku as per the hierarchy. However, the MUD I play is heavily customized and I know I wont have anywhere near the features, but if I can find something close to that, it would be neat. I play Dark and Shattered Lands, for the record. dsl-mud.org:4000
05 Jan, 2009, Tyche wrote in the 9th comment:
Votes: 0
quixadhal said:
I don't know, perhaps your cygwin gcc is getting the line numbers wrong?


Far more likely the user quoted lines 61-67 of db.c than gcc being broken.
06 Jan, 2009, BleaS wrote in the 10th comment:
Votes: 0
I think I'll wait for RaM, unless there are other suggestions. I'm not getting a undefined reference error, so I made sure all of those were declared and I'm still getting the error, plus a ton of warnings.
0.0/10