npc_types table incomplete?

[quester]

How come the npctypes table has no stats? ac? Seems to be a LOT of information missing.

[Xarslik]

Not really missing, just not implemented yet. As far as I remember all NPC stats (Str, Sta etc) are 75 by default.

You could probably add support for the stat variables in npc_types.

[quester]

Yes.. I would like to add the support. I've already added npc procs to the database and the emu code.

If no one has any objections, I will add stats and ac to the database as well.

[Zerak]

Great idea. Would increase MySQL size by a rather noticeable amount, but great idea.

[Lurker_005]

A quick way to improve things would be make the stats different for different race class combos, also have it raise some stats based on levels. You could even throw some randomness in there. That would go a long ways to getting the npc's closer to wher they should be. Then perhaps have a table of profiles that could overwrite (or modify might be better) the calculated values. That way you need a lot fewer sets of stats 200-800 instead of 20000 stored in the DB.

just my 2cp

[quester]

Not a bad idea at all. Here is what I would recommened:

Seperate the stats off into a PROFILE. Build default profies for main types "Ghoul", "mummy", "Giant", etc..

In the npc_types database, add a colum,n that specifies what profile the entry uses.

Then, to customize things, you could just make custom profiles and link those in as needed.

If this sounds good, let me know, and i'll implement it tonight. I really want to get something like this working because i'd much prefer pets to be pulled form the database rather than hard coded.

[DeletedUser]

isnt that how eqlive works?

All races have a set stat then it raises by level/class/items/buffs/etc.

[quester]

Stop folliwng me! :p

Yes and no. The npc defintions include the stats. If eqlive was eqemu, then the stats would be in the npc_types table. Whenever a designer wants to make, sya a new type of ghoul, he typically will copy the entry for an existing ghoul, then modify it. Thats how they retain similiar stats.

But I like te idea of splitting them off into a seperate profile better. Then just adding a link to the profile used when you define the npc. Less data overhead that way.

[Trumpcard]

Also nice that it makes old code compatible with new databases since the stats live in an entirely new table..

[Lurker_005]

quester:
Yea, that was the basic idea. I suggested having base profiles calculated so that most mobs would not need any modification, then have the "profile" table for special mobs. Also if the profile table is a stats modification table then the calculated values can be tweeked without greatly upsetting the special mobs.


Taking it a bit further, if all the modifications (class/race/special mobs) are formula values, then there will be even fewer profiles needed.

So wild numbers pulled from no where...

Std mob profile:
war:
5% str from the base numbers
4% sta
10% HP
-5% int
ect

halfling:
-4% str
3% agi
ect

ogre:
10% str
-15% int
ect

level:
3% * level different values for different stats



Profile adjustment:
high resist profile:
10% * level to all resists


High HP profile:
12% HP * level

ect...


So in npc_types you would specify a profile mod (or leave 0 for the default) HP would be removed, and changed to a calculation. HP, mana regen, and perhaps the walk/run speed should probably be moved to the profile as well. And I would prefer that level was moved to the spawn entry table, even beter if it was changed to a level range.


Think that about wraps up my view on things. What do you think?

[quester]

I think it sounds good. Some stuff, as you pointed out, that is currently in npc_types should be moved over to the profiles.

I'll do what I can to make the code work with the different database configurations, since npc_types will undergo some large scale changes.

I also want to be able to make the profiles as flexible as possible, so you can do things like randoms, percentages, fixed values, etc. I'll do some thinking on that. Probably the best way would be to do it with varchar fields, and then have ways of entering values, such as:

%+10 (Increase value by 10%)
%-10 (Decrease value by 10%)
10 (Make value 10)
+10 (Increase value by 10)
-10 (Decrease value by 10)
r10-20 (Set value to a random value between 10 and 20)
r+10-20 (Increase value random between 10 and 20)
r-10-20 (Decrease value random between 10 and 20)

Maybe add in a variable, as well for levels:

l* (Level times)
l% (Level divided by)
l- (Level minus)
l+ (Level plus)

This could be used anywhere a value is indicated, for example:
[code]
%+l*10
[code]

Would mean, "Increase value by (level * 10) Percent.

Thoughts?

[quester]

Well.. haven't seen any comments against this, so that is what i'm going to do this weekend unless someone comes up and says no

[TheClaus]

quester,

I just wanted to say that you are doing some cool things and wish the devs would speak up about this. Unfortunately they tend to not answer too much in fear of being sucked into the void. Don't think your code is going unnoticed. IMO you are bringing some life back into the project. You might want to show up on IRC this weekend if your working on this. Most of the devs are around. Keep up the good work and don't leave like some people did (Malv, RIP buddy).

[Trumpcard]

No doubt Quester, awesome work.. You should consider coming onto irc and joining the dev team.

[devn00b]

you know the devs might care more if they saw some ACTUAL code from him..

i have yet to see antything original from him...and the one 'fix' increased the memory footprint of zones by 60%.

which is a step in the WRONG direction.

show some code then maybe somone will care.