Difference between revisions of "ID System"

Revision as of 23:51, 17 April 2007

All ids are 64bit values, first 4 bytes determine category, last 4 is the objects id

categories:

0x00000000 -         // static objects, currently used(buildings,cells,terminals,chairs,bazzar,..)
0x00000000000C3500 // Additional Planets Static Buildings START
0x00000001           // travel terminals and for future expansion (LAST ID USED --> 4294967567)

   groups:

   0x000000010xxxxxxx  // terminals
   0x000000011xxxxxxx  // ticket collectors (DONE!)
   0x000000012xxxxxxx  // crafting stations

0x00000002 -         // characters, todo: see how much to reserve for each(increment)
0x00000003

0x00000004 -         // player vendors
0x00000006

0x00000007 -         // player mounts
0x00000008

0x00000009 -         // player ships
0x0000000A

0x0000000B           // static npcs(trainers,junk vendors)

   groups:

   0x0000000B0xxxxxxx  // trainers, increment by  2(object,inventory)
   0x0000000B1xxxxxxx  // filler NPCs, increment by 2(object,inventory)
   0x0000000B2xxxxxxx  // shuttles, increment by 2(object,inventory)
   0x0000000B3xxxxxxx  // junk vendors, increment by 2(object,inventory)

0x0000000C           // guilds

0x0000000D -         // mails
0x0000000E

0x0000000F           // unused

0x00000010 -         // missions
0x0000001A

0x0000001b -         // quests, todo: check, probably those are fixed ids
0x0000001f

0x00000020 -         // waypoints
0x0000002f

0x00000030 -         // auctions
0x000000ff

0x00000100           // resource containers

0x00000200           // resources

0x00000201 -         // dynamic structures(buildings,cells)
0x00000fff
   
   groups:

   0x00000201xxxxxxxx    // tutorial stations

0x00001000           // lairs

0x00001001 -         // dynamic npc
0x00001fff

0x00002000 -         // space objects(jtl)
0x0000ffff

0x00010000 -         // tangible objects(items)
0x000fffff

   groups:

   0x0001xxxxxxxxxxxx - 0x0002xxxxxxxxxxxx  // wearables
   0x0003xxxxxxxxxxxx - 0x0004xxxxxxxxxxxx  // foods
   0x0005xxxxxxxxxxxx - 0x0006xxxxxxxxxxxx  // furniture
   0x00070xxxxxxxxxxx                       // tickets
   0x00071xxxxxxxxxxx                       // crafting tools
   0x00072xxxxxxxxxxx                       // survey tools

0x00100000           // persistent chatrooms
0x00100001           // temporary chatrooms(groups)
0x00100002           // guild chatrooms
0x00100003           // other user chatrooms

0xXXXXXXXXXXXXXXXX    // draft schematics, first for byte of the id are the crc of the schematicobject, so they shouldnt be smaller than 0x0xxxxxxx
, last 4 byte represent the linked resourceweights batch

object ids:


on static objects:

category 0x00000000

- starts with 2
- inrement by 1, e.g. by 1 + cellcount for structures

Most are already ripped from the snapshots, you can find em in the static_objects tables.
So there are big holes, probably need to fill up that stuff with ids for chairs and other stuff from the ilf files.
Unfortunately those arent id'd and so can only be identified by their position.

category 0x00000001

- start with 1
- inrement by 1, e.g. by 1 + cellcount for structures


To sum it up.

Use linear id'ing for: static_objects,characters,vendors,trainers,mounts,ships,static npc,guilds,mails,
draft schematics,resources,skills,player structures,chatrooms

use random number id'ing for missions,auctions,lairs,dynamic npc,items,




On Character/NPC id'ing, from what i understand right now, plz correct me.

1. the character id would be the creature object id, so the main objects id, which we send with createobject().
2. with a containment msg this creature object is put into a player object, which id, lets say
   is a fixed offset from that creatureobject id
3. from there on we send updates to the client, creature specific(CREOs), referencing this creatureobject id and
   player specific(PLAYs), referencing the offset player id
4. procedure would be the same for npc
5. non npc -> creatures, dont need PLAY updates
6. we have an inventory object, which is set off from the creatureobject id
7. we have a mission_bag object, which is set off from the creatureobject id
8. we have a weaponslot object, which is set off from the creatureobject id
9. we have a hair object which is set off from the creatureobject id



On Object <-> cell linking

Currently it seems, we only need to send a containment msg when we want to load in to a cell.
The linked id would be the creatureobject id. Linktype would be 0xffffffff.
No containment msgs are sent, when entering/leaving a cell while in game
So this needs further testing..