No probs - I'm a few days away from releasing the next version of this. I've done a pretty detailed review of the Cavedude/PEQ databases to figure out in all the fields where I can safely renumber key fields. The next version or two is going to include:

- Automatic key re-numbering
- The ability to do batches of people at a time (maybe something like zones, maybe everyone)
- Generating the scripts that will reverse the adds. For example, if something doesn't work, remove what you just added in.

Most excellent work, Zephyr. I think the renumbering project was going to be enormous, and I know how to do it, just not sure what the accepted standard really is (besides simply zoneid * 1000 heh). Since loots and merchant sets could belong to NPCs in multiple zones, it mades my brains ache.

I can't wait to try this out.

Loot id's and merchant id's should not change really the two databases both share the same structure for items and shared item numbers.

True, so perhaps the only things really needing a re-indexing is things that are specific to a zone? Like an NPC, or it's spawn* info (both of which I think are mostly ok), or grids?

Anything else?

Merchant ID's should be the more or less the same i'd think, however loot ID's will be completely different. Both DBs (from teh little i looked into it when merging them) did a serialized numbering that i believe overlaps since cavedude had fewer spawns and thus his 1000th loot id might be somewhere in omens of war, which PEQ did all the creatures puting their 1000th loot id somewhere in kunark or something (not litteral, just to give an idea) So if you truely want to merge these two and make it pretty, then you'll probably have to re-do the loot id's entirely for one or the other (I'd assume cavedude's) I don't readily see any other way to go about it...

One of the things I did as a precursor to starting to rewrite this program was to review each of the tables that we would need to touch to come up with what the existing ranges are for all of the key fields (there are sometimes more than just the ID field) to find a "safe" range.

There are several cases of where the databases are the same up to a point, but then they diverge. In cases where there is any discrepancy, I'm taking the safe route to come up with a range of id's (for all the key fields) that new records could be imported with. This will be true if you're going cavedude -> PEQ or PEQ -> cavedude. It looks like there is going to be at least one case where we're going to have to alter the database structure (by expanding a field) as the existing ranges are already using all the available space.

Part of what I'll publish when I get the program running is that analysis. That way if I missed something, I'll have lots of folks helping me troubleshoot it. =)

Tool is now written - we're beta testing it on Dark Tides right now. As long as things look good, I'll get the update out in the next couple of days.

It's gonna be a biggie. =)

Here's a precursor of what it does:

http://www.verycarr.com/apps/scripts...ldchanges.html

That looks very well thought out. I can't wait to give it a whirl.

One thing, what does "add 500,000" mean on Items? Does that mean your IDs will start with 500,000 and go up from there? I ask because I ran into a problem when I tried to make a custom item with am id > 100,000, and believe I tracked it to this:

Items.h in EmuShareMem
Of course, I am unfamiliar with this code, so I could be wrong. Will this effect you?

Yes, you're correct with what I'm adding to the item ID's. I haven't found a problem yet with range I'm using. Just to be sure, I've made a section that allows you to easily set what you want to increment each key field by.

I'm working on posting the code for the program now.