You might want to check out nine digit numbers - I had problems to where my EQEMU wouldn't load the database when they were nine digit.

How about generating the IDs with an fixed offset instead of an multiplier?
EDIT: On second though I dont think its that easy, you might have to discard the old IDs alltogether and give new IDs, counting upwards from the offset.

Be aware that I did not read through the whole documentation yet, so the below could be moot:
Maybe it would be nice to have some conventions what ID ranges to use for certain stuff. Eg. Half the usable range for PEQ itself. A well sized chunk for imports from Cavedudes and other databases(are there any?). And the rest for local server customizations.
I recon it would help server admins to make sure that their custom additions dont clash with further updates of the PEQ databases.

Where do I put the files I downloaded from the one post? And how do I get it to source in properly?

If I were you, I'd wait tell Zengez replies to my "nine digit" comment - You're database may not load after you do this.

I'll be testing it as is tonight because this is very exciting! but of course I have my current database saved off incase I need to roll back.

Yea, i had that problem originally because the database only supports some of the upper end ranges because of the size limitation of the field, but it won't tell you you've reached the max until you've already hit it, then try to go higher a second time...

basically if you multiply by 1000, then do so again, half yer id's turn out to be the same number which won't let anything load, but it won't error until you try to multiply/divide it 'again' once they are all the same number... which is frustrating...

Anyway i ran into this problem by accident, figured out what the problem was, then resolved it... so (in my case anyway) everything loads just fine and i didn't break anything... I can't imagine anyone else having this problem if i didn't because i haven't actually customized my server very much... but I make no promisses as i don't know other people's code... my recommendation; dump your database files before you source these in, then if it kills something do a kill on the table and resource in your dumped original version...


As to how to source it, i just did a straight copy/paste from the text files into the mysql prompt in order to put it in, but remember not to do any more than 20-25k lines of code at a time or you may crash the prompt (won't destroy your database or anything, just crashed the prompt)

This worked fine for me. No problems loading the database and all the zones previously empty have caveman's spawns in them.

Everyone has their own way of doing things, but starting out with the base of what the designers intended is always a good practice. Any work (or modifications to existing work) that I do will follow this basic format:

http://www.eqemulator.net/forums/sho...12&postcount=7

The only problem I really have with this is the merge confusion - which is not a problem to the PEQ folks, since that is not their focus - it's our, individual desire to have more content immediately that is driving this effort again. If you use REPLACE INTO, you run the risk of blowing up LOTS of PEQ data. If you use INSERT INTO, you'll bump into existing (unique) records and lose Cavedude's data. I see some tables with auto increment values, and others where there are none. The confusion for me lies in, say, Zone ID 202 having npc ID 202000, in spawn group <autoinc, so it could be anything> using loot table <auto, anything> with loot drops <auto, anything> etc... see where I'm going? Sure it cuts down redundancy to NOT tie npc loot, faction, or spawn id's to zone id's (* 1000) but at the same time, it becomes hell to manage.

As a learning exercise, this is where I am focusing my attention right now... learning the intertwinings of the database and seeing if I can make things make more sense to me. I doubt my effort will become an acepted norm, but at least I will understand what's going on when I am through.