[camlorn]

horrible, perhaps, was the wrong word. It's more that I would do it a different way because my way would be marginally better--I see arrays, I see the words "add to", and a little part of me dies inside, because I'm one of those coders who codes things to be beautiful and functional for the next thousand years, and I'd have gone and modified the whole codebase to store the area list sorted (which is more than you need). Also, when I originally wrote that part, I thought one of the following loops was going to involve some odd c syntax. Also, I just took the final for a class called data structures yesterday which talks about what to use instead of arrays and why and when you would want to use them.

The truth is, because muds are now so little compared to even your word processor, you can do all sorts of this-is-awful coding, and it'll still run plenty fast [1].

The code I gave you was the easy way. The hard way is dynamically allocating arrays.

The MAX_AREAS looks something like this:
#define MAX_AREAS 1000
Somewhere in merc.h. The number needs to be larger than the total number of areas you're likely to have. In gcc, I believe you can use a variable for array allocation, so it may be possible to declare the array in a smarter fashion, but let's not go there right now. I don't think you're overly worried about losing 4kb ram. If you have over 1000 areas, well, time for me to come play your mud.

The proper way to iterate through a hashtable is a bit more complicated, and highly implementation specific. Again, let's not go there. Just be aware of the phenominon I call drunken coding, where people want to be "cool" and use them in places they shouldn't be used, i.e. the area list. If you can't get this working, at all, that's worth checking. Knowing about hashtables, binary search trees, and linked lists are really cool and will help you understand what is going on in a lot of the code in your mud, but is by no means necessary for this (I just finished a class on them as part of my computer science major, so I have them on the brain). The ->next bit in rom coding seems to be highly context sensitive, even on the same object, and it can be a bit tricky to be sure what you're iterating through (All effects on the mud? on the player? Is that all objects, or all objects in this room? etc.) [1].

1: I'm super complete in my answers, giving every detail that I think might be pertinent, even if most of me knows that it is not going to be the slightest bit helpful. I tend to write code for efficiency, even when no one will see the gains without a profiler. My solution would be to sort the area list in-place, because we save about 4k ram, and to modify the mud to always insert areas in the correct position to keep it sorted (not a small task--this is why I have never got a mud under way. I spend too much time on what is "best", and never code it unless someone is breathing down my neck). Basically, I try to be helpful, but have trouble letting it go at "this is the simplest way". I read the gcc c extension manual for fun, for example, so that I know what kind of things I can get away with.