How you have made room counting code in lpmud. like when player can see howm many rooms he have explored from total. i mean, without making every room to inherit one standard object or somthing, as that would limit builders from making different virtual and maze areas and stuff.

Please explain.

Let me get this straight...you want your builders to make their very own implementations of a base room? If they want a different kind of room, why not inherit /std/room.c and override functions in it? The whole philosophy of LPMUDs is based on reusing code and layers of inheritance. Each layer adds flexibility, it doesn't take it away.

We've suffered no lack of flexibility in our design by having a single base room object that all rooms have at the root of their inheritance tree, and we do some pretty funky things with it, such as our Underdark area, which creates rooms on the fly and our hex grid system for wilderness travel.

well ok then. lets forget virtual areas where there is only one object actualy but players think they see huge many rooms area. and forget different mazes where rooms are created on the fly. imagine allr oms are derived from standard room obj. how you make counting ?

Yes, let's. That is almost always a very poor design decision.

This is easily accomplished when using a base room class.

As for counting, here's what you need to do:

1) Design a robust system of assigning unique IDs to rooms
2) Design a scheme for storing the necessary information.

That's it.

Necessary UID characteristics:

Addition of new rooms must not alter the UIDs of existing rooms.

The UIDs of deleted of rooms must be removed and invalidated. The former is trivial, the latter less so. Failure to ensure the latter may result in players with exploration "scores" of greater than 100%.

The details will vary based on the design of the specific mudlib in question. A relatively efficient generalized implementation of this sort of system is actually fairly hard to design, though the problem can be simplified greatly if you can guarantee certain extra restrictions (e.g., no room will ever be deleted once it has been seen by a player).

Umm.. While I don't know a whole lot about LPC... A while back I was asking a wiz on the mud I play at how you would go about finding out the names or other information about say each existing piece of equipment in the game. According to what I was told you can get a list of loaded objects that are derived from a based class. All you would then need to do is count the total number of objects returned. Using an UID system seems like overkill if this works...

Note - This wouldn't work for rooms that do not load until some event or the like references them (like the ones created on the fly), which is essencially what the virtual rooms do, since they pull up the data for the room and insert it into the standard room object. However, I am not sure if such virtual rooms necessarilly get removed when they go inactive. If they stay in memory, then they would be in the list of derived objects as well.

I tried looking at the virtual code once for an LPC library that I tried using to play with (and was broken), but it confused the #### out of me at the time, so I don't know if they are created and destroyed as needed or if they just check to see if they exist already and create the room if needed. This would imho make more sense speed wise, but you never know.

Anyway, there should be a way to generate such a list. If the mud driver also has some sort of means to return the upper bound of the array generated (I assume it should), then you may not even need to count them, just get the bounds for the array. Now if you where counting unique objects of some sort...

That does not work. UIDs are necessary.

It also will not work correctly on DIKU unless all rooms are always loaded when the MUD boots up.

Well. That is the one drawback. It only returns instances of loaded objects. But your method isn't any better, since it assigns each UID as the room loads (apparently) then removes it later when it is unloaded. Or I don't understand what you actually mean. In any case it wouldn't work if each new room got a premanent UID, either since removing room 3962-3965 out of a 10000 room mud leaves a gap. You would have to literally reassign everything above the start of the gap and adjust the number or the count would never be right anyway. Short of storing all rooms in a database and executing something like 'FROM Rooms COUNT ALL' or whatever the SQL would be for it, there is no way to do better than giveing a rough (and inaccurate) guess or counting the existing loaded rooms.

I think you are answering the wrong question.

The original poster wanted to count the number of rooms visited by the player, not the number of rooms currently loaded.

Therefore the method, as JilesDM outlined, is to keep (for each player) some form of "list" of rooms visited, and count the number of items in that list.

The UID could be based on the filename, or the coordinates, or an integer similar to the vnum in dikurivatives, but it needs to be there to uniquely identify rooms for adding to the list (or ignoring, if already visited).

hmm. well UID for each room ... that would mean that each playerfile would store like 5000 room numbers player has visited? sounds like lot of resources needed. Wont there be too long evalution errors etc with so high ammount of data?

well i just wanted to know if there are anyone who have actualy made it? becouse there are lots of muds out there who do have that sort of feature. i guess in rom based muds its easier to implement though.