-
Hi all,
Various people have expressed an interest in UIDs, a feature I've had to implement on a limited-basis to accomodate the wilds v2 code. This thread is intended to explain what UIDs are, how they are implemented and how they should be employed in-game (assuming of course, that the code is adopted into the main build).
UIDs are "Unique IDentifiers", much like vnums, except that vnums refer to the originating index of an entity, not the entity itself. A hypothetical example to clarify this point is necessary:
Object: A Sword called "Bert".
Vnum : 100
This is the index or template, if you will, of the object - this is a reference to the "obj_index_data" structure stored in the area file. Then we "load obj 100", which creates an "instance" of that object, referring to the obj_data structure. These are also stored seperately in the area file should the object be loaded up by the area/room/mob, or stored in the players pfile should they be in possession of the object. However, there is currently no way to directly reference a particular instance of a loaded object, with the exception of the in-game method (1.sword, 2.sword etc). This is where UIDs come into their own.
The premise is that there is an absolute, unique identifier code for each and every instance of an entity in the game. For the wilds v2 code I've only implemented area/wilds/vlink UIDs for the moment, with mobs/objects to follow. When the game starts up it loads up a config file called gconfig.rc, containing a counter value for the next unused UID for each type of entity:
NextAreaUID 123
NextWildsUID 3
NextVLinkUID 27
UIDs are of course, unsigned longs, so you've got about 2.4 billion of them before it cycles around.
Areas:
It was necessary to implement UIDs for areas because area files themselves can be loaded in any order from the area.lst file. The game doesn't really care as long as the vnum range for the area isn't being used anywhere else. The problem is that the wilds does care, and I didn't want to go faffing about with hard-coded area names all over the code. An area with a UID can be loaded in any order you like and the code will still find that code. You can have two copies of the same area, and still be able to access the one you intended as long as they both have different UIDs.
Wilds:
In order to implement multiple wilds sectors within a single area (so making wilds files children to a parent area), UIDs were required in order to directly reference a particular wilds sector. This is handy in itself - a new command "goxy" that allows an imm to jump to a particular map reference in a wilds, also takes a third argument for the wilds UID file, i.e "goxy 433 448 1" puts you at the crossroads outside the eastern Plith entrance, regardless of where you were in the game at the time. I can add hundreds of other wilds files, even copies of the sent wilderness and still be able to jump directly to the same place in the same wilds. Correspondingly, if a particular instance of wilds is missing, you can't jump to another one and start editing by mistake - the code will warn you that the UID isn't available.
VLinks:
VLinks are an odd one. When i set out with the wilds code, vlinks were just links between wilds and areas. Due to one thing or another, and a lot of input from people like Nib, they're gradually becoming an all-purpose dynamic link, modifiable by scripts (eventually). UIDs allow things like a mob in the wilds being able to link or unlink a VLink from script - unlink THAT link in THAT wilds sector, at THIS location.
Mobs/objs:
Mobs and objects are probably where UIDs will come into their own. mobs and objects start out as reloadable indexes, or templates. The game then loads up each instance of them with stats within a defined range of values. UIDs allow you to load up a particular mob/object and be able to reference THAT particular one directly. This lends itself to things like mob memory, directly accessing the values/tokens of specific mobs/objects, accessing or modifying the affects on something.
That's it. Any questions, suggestions, show-stoppers, fire em into this thread.
Cheers,
Scott.