Possible new aproach to world building

[Sprig]

I'm not sure how possible this would be....

I think it would be a good idea to attempt to come up with a standard for IDs based on the zone numbers for the id numbers used in the database for things like doors mobs etc,

If blocks of ID numbers were reserved for certain areas anyone who used the standards would have a much easier time changing out individual zones for newer versions.

with this modular method it would be possible to choose between versions of zones that people make public without worrying about picking through ID numbers to make sure you weren't messing things you had worked on up.

I understand that this would require a ton of work as far as rewrites go
but i would be willing to assist in whatever way i could if anyone wants to work on it with me. ( my knowledge of mysql is somewhat limited though)

-sprig

[John Adams]

Before someone comes and says something mean, I will attempt to take the high moral ground and say, much of the data already is in that structure (zoneid * 1000), for say NPCs and such. To re-ID the entire database would be monumental. Many have talked about it, said they'd get back to us with some results, and vanished from cyberspace.

Even I myself (a self-proclaimed SQL GOD - until I saw some of GeorgeS's hints ;)) tried to review what it would take to re-ID everything. It's just too scarey, and dangerous. So many things could break. Blah blah.

Best thing IMO is to leave it in the hands of PEQ - those uber data monkeys. If they want the core database "fixed", they'll ask. :)

[ChaosSlayer]

hehe yeah there is prabobly MILLIONS lines of data in DB (class skills table is 40,000 lines alone), but since I am rebuilding everquest from the scratch right now, I am only doing 1 zone at a time, so i have the luxury to set up a standart and follow =)

[Sprig]

Let people say mean things... i'm posting on the the web so manners are not the norm =)

my prior post was more of a wish list than anything i hoped would really happen.
I am not completely giving up on the idea but not expecting it to happen either. =)
-sprig

[John Adams]

I should have asked initially, but where do you see a deficiency with the current indexing? I mean, the PKs shouldn't matter as much as the FKs - or what IDs tie the whole thing together. The database does show it's age, with no constraints and dead data (that many have offered to clean up).

The npc_types table is laid out exactly as you described, with Zone 1 mobs being numbered 1000-1999, zone 2 being 2000-2999, etc. You can't really bind many of the other tables to "zones" unless the range is increased (I guess), because there could be more spawn groups, spawns, loot drops etc.

I doubt SQL cares what your PK is, but I believe our shared memory modules do. If you read in IDs 1-100,000, it takes up 'x' amount of memory. If you start making up new IDs and now have to read in ID 1-1,000,000, that's a helluva lot more memory (if we pad that empty space, which I think we do from an earlier discussion).

Anyway, always a good idea to have a solid database. I guess I forgive 'eq' because it is so old, before MySQL became a real database solution ;)

[EmanonCow]

How practical would splitting the IDs be?

Ie, items being identified by a (zone, ID) pair, with (0, ID) being "uncatagorized"?

This would require changes to the code base (so it identifies things as (zone, ID) pairs rather than just IDs), but the existing data wouldn't have to be changed.

Then one could start moving things out of the "uncatagorized" zone and into a (zone, ID) pair space -- it would allow one to create portable zone-data files, but not require you to, so existing data would work fine.

[Dralanna]

items being identified by a (zone, ID) pair, with (0, ID) being "uncatagorized"?

The problem is many items appear in multiple zones.

[ArChron]

I doubt SQL cares what your PK is, but I believe our shared memory modules do. If you read in IDs 1-100,000, it takes up 'x' amount of memory. If you start making up new IDs and now have to read in ID 1-1,000,000, that's a helluva lot more memory (if we pad that empty space, which I think we do from an earlier discussion).


I believe that the IDs are read and stored in a 1 to <maxid> space... there are other programming models for handling what could be a "sparse matrix/list" if the range of values for IDs were spread out to accomodate a new identification scheme. I think that (EMU code change) is far less of an issue than just managing the data transformations that would have to happen in the SQL database...