10 Aug, 2010, Scionwest wrote in the 1st comment:
Votes: 0
I saw online today that MUD's use a unique ID typically for each object that exists in the game world. Up until this point I had been using string that held the objects Name, and that was how I saved the files and accessed them from within the game. The issue of having multiple objects with the same name, but a different variation of the object came up, and the only way to do this was by modifying the Name so that it was unique in some way, as the filename for the object was the objects name, and searching through the game object array for the object was done by passing the name of the object off as a method parameter.

So I decided to convert everything to use a unique Long that would hold the ID for each object. Do you guys see any reason why you would not use this approach?

Btw I'm doing this in C#.
10 Aug, 2010, Kline wrote in the 2nd comment:
Votes: 0
I've wanted to look for an easy to implement UUID system for awhile; let me know if you find/create one :)
10 Aug, 2010, Idealiad wrote in the 3rd comment:
Votes: 0
UIDs definitely are one method. I think Tyche demonstrated a dual ID/string method but I can't remember where that was.

Also don't LP muds use a kind of URI, like area/race/mob or something like that?
10 Aug, 2010, Scionwest wrote in the 4th comment:
Votes: 0
Idealiad said:
UIDs definitely are one method. I think Tyche demonstrated a dual ID/string method but I can't remember where that was.

Also don't LP muds use a kind of URI, like area/race/mob or something like that?

I'm not sure, I'm flying by the seat of my pants really with building the engine. I can look into something like UID's, the only issue I am having is figuring out which Room (ID9) and Room(ID14) is the correct one to deliver to the client if a multiple rooms with the same name exist. I'm still tinkering with it.


Kline said:
I've wanted to look for an easy to implement UUID system for awhile; let me know if you find/create one :)


You using C#? I can paste source for you or something once i get it worked out.
10 Aug, 2010, quixadhal wrote in the 5th comment:
Votes: 0
A typical lpmud path would be "/domain/beerland/swamp/npc/goblin.c#37". The NPC in question is a goblin, specifically the one defined in the swamp area of beerland. The #37 (which may not be used these days) was the clone number, which distinguised a particular swamp goblin of beerland from other such goblins. The goblin in question might not be IN beerland, since he might have chased a player into "/domain/winerealm/forest/room/path13.c", which is just a forest path type room in winerealm. Since one typically has only a single instance of a room, you wouldn't expect a clone number after it.

You could also just track the instance number of each object as you create it. So, loading a copy of vnum 1372 would bump a counter by one and that thing would be identified by vnum and instance numbers. If you use 32-bit integers, you have to create 4 billion instances of an object before you need to worry about duplicates.
10 Aug, 2010, donky wrote in the 6th comment:
Votes: 0
quixadhal said:
A typical lpmud path would be "/domain/beerland/swamp/npc/goblin.c#37". The NPC in question is a goblin, specifically the one defined in the swamp area of beerland. The #37 (which may not be used these days) was the clone number, which distinguised a particular swamp goblin of beerland from other such goblins. The goblin in question might not be IN beerland, since he might have chased a player into "/domain/winerealm/forest/room/path13.c", which is just a forest path type room in winerealm. Since one typically has only a single instance of a room, you wouldn't expect a clone number after it.

You could also just track the instance number of each object as you create it. So, loading a copy of vnum 1372 would bump a counter by one and that thing would be identified by vnum and instance numbers. If you use 32-bit integers, you have to create 4 billion instances of an object before you need to worry about duplicates.

Isn't it the case where clone numbers are not persistent. So if you persist the object and reload it back in, it will have a different clone number. Ideally, an ID system should be able to persist an object under that ID and link it to other information which refers to that specific instance of an object directly.

Now, with that additional constraint in mind, I am reminded of the VMS operating system. Basically, IIRC you could use version numbers in any file name. If you wanted the sixth revision of file "foo.c", then you would open "foo.c;6". You could have a per-script instance number pool, which was incremented for each new and unique instance. Where the instance numbers were persisted, so that serialised object instances didn't get clobbered. Then "foo;6" would uniquely refer to the 6th instance of the script "foo".

Of course, that's way more work than needed. The simplest form is to use an integer that starts of at zero, and gets incremented with each new object instance, whatever that object is. I've worked on a game where there were hundreds of thousands of players, and eventually that number had to be upgraded from an int to a bigint. In the meantime, I think there was ID recycling. And also object instances that were never going to be persisted got IDs from the negative domain, where each game startup the pool started from -1 again.

Anyway, just some thoughts.
10 Aug, 2010, Kline wrote in the 7th comment:
Votes: 0
Scionwest said:
You using C#? I can paste source for you or something once i get it worked out.


C++, I'd be willing to do the conversion legwork. One my drive to work last night I considered hashing the name of the room the obj loaded in, the name of the obj, and the time it loaded. Then hashing all 3 together. Just curious how well it would work in practicality or collisions.
0.0/7