Brainstorming: Partial DB Standard

[cavedude]

Originally Posted by GeorgeS

That's correct

No it isn't, not starting anything here but my database is my own. I started it from scratch.

As for a standard, that is something DRP is working on. I have already begun stripping my database apart and re-organizing all IDs to fit a standard. Duplicate mobs, loot, and faction entries will all be removed as well. The problem is there are essentionally 3 different databases out there (and yes, they are all quite different and have their own strengths/weaknesses) so the other two databases would need to go through the same perging mine is to fit a standard. Any database built from EQBuilder follow the zonenumberid*1000 standard but as Sesmar and I were discussing on our forum, after the zone is initially built, new entries either get tacked on to the end of the db, or somewhere in the middle causing a mess. Our db editing tools will need to be updated to follow the standard. Again, with 3 different databases and multiple people making cool editors how will that work? While I'll continue work on my own database, I am all for a standard and I'll work with whomever I need to to create and follow one.

[Damilis]

Well, my issue is with linking NPCs with zones is that many NPCs can exists in many different zones... so what then? I am thinking that simply blocking off the first two or three hundred thousand NPCID's and just having the NPCs there, in no particular order. If you attempt to order in any way, then you introduce ambiguity to your standardizing system. Just make it so that all non-custom NPCs are ID <300,000 and standardized from db variant to db variant.

[cavedude]

We thought about that, too. I like having the NPC ID being based on the zone ID because then you can look at its entry and say hey, this guy is in Overthere. It makes world building MUCH easier. Part of the purge I am doing to my database involves deleting duplicate identical mobs and updating their spawn entries to the single NPC entry. Those mobs that are "universal" and are found in multiple zones I feel should have their own block of reserved IDs, possibly in the 800-900k range (or some other obscure number that will probably not get a zone assigned to it any time soon by SOE) That way, when world builders look at a tree snake for example, they can automatically tell by its ID that hey, this guy is a roamer.

[John Adams]

That's pretty much exactly how I picture it, Cavedude. One question though - regarding memory utilization. I [assume] with items, the higher the item ID, the more memory it takes to load them all in... I assume this because of the 100k cap. Now, do NPCs have this same memory issue when a zone boots or is made static? Say you have 900 NPCs in zone 123, so NPC id 123000 - 123900. Then add 500 roamers (totally exaggerated populations, i agree) starting at 800000-800500. What will happen to that zones memory consumption? Will the zone allocate RAM for all the empty (but possible) spaces between 123900 and 800000?

I'm having a brain fart, so forgive me if I am totally on crack at the moment. I love publicly humiliating myself. Chicks dig it, too.

[Rhodan]

I'd like to know too.

If the database has two items, #1 and #2,426,333,000, will that use enough ram for 2,426,333,000 items or will it use enough for two items?

The whole idea of cutomized/allocated ID numbers flies out the window if the former is the case.

[eq4me]

Originally Posted by Rhodan

I'd like to know too.

If the database has two items, #1 and #2,426,333,000, will that use enough ram for 2,426,333,000 items or will it use enough for two items?

It certainly appears so, at least with some tables that are loaded into shared memory.

Originally Posted by Rhodan

The whole idea of cutomized/allocated ID numbers flies out the window if the former is the case.

I bet there is no way for the routine that is reading the tables to determine what is actual data and what is just the unused default value defined for the table. Someone with time an skill has to look into the source and find out how exactly tables are read into shared memory and change it so that not needed entries(the ones with the default value)are not using up memory. I know I am not explaining it right but I dont have much time right now. I think something in the line of double pointers. so eg. item[ID] does not hold the data but a pointer to it. So item[1001] to item[10001] could all point to the same data structure.

[Rhodan]

But does a row actually exist if it hasn't been created? I don't think so.

So in my example above, any query would only return two rows since that is all that was created.

I would think (being only an amateur programmer with little knowledge of EQEmu's inner workings) that memory would be allocated based on the number of rows returned and not the highest index number. Problem is, thats just what I would think which isn't necessarily based in reality