08 Aug, 2010, Zula110100100 wrote in the 1st comment:
Votes: 0
for( iHash = 0; (pRoom = room_index_hash[iHash]);iHash++) {
for( ; pRoom!=NULL;pRoom = pRoom->next) {


Making sure that this will go through every room in the mud, is there a better way to do it? Pulled this from some olc stuff.
08 Aug, 2010, Davion wrote in the 2nd comment:
Votes: 0
That's the only way. Rooms in ROM are stored in a hash tree (room_index_hash) and you need to iterate through the hash (for( iHash = 0; (pRoom = room_index_hash[iHash]);iHash++)) and then iterate through each of the hash buckets (for( ; pRoom!=NULL;pRoom = pRoom->next))
09 Aug, 2010, Scandum wrote in the 3rd comment:
Votes: 0
One option is to replace the hash tree with an array. It's faster, easier, and uses about the same amount of memory.
09 Aug, 2010, David Haley wrote in the 4th comment:
Votes: 0
Scandum said:
One option is to replace the hash tree with an array. It's faster, easier, and uses about the same amount of memory.

While it is easier, it uses more memory, assuming a sufficiently large number of holes between rooms. It also ties you in to the model that room identifiers are necessarily numbers. A map approach is far more flexible.

It would be relatively easy to fix things here – what's dumb is the way the list of rooms must be accessed, by directly manipulating the low-level implementation of the data structure.

As usual, implementation and API should be separate, or you end up with dumb access patterns.
09 Aug, 2010, Runter wrote in the 5th comment:
Votes: 0
Meh. Something stinks about the array idea to me. Its not the most flexible solution. You really don't need to worry about having the o 1 access time. Also I wouldn't worry about using a little extra ram. The lame thing is you'll have to implement a relatively simple data structure that doesn't exist in c.

I don't like the intrusive linked lists. The easiest solution as a user to me would be to use a c++ data structure such as std::map.
09 Aug, 2010, David Haley wrote in the 6th comment:
Votes: 0
The linked lists are there only because the implementation is exposed to the user; hash tables typically use linked lists under the hood after all to implement the buckets. A sane API would make them near-invisible.
09 Aug, 2010, Runter wrote in the 7th comment:
Votes: 0
Yeah, but I would prefer the linked list not be built into the struct in question.

An actual container object is more appealing to me.
09 Aug, 2010, David Haley wrote in the 8th comment:
Votes: 0
What I mean is that the implementation is (or should be) irrelevant – you wouldn't see it. An "actual container object" of a hash table is all but certainly going to have linked lists under the hood as well – you just won't notice it (which is how things should be).
09 Aug, 2010, Runter wrote in the 9th comment:
Votes: 0
That implementation under the hood shouldn't be intrusive and define variables on contained objects.
.
I understand the point your making and its irrelevant to what I'm saying.
09 Aug, 2010, David Haley wrote in the 10th comment:
Votes: 0
Then I don't know what you're saying… you reject an implementation in favor of an "actual container object". What does that even mean? Is the container object not going to have its own under-the-hood implementation details? It sounds like what you want is a sane API, which is what I've been saying all along here……
09 Aug, 2010, Runter wrote in the 11th comment:
Votes: 0
I'm on my phone so this will be my last in this back and forth.

I'm saying that the implementation under the hood shouldn't be intrusive except with very specific reason.

An example of something not intrusive is a linked list with outside pointers to the data. Not the data itself acting as each node.

I haven't been disputing anything you're saying.
09 Aug, 2010, David Haley wrote in the 12th comment:
Votes: 0
Well, I guess I found what you wrote confusing since it was phrased as disagreement, and you were objecting to the linked lists being part of even the implementation (cf. "built into the struct in question"). If we're in agreement, then all is well in the world… :wink:
09 Aug, 2010, Davion wrote in the 13th comment:
Votes: 0
Scandum said:
One option is to replace the hash tree with an array. It's faster, easier, and uses about the same amount of memory.


Ya know, suggesting this particular implementation in this condition seems a bit… wrong. Considering to cycle through every element of the array, you'd have to go through every spot regardless of the room existing or not. In this case, with the hash tree, you're wasting very few iterations.
09 Aug, 2010, Runter wrote in the 14th comment:
Votes: 0
Well yes. If the indicies are the vnum. Of course if they aren't then you'd have to search for any lookup.
09 Aug, 2010, Runter wrote in the 15th comment:
Votes: 0
Well yes. If the indicies are the vnum. Of course if they aren't then you'd have to search for any lookup.
09 Aug, 2010, JohnnyStarr wrote in the 16th comment:
Votes: 0
Runter's phone is funny :p

IMO, looping through every room in the mud isn't really the best choice.
Not that you don't have to peform instructions on many rooms, why not maintain a
seperate list of rooms for events. For example, if there are only 4 players logged on, and
all 4 are in Midgaard, why would you care about Moria, The Shire, or The Fire Swamp?

In other words, I know C is effcient, and the memory footprint is trivial, but that doesn't mean
that you shouldn't develop a more sophistcated update / event system.
09 Aug, 2010, Oliver wrote in the 17th comment:
Votes: 0
Well. Persistence, for one thing; I feel like on an ideal MUD, the tree does fall in the forest if there's no one around to hear it.

Edit: besides, if you want something to only occur for players, you can just use the list of players and their ->in_room data without a separate list?
09 Aug, 2010, Runter wrote in the 18th comment:
Votes: 0
I don't understand why persistence is relevant here.
09 Aug, 2010, Oliver wrote in the 19th comment:
Votes: 0
If events only occur when players are in a room, it removes the possibility for events to occur regardless of player presence. The world stops being persistent.
09 Aug, 2010, Runter wrote in the 20th comment:
Votes: 0
I believe the only criteria for the label of persistence is that state wholey persists across a reboot.



Also, event driven really doesn't mean only in rooms with players.
0.0/46