Very Nice....Reloaded Server with it, seems to work nice, keep up the good work! :wink:

Awesome Job!

A few changes I made to make it more enjoyable for me:
01 - Stop those pesky insta-respawns:
UPDATE spawn2 SET respawntime=1000 WHERE respawntime=0;

02 - Create a new loottable (301 here) for NPCs with no drops at all (loottable_id=0):
UPDATE npc_types SET loottable_id=301 WHERE loottable_id=0;

03 - I created a small table of funky items (loottable_id=300) for all mobs lvl 1-10 for fun... it's kind of neat and made the low levels fun

04 - Some proposed maxdmg catch-alls (mainly to rid the 400[dmg] hitting noobie mobs):
http://www.everquestserver.com/forum...?p=63156#63156

I'll post back if I have any more ideas :)

*EDIT* - And for the curious people who might not know how to do it... here is how to make a new loottable and have it implemented:

a) INSERT INTO loottable (id, name, mincash, maxcash, avgcoin) VALUES ('yourID', 'yourNAME', 25, 350, 2);
--> replace 'yourID' with and unused loottable ID number and use whatever text for 'yourNAME' to describe the entry
b) INSERT INTO loottable_entries (loottable_id, lootdrop_id, multiplier, probability) VALUES ('yourID', 'yourID', '#drops', '%#drops');
--> use the same 'yourID' number for sanity's sake; '#drops' is the max number of slots drops will occupy if '%drops' is @ '100'
c) INSERT INTO lootdrop (id, name) VALUES ('yourID', 'yourNAME2');
--> same 'yourID' number & don't use spaces in the 'yourNAME2' field (well, no one else did anyway... not sure if it's required)
d) INSERT INTO lootdrop_entries (lootdrop_id, item_id, item_charges, equip_item, chance) VALUES ('yourID', 'itemID', 1, 1, '%chance');
--> use same 'yourID' for ALL entries of individual items so they stay in your new table; 'itemID' is the "#summonitem" itemID number of the item you want to insert; just keep '%chance' the same with all for equal drop rates of all items in the table
e) UPDATE npc_types SET lootable_id='yourID' WHERE 'condition';
--> 'yourID' is your new loottable ID and 'condition' is the condition upon which you wish to apply the new table (i.e. - loottable_id=0)

Hope that helps :p

05 - Some level 24 mobs have WAY too many hps (i.e. - stonegrabbers in MSeru)
UPDATE npc_types SET hp=880 WHERE (level=24 AND hp>3000);

06 - Personal opinion, I guess, but skeletons seem to have an entirely too huge aggro range (e.g. - large chunks of kurns aggro at a time - even below/above current level)
UPDATE npc_types SET aggroradius=65 WHERE (name LIKE '%skeleton%' AND aggroradius=200);

Awesome recommendations... I wish everyone made them with sql statements! Thanks a lot for your time, I'll suggest these to get utilized.

I must agree with Kroeg that the inclusion of the SQL statements is a HUGE help with understanding how to get some things done.

/cheer

--
Veto

i have a problem donno if its in DB or not but since its mob related i am assuming it is but when u attack a mob its health does not decrease it stays at full heath untill it dies using npcstats shows its hp droping but the target window stays at 100pct then it just dies

Thanks for the DB, here are a few issues i have found.

Many of the class numbers for the NPC's are incorrect, many that are supposed to be GM's are set to merchants (41). There is no easy way to fix this other than referencing the class numbers from a db with correct data. I used this query to construct a query to perform the udates, where the EQ1 db is the current DB and the EQ db is an older version containing the correct class numbers:

SELECT CONCAT('UPDATE eq1.npc_types SET class = ', b.class, ' WHERE id = ', a.id, ';')
FROM eq1.npc_types a, eq.npc_types b
WHERE a.id = b.id
AND a.class <> b.class

(Here's the resultant query)

Is there a reason why the start_zones table is not indexed? There are many redundant (replicated) records in this table.

Some of the start_zones.race, class, zone and deity records have no corresponding starting_items. race, class, zone and deity records (e.g. Any Freeport Cleric):

select start_zones.zone_id
, zone.short_name
, start_zones.player_race
, start_zones.player_choice
, start_zones.player_class
, class_skill.name
, start_zones.player_deity
, starting_items.id, items.name
from start_zones, zone, class_skill
left join starting_items
on start_zones.zone_id = starting_items.zoneid
and start_zones.player_race = starting_items.race
and start_zones.player_class = starting_items.class
and start_zones.player_deity = starting_items.deityid
left join items
on starting_items.itemid = items.id
where start_zones.zone_id = zone.zoneidnumber
and start_zones.player_class = class_skill.class
order by start_zones.player_race
, class_skill.name
, zone.short_name

This seems to be because of problems with the start_zones table, rather than the start_items table (some of the start_zone zone id's are incorrect). e.g. This update will fix the evil Erudite Clerics:

update start_zones
set zone_id = 75, start_zone = 75, x = 880, y = 456, z = -120.19
where start_zones.player_race = 3
and start_zones.player_class = 2
and start_zones.player_deity = 203

(I have referenced the x,y and z values from the Shodownights as I don

Is there a relatively easy way of converting character data from 5.2 -> 5.3-DR2 format?

As you said.. i did loose all character data.. and if i tried to create a new character with the same name as the one i had (and prolly still is in the db someplace) i get a rejected name..

Any "hotfix" to this?

Molly, keep putting out all that usefull info!

Nice SQL queries, more advanced that I have tried to go for yet.

I've got a quick question about the database. It doesn't seem like anybody outside the dev team is interested in merchants. I've been looking through the database and noticed that some merchants are way off from what they should be, for example:

npc # 646 "a_clockwork_jeweller" in Ak'Anon is associated with fishing supplies
npc # 1344 "Felen_Razdal" in Butcherblock is associated with a random assortment of stuff, when he should be selling stuff like rations, lanterns, etc.

The code I used to come up with this is this:
So my quick question becomes three. First off, what can I do to help set the merchants straight?

Secondly, is the merchantlist.merchantid an arbitrary value, or is the exact value important somewhere?

Lastly, did I just totally botch the SQL statement above(which isn't exactly pretty), and am getting randomly wrong results?

I've already started writing a SQL file out to help fix the problems, but I didn't want to start working on it and have someone say that I wasted my time because the merchantid's were important and I couldn't just choose arbitrary ones. If anyone can help answer my questions I'd be greatly appreciative.

Also, if I posted this in the wrong place.. smack me with a clue-by-four, and let me know where it needs to go.

I wrote a conversion program for Scorpious2k Server :-) Interested?

I wasn't sure anyone but Conan at BrightBlade was looking for anything like this... maybe I should put a topic in 3rd PT...

Does anyone have a list of deityid's vs. names?

*edit* Scratch that, i worked it out.

hey anyone notice that some of the spells in spells_us.txt were shifted around in the last patch? because of this some of the spell scrolls are bugged, and so are some of the weapon effects (eg. skin like wood).

The sollution to this i would persume is to make a program that compares the old and new spells_us.txt

first the spell structure must be loaded, then just keep reading from both files n build link lists (lots of memory required =S) then compare id's. Any changes are put into a query for SQL

UPDATE items SET spellid = (new spellid) where spellid = (old spellid) ;

should solve the problem... would fix it myself but i hate C++ and mysql =)

Thank you

EQEmu was using the wrong format for spells_us.txt. This is fixed in 0.5.3-DR2 as of 1/2/03 and all spells should work as they should now.