Just an FYI; Going forward, we are not putting names into the actual source code comments anymore. We have even been going through and removing some that are already in there. The names will go into the changelog like normal, and that is the best place to keep track of who did what. Just making note of that for future submissions.
Here is the code from the #spawn command that autocalculates MaxHPs:
Code:
//Calc MaxHP if client neglected to enter it...
if (!sep.IsNumber(4)) {
//Stolen from Client::GetMaxHP...
int8 multiplier = 0;
int tmplevel = atoi(sep.arg[2]);
switch(atoi(sep.arg[5]))
{
case WARRIOR:
if (tmplevel < 20)
multiplier = 22;
else if (tmplevel < 30)
multiplier = 23;
else if (tmplevel < 40)
multiplier = 25;
else if (tmplevel < 53)
multiplier = 27;
else if (tmplevel < 57)
multiplier = 28;
else
multiplier = 30;
break;
case DRUID:
case CLERIC:
case SHAMAN:
multiplier = 15;
break;
case PALADIN:
case SHADOWKNIGHT:
if (tmplevel < 35)
multiplier = 21;
else if (tmplevel < 45)
multiplier = 22;
else if (tmplevel < 51)
multiplier = 23;
else if (tmplevel < 56)
multiplier = 24;
else if (tmplevel < 60)
multiplier = 25;
else
multiplier = 26;
break;
case MONK:
case BARD:
case ROGUE:
// case BEASTLORD:
if (tmplevel < 51)
multiplier = 18;
else if (tmplevel < 58)
multiplier = 19;
else
multiplier = 20;
break;
case RANGER:
if (tmplevel < 58)
multiplier = 20;
else
multiplier = 21;
break;
case MAGICIAN:
case WIZARD:
case NECROMANCER:
case ENCHANTER:
multiplier = 12;
break;
default:
if (tmplevel < 35)
multiplier = 21;
else if (tmplevel < 45)
multiplier = 22;
else if (tmplevel < 51)
multiplier = 23;
else if (tmplevel < 56)
multiplier = 24;
else if (tmplevel < 60)
multiplier = 25;
else
multiplier = 26;
break;
}
sprintf(sep.arg[4],"%i",5+multiplier*atoi(sep.arg[2])+multiplier*atoi(sep.arg[2])*75/300);
}
Though, that probably isn't very useful for this feature unless mobs all used this same formula and they don't.
We could always just scale HPs (and possibly other stats) based on the mob's actual level vs the level set in the database. So, if the level is set to 10, and max level is set to 12, that would mean mob stats/hps could scale up 20% from what they are set to in the DB. So, a level 11 NPC would scales it's hps by 1.1, which would mean a 100HP level 10 NPC would have 110HPs at level 11. and 120HPs at level 12. This scaling would probably work well in most cases. The formula for that should be pretty easy. Something like this should work:
Code:
maxhp += (maxhp * ((moblevel / level) - 1));
Where moblevel is the level of the NPC after it has been spawned and set to one of the levels in it's range, and level is the base level set in the database.
If we wanted to be more flexible, though, we could add another field for scaling rates. The default for the scaling field would be 100. So, if we wanted a particular NPC's stats to scale at a faster rate as levels increase, we could set the scale rate to 200 (double scaling rate), or if we wanted it's stats to scale slower as levels increase, we could set it to 50 (half scaling rate). The formula for that would be something like this:
Code:
maxhp += (maxhp * (((moblevel / level) - 1) * (scale_rate / 100)));
This should allow for decent automatic scaling with lots of flexibility so it can be adjusted on a per-NPC basis. Of course, all other stats such as resists, normal stats and such could also be factored into this scaling system. Here is an example:
Code:
STR += (STR * (((moblevel / level) - 1) * (scale_rate / 100)));
Just something to consider. The main difference from what Secrets has posted and this is that there wouldn't be a need for a maxhp field, and instead there would be a scaling_rate field. I really like the idea of the whole random level NPC thing, no matter how it gets put in. We might as well work out all of the details now before it is committed so the system doesn't need to be adjusted afterward. It can be a pain to make adjustments after people have already started using a new system like this. Any thoughts?