this is perfectly reasonable to do, if you wanna code it up. The biggest reason it hasnt been done is that nobody wants to populate the database table.
I see these fields in the table:
classID
skillID
formula (integer which you switch on for various calculation formulas)
min_level (the level at which this cap starts to apply)
cap (the cap at this level)
some formula types, which apply until the formula's result exceeds the cap:
0. untrainable
1. untrained (at this level it cannot be trained, but will be avaliable later)
2. just use cap
3. (level * 5) + 5
4. ((level - min_level) * 5) + 5
... I believe theres some others in there ...
I dont see the point of your index field really, just store them sorted by level, and run throught the list until the level of the next entry is higher than your current level, or the list ends.
Actually, you could pull these from the database and apply them as you load them to calculate the level cap at each level and then just store that in a big array in shared memory:
uint8 skill_caps[MAX_CLASS][MAX_SKILL][LEVEL_CAP]...
for level 70, thats 78kb of data... which is nothing in shared memory...
dont really use a 3d array though, use:
uint8 skill_caps[MAX_CLASS * MAX_SKILL * LEVEL_CAP]
and index it with:
getskillcap(class, skill, level) \
skill_caps[class * (MAX_SKILL + LEVEL_CAP) + skill * LEVEL_CAP + level)
This is a very shared-memory friendly system, and is what I recommend.
I dont know if it would be worth your time to put all the race-based caps into the database, its prolly easier to just make a quick switch statement for them, and intelligently combine the results with the results of the class stuff.
However you do it, these caps should all be loaded into memory at zone start time, if not shared memory.
There would need to be at least 1200 entries in this table for each class/skill combination, maybe reducable by making the default 'untrainable', but there will be a lot of extra entries for 50+ and 60+ levels, so it'll end up being a few thousand... not that it matters.
|