Good Morning,

I prob was gone when this was a hot topic, but I am wondering if smaugfuss team ever thought doing something like Nick Gammon offered for a solution with GUID.

In the past I always hated having a long number by the object or mob as a player. However, I do see how in smaug typing 2.sword or whatever can get confusing for players. I wonder if it would make sense to try something like this, but make it a config, so a player can turn it off at will. So they are not dealing with a ton of same vnum objects or mobs they don't have to see it. What were the pros and cons of doing this, has anyone done it?

http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=10099&page=999

It seems like it's only really useful for custom/graphical clients.

I can't imagine most players would enjoy typing something like:

get sword#18277172

FWIW though, the LPMUD universe treats clones that way, but the ID is not unique across all objects, it's simply unique for a given object.

For example, you might have a sword object "/domain/fooland/item/sword.c", and if there are 12 copies of it in the game, they can be referenced by "/domain/fooland/item/sword.c#7". The usual parser still applies local logic, so situations like "get second sword" will still refer to the second sword in the local environment, but if the game were to display the clone numbers, you could use the instance numbers as well.

Interesting. Yah I hate the large numbers, but you can type get sword, or get 32523sword.

So I was thinking something like that might be neat, if you add a config so players can turn it off
and do get 2.sword if that is what they want.

I know I have a lot of tradeskills with the same vnum for the objects crafted, so 2.sword, etc really
does not work well.

Would be better though if instead of a large number could maybe be based on object->type
such as. if item_type->weapon GUID = a1sword or something like that to shorten it. I know it is
mud dependant, but I will never have more then 100,000 vnums tops in my game, so just
thinking there could be a better way to shorten it so easier for players to use.

It really boils down to how unique you want things to be.

The GUID concept is really an "object ID", which means every instance of every object will have a unique identifier. That's useful in cases where everything in the game shares a common data structure (many MMO's), and so getting a pointer to GUID 3 and another to GUID 827711 are both useful things to do.

However, most Dikurivatives have rooms, mobs, objects, and players ALL as seperate kinds of pointers. So, if GUID 3 is a room, and GUID 3281 is an NPC, it's not useful. You'd need your lists to be all void pointers, and then you'd STILL have to look up the type so you know what to cast it back to.

Further, items are, as you said, split up by item_type, which means many of the fields will be reused for different things. Accessing a scroll's data structure without knowing it's a scroll is not useful.

If you're stuck in vnum-land, you can still use the concept of instance ID's. You just keep a unique ID for every different vnum. So, when you create a new copy of vnum 3001, perhaps it gets ID 337. Next the the game boots, you'll make another new one which might be ID 400. When a player gets one and saves it in their inventory, that ID number will remain... so while the next respawn/reboot might yield sword #922, the one the player is carrying will always be sword #400.

As for confusion between different vnum's... that's your fault, as a builder.

If you make two swords that are indistinguishable when lying on the ground, despite being different vnums, you failed. You should have either used the same sword and not had the other one, or you should have changed the descriptions of one to make it unique. Note that keywords != descriptions.