03 Oct, 2008, David Haley wrote in the 41st comment:
Votes: 0
What, it's a bad idea to enforce proper standards? I dunno, but it seems to me that people learning things the right way from the get-go is much better than allowing bad habits.

And we're not talking about style here, we're talking about things like const correctness, type conversion, etc.
03 Oct, 2008, quixadhal wrote in the 42nd comment:
Votes: 0
OK, here's my novel as the sequel to your novel! Hopefully it makes sense, I wrote little bits over the afternoon… :)

Davion said:
I think this is exactly where we should start. I also think it's a fairly simple answer. The g++ clean up of ROM.


Sounds good to me. I'll unpack that one and start taking a look this weekend. It might be a good idea to get a small sample survey of what environments/compilers everyone is using, just so we can know what bugs show up where. I'm using Debian (Etch) Linux, and gcc is at version 4.1.2.

Davion said:
Now, I'm not saying here that we should full on implement C++ into the codebase, but instead, allow the option for developers to do so if they please, without having to jump through the hoops of getting it to compile under g++.


I agree with this too. I'm no fan of C++, but there are very few thing (perhaps none!) that you can do in C, that a reasonable C++ compiler won't let you accomplish just as cleanly. Having the codebase be g++ clean also opens the door to use C++ wherever it's appropriate, such as the STL containers, the std::string class, and extensions for database access, etc.

Davion said:
On to the systems. The OLC will definitely be a big step. But seeing as we're trying to keep the feel of ROM I think Ivan's OLC is probably our best bet (1.81 if I may suggest a version.)


I'll happily defer to you on this one. My antique MUD doesn't have OLC at all, so as long as it's clean and mostly bug-free, it sounds good. That's another one that, like editors, we could eventually have multiple frontends if it's desireable.

Davion said:
Now, for additions to the OLC, I think we can't ignore the plea for a class and race editor. It's totally possible with the existing system. That said, you can't really just stop there. With those, you should also include an editor for the skill/spell table, as well as the groups, so one can easy modify the inner workings of the games without having to dig through the code. Also, for additions to the OLC, we could add ones for generic tables as well (like the bits, and pretty much everything in tables.c.) Along with that, we can remove most of the constants (like the OBJ_VNUM_*, MOB_VNUM_*, ROOM_VNUM_*, MAX_*) and put an online editor for those as well.


Fine with that too. I'm slowly migrating my own game to store everything in an SQL database, so eliminating everything that's hard-coded and allowing it to be modified on the fly sounds like the way to go here too. All that really means from the coder's point of view is that you can't get away with clever-but-ugly constructs anymore, but have to use thin wrappers for everything. if(ch->aff & AFF_BLIND|AFF_POISON) would become if(is_blind(ch) || is_poisoned(ch)). Sure, it's not quite as efficient, and it looks less hax0rzish, but we're not running MUD's on the C64 these days, and us old folks like things in big print. *grin*

Davion said:
Now for the progs.

Yep, buggy mprogs are junk. We'd have to clean it up and keep them for legacy suppport, but if we implemented a proper scripting system, we could translate them as the area files are being imported. Python is fine. I know we have Lua folks in the camp too. I like Ruby. I'd say let's go with whatever will embed with minimal fuss, since anyone extending the codebase will likely have to add or modify the interface to the scripting langauge as well.

Davion said:
Colour. Colour is a huge part of a MUD.

Heh, my MUD pre-dates colour too. :)

I do agree though. I helped do a rewrite of the colour code for AFKMUD a few years ago, and I think that's actually made it into the SmaugFUSS code as well. A discussion we had over at lpmuds.net a while back was interesting, as someone suggested a scoped color system, and I suggested using the diku color codes to make it less verbose.

I suppose, it would be quite useful to have some syntax (extension of Diku, or other) which allows for color class names rather than just hard-coded colors. Ideally, I'd like to be able to specify exact colors when I want them (&rRED&R text!), or specify class names when I just want things to be consistent (This will &(damage)hurt&R you!). Extending that to allow scoping too…. This &r(red text&) will &((damage)hurt&) you!

I would avoid using color tags for things like "say" or "tell" though. Those aren't properly things that you want to tag, those are things that want their own channel data. That channel may then be configured to be a certain color, or have a certain prefix tag, but it's a different purpose. Tags don't change the purpose of the data, only the presentation. If that makes sense.

Davion said:
That leads me to the database. Flatfiles verses and actual DB.

I'd put this on the back burner. Personally, I'd love a database, and I'm a PostgreSQL nut (having spent 10 years or so working with it), but having recently spent some time trying to work with ODBC in C…. not pretty. Using a native API is a pain, because we then have to pick a database – and you can't please everyone.

I would, however, encourage the idea of pretending we were moving to a SQL database. I'd be happy to (eventually) write up a schema based on the existing ROM file format too.

Why would that be helpful? See below for the bits part of the topic. :)

Davion said:
Now for the copyover. I think we should offer a little sugar on this one, and implement a seamless copyover that is barely detectable by players. I've gotten pretty close to this, to the point where there's almost no lag. You can view it in the MudConV codebase on this site. Just check acnt_cmd.c and comm.c for the meat of it. This comes -really- close to seamless, it only misses because it doesn't save mobs, combat, etc (mostly because the codebase lacks all these.) But I think it's a nice feature.


Not a deal breaker, but I don't object as long as it doesn't introduce any complications. I abhor the idea of doing a copyover on crash though… it's bad enough that most people run their games in a script that loops regardless of how the game exited.

Davion said:
Infinite bits. This is a tricky one. I happen to very much enjoy Runter's bitmask code, for implementing infinite bits (also available somewhere on this site.) However, most implmentations of infinite bits introduce some sort of data structure or array to the mix. The problem here, is with the object values, as they use an array of ints to set many default bits. We'll have to tackle that one once it's infront of us, and decide which way to go.


Here's where my SQL topic comes into play. I hate bits. They were great back when my MUD ran on a Sun 4/110 with 12Megs of RAM, and my game took up 7.5M of it. Now that even the refrigerator has 32M of RAM, and any decent site hosting will provide you with 128M+, there's no reason to pack lots of values into a single integer (or a cobbled-together set of macros to access an array of integers).

Well, in a proper SQL database, everything is stored as individual data elements. Part of the process of designing a database is called normalization, and it involves identifying what bits of data are properly seperate and making them distinct. For example, don't store the room flags as a single column, break it apart into seperate boolean values.

#3003
Cleric's Bar~
The bar is one of the finest in the land, lucky it is members only. Fine
furniture is set all around the room. A small sign is hanging on the wall.
~
0 CDS 0
D2
You see the entrance.
~
~
0 -1 3004
D3
You see the inner sanctum.
~
~
0 -1 3002
E
sign~
The sign reads:
Free instructions provided by the waiter:

Buy - Buy something (drinkable) from the waiter.
List - The waiter will show you all the different drinks and
specialties, and tell the price of each.
~
S


by something more like:

ROOM
Vnum 3003
Short Cleric's Bar~
Long The bar is one of the finest in the land, lucky it is members only. Fine
furniture is set all around the room. A small sign is hanging on the wall.
~
Area 0
Sector Inside
Flags NoMob Indoors Law~
EXIT
Direction south
Vnum 3004
Long You see the entrance.
~
Keywords ~
END
EXIT
Direction west
Vnum 3002
Long You see the inner sanctum.
~
Keywords ~
END
EXTRA
Keywords sign~
Long The sign reads:
Free instructions provided by the waiter:

Buy - Buy something (drinkable) from the waiter.
List - The waiter will show you all the different drinks and
specialties, and tell the price of each.
~
END
END


I would have had my example posted sooner, but I had to go paw through the header files to figure out what "CDS" meant. THAT is why bits are bad. :)

Note that Flags could have also been stored as three seperate lines, one for each bit that was set. In a Database, that's how it would have worked. If the room were a C++ class, it would also look like that, having separate accessor functions like room->is_NoMob(). In C, we'd have to use wrapper functions like is_NoMob(room).

To keep things dynamic at runtime, I guess we'd move to a property system, ala get_prop(room, "NoMob"). To be mutable at runtime, we can't use defines, enums, or the other usual ways to map ROOM_NOMOB into (C) or 0x04 or whatever, so we may as well use strings so the code is readable, and we may as well use the values we'd want in the files.
04 Oct, 2008, quixadhal wrote in the 43rd comment:
Votes: 0
Quick question… I noticed the filename for the G++ clean version of Rom 2.4b6 comes up as CleanedG++Rom24b5.tar.gz. I assume that's a typo, but just wanted to clarify before looking at something that's a version out of date. :)
04 Oct, 2008, quixadhal wrote in the 44th comment:
Votes: 0
Ok, round 1 was the easy stuff. Do we have a place to upload patches/additions/etc yet? I have a nice fat diff that is the fixes I've done tonight to make g++ happy with all the warnings I have enabled.

Believe it or not, -Wall does NOT enable all warnings. It enables all the default warnings, but there are quite a few that you have to turn on explicitly. Don't ask me, ask the GNU people. In any case, you can see all the gory details in the Makefile. You can also see a running commentary in the file HACKLOG, which I try to remember to always create and keep up to date in these kinds of projects.

Until I know where to put them, you can download the diff here, and a full tarball here. At least, I hope so. My ISP isn't very nice, which is why you have to use https to get in.

I did try running the game, creating a new character, and logging in. That's about it though, so if anyone else wants to give it a once-over, please do!
04 Oct, 2008, Davion wrote in the 45th comment:
Votes: 0
quixadhal said:
Quick question… I noticed the filename for the G++ clean version of Rom 2.4b6 comes up as CleanedG++Rom24b5.tar.gz. I assume that's a typo, but just wanted to clarify before looking at something that's a version out of date. :)

Yep. Good call on the typo. Eesh. I make far to many of those.
04 Oct, 2008, Darva wrote in the 46th comment:
Votes: 0
As i offered on the last thread talking about updating rom, I can provide hosting space, for web and shell space for an example mud. As long as you can put up with me occasionally forgetting to pay the bill, and having a day or two of downtime. *laughs*
04 Oct, 2008, Pedlar wrote in the 47th comment:
Votes: 0
for hosting, we can coax Davion to let us use MB space, since this is a in whole a MB project? to run an example mud, and some webspace for logs of bug fixes, and changes?
04 Oct, 2008, Davion wrote in the 48th comment:
Votes: 0
Pedlar said:
for hosting, we can coax Davion to let us use MB space, since this is a in whole a MB project? to run an example mud, and some webspace for logs of bug fixes, and changes?


Unfortunately, the MB server is pretty bogged down with the services/muds/webserver we've got going. I don't think it'd be wise to put it under more stress. But incase ya'll missed, Avaeryn already has a server up and running at sulinea.arthmoor.com 5489. So the hosting is already taken care of ;).
04 Oct, 2008, Pedlar wrote in the 49th comment:
Votes: 0
I did miss that :D, sick
04 Oct, 2008, Kline wrote in the 50th comment:
Votes: 0
I've got plenty of web/svn resources for anybody needing them on a variety of domains. Just no shell processes. (webhost, not a vps)
05 Oct, 2008, Avaeryn wrote in the 51st comment:
Votes: 0
Would it be premature at this point to suggest a round-table type discussion on the mud (sulinea.arthmoor.com:5489).

If everyone could try to be there at 7 pm EST tomorrow (Sunday), might be a good place to start. The discussion could last as long as everyone could devote to it.

Also, I think a project or project manager(s) are definitely needed as well as a to-do list. That might lead to volunteers for each item on the list. Dunno, what do you guys think?
05 Oct, 2008, Chris Bailey wrote in the 52nd comment:
Votes: 0
I think it's an excellent idea, I've been trying to get a couple people at once to figure out what's going on. I will do my best to be there but I'm leaving tomorrow morning for a tour of the Bell Witch cave and I'm not sure what time I will be back. In case anyone is curious the Bell Witch is the basis of several books and the movies "An American Haunting" and of course "Bell Witch: The Movie". =)
05 Oct, 2008, Avaeryn wrote in the 53rd comment:
Votes: 0
Chris Bailey said:
I think it's an excellent idea, I've been trying to get a couple people at once to figure out what's going on. I will do my best to be there but I'm leaving tomorrow morning for a tour of the Bell Witch cave and I'm not sure what time I will be back. In case anyone is curious the Bell Witch is the basis of several books and the movies "An American Haunting" and of course "Bell Witch: The Movie". =)


Hopefully you can be there. I saw that cave on a television special once. It's an interesting place. You'll have to share your experience with us when you return.
05 Oct, 2008, MacGregor wrote in the 54th comment:
Votes: 0
Okay, this sounds like a project I could get into. I'll be at the meeting tonight.

One thing we need to do is to establish just what it is we're trying to do here. Bug fixes and cleanups, of course. OLC, I'd say definitely. A bunch of other things too, probably. Contrariwise, I don't think we want to add a bazillion races, classes, spells, skills, etc. We want to do an improved ROM, not another DoT.

One thing I think we need to set up as soon as we can is a SVN or CVS repository.

By way of introduction, I've been coding for a couple years now; my first mud was a Circle 2.2 running as a door on a dialup BBS. I'm currently working on a project that started out as stock Rom 2.4b6 in 2002. I believe a couple people on the board here know me and have seen some of the work I've done.
05 Oct, 2008, MacGregor wrote in the 55th comment:
Votes: 0
quixadhal said:
Ok, round 1 was the easy stuff. Do we have a place to upload patches/additions/etc yet? I have a nice fat diff that is the fixes I've done tonight to make g++ happy with all the warnings I have enabled.

Believe it or not, -Wall does NOT enable all warnings. It enables all the default warnings, but there are quite a few that you have to turn on explicitly. Don't ask me, ask the GNU people. In any case, you can see all the gory details in the Makefile. You can also see a running commentary in the file HACKLOG, which I try to remember to always create and keep up to date in these kinds of projects.

Until I know where to put them, you can download the diff here, and a full tarball here. At least, I hope so. My ISP isn't very nice, which is why you have to use https to get in.

I did try running the game, creating a new character, and logging in. That's about it though, so if anyone else wants to give it a once-over, please do!


I downloaded it last night and tried compiling it with g++ version 3.4.6 and it bombed on comm.c:

comm.c: In function `void act_new(const char*, CHAR_DATA*, const void*, const void*, int, int)':
comm.c:2443: warning: cast from `const void*' to `CHAR_DATA*' discards qualifiers from pointer target type
comm.c:2444: warning: cast from `const void*' to `OBJ_DATA*' discards qualifiers from pointer target type
comm.c:2445: warning: cast from `const void*' to `OBJ_DATA*' discards qualifiers from pointer target type
comm.c:2512: warning: cast from `const void*' to `char*' discards qualifiers from pointer target type
comm.c:2513: warning: cast from `const void*' to `char*' discards qualifiers from pointer target type
comm.c:2536: warning: cast from `const void*' to `char*' discards qualifiers from pointer target type
comm.c:2542: warning: cast from `const void*' to `char*' discards qualifiers from pointer target type
make: *** [comm.o] Error 1
05 Oct, 2008, Caius wrote in the 56th comment:
Votes: 0
These are all related to casting from const to non-const. In the function you mention you have lines like this:
CHAR_DATA *vch = (CHAR_DATA*) arg2;

arg2 is of type const void*, but you cast it to vch which is a pointer to a non-const CHAR_DATA. As to why your compiler balks, yet newer compilers accept it I'm not sure. But I think a compiler should react to this. In the long run it's a good idea to start using const a lot more. For example, further down in the function you have this:

PERS( vch, ch );

If we take a look at the PERS macro we see for example that it uses the can_see( CHAR_DATA*, CHAR_DATA* ) function. So it may be a good idea to change that to can_see( const CHAR_DATA*, const CHAR_DATA* ). Then we also have to go into the can_see function and look at which functions it calls, and change those to using const as well. Etc, etc. This is obviously a time consuming job, because adding even one const tend to have a cascading effect.

Whenever I see a predicate function returning a bool, like can_see, I intuitively expect it NOT to change any data. As such using const in the arguments doesn't only enforce this, it also tells me what I need to know, without having to look up the function body.

So I guess my contribution to this thread is to start using const whenever you can possibly get away with it. :cool:
05 Oct, 2008, Pedlar wrote in the 57th comment:
Votes: 0
Avaeryn, I will be there tonight, or alteast try my best, gotta pick my sister up from work at 7:30 i think, but ill be here :D, Im always here :D
05 Oct, 2008, MacGregor wrote in the 58th comment:
Votes: 0
Caius said:
These are all related to casting from const to non-const. In the function you mention you have lines like this:
CHAR_DATA *vch = (CHAR_DATA*) arg2;

arg2 is of type const void*, but you cast it to vch which is a pointer to a non-const CHAR_DATA. As to why your compiler balks, yet newer compilers accept it I'm not sure. But I think a compiler should react to this. In the long run it's a good idea to start using const a lot more. For example, further down in the function you have this:

PERS( vch, ch );

If we take a look at the PERS macro we see for example that it uses the can_see( CHAR_DATA*, CHAR_DATA* ) function. So it may be a good idea to change that to can_see( const CHAR_DATA*, const CHAR_DATA* ). Then we also have to go into the can_see function and look at which functions it calls, and change those to using const as well. Etc, etc. This is obviously a time consuming job, because adding even one const tend to have a cascading effect.

Whenever I see a predicate function returning a bool, like can_see, I intuitively expect it NOT to change any data. As such using const in the arguments doesn't only enforce this, it also tells me what I need to know, without having to look up the function body.

So I guess my contribution to this thread is to start using const whenever you can possibly get away with it. :cool:


I realize what the cause is, in fact I started fixing it, my comment was more in the nature of notifying quixadhal that it didn't compile cleanly for me; I got the impression from his post that it does so for him.
05 Oct, 2008, Caius wrote in the 59th comment:
Votes: 0
MacGregor said:
I realize what the cause is, in fact I started fixing it, my comment was more in the nature of notifying quixadhal that it didn't compile cleanly for me; I got the impression from his post that it does so for him.

Whenever I said "you" I didn't mean you specifically. :wink:
05 Oct, 2008, MacGregor wrote in the 60th comment:
Votes: 0
Caius said:
MacGregor said:
I realize what the cause is, in fact I started fixing it, my comment was more in the nature of notifying quixadhal that it didn't compile cleanly for me; I got the impression from his post that it does so for him.

Whenever I said "you" I didn't mean you specifically. :wink:

Heh, okay, fair enough. Still and all though, you're right; we should certainly use const when applicable. It can be a nuisance, though, when the compiler complains because you're comparing a const pointer to a non-const pointer. Or when you're loading a table at bootup which should be considered read-only afterwards.
40.0/181