I think this issue may be considered as a small part of #73 , but I thought it would be better to make it as a separate issue so we can tackle this issue isolated from the rest.

I am up for working on this. I just want to grab some feedback on the approach before I go ahead.

Is your feature request related to a problem? Please describe.
Today we have this huge battle_calc_skillratio function with 2 levels on switches for pretty much every skill in the game. Currently it takes around 1500 lines with formulas for each skill and some fall throughs.

To add to the complexity, it has a mix of sometimes adding to the received paramter "skillratio" and other times replacing the value. And well, skillratio is always 100 when this function gets called.

In my opinion, this huge function block with formulas + the skillratio parameter makes things quite confusing. For example, there we many times when changing a skill where I had to wonder whether 100% was forgotten in the formula, or whether I have to reduce 100% when comparing to the description, etc.

Describe the solution you'd like
My proposal is to rework this part so:

1. "constant" values are moved to skill_db.conf;
2. Values that still needs to be calculated are moved to separate functions;
3. We don't have to think about this incoming skillratio = 100 parameter

This would remove those hardcoded values and should make tweaking basic skill settings easier and pluggable. In the other hand, skill_db.conf will grow a few thousand lines.

A very high-level draft of what it would look like may be found here: guilherme-gm@265fe57

Scrolling through this function, I can see a few things that jumps to the eyes:

1. Cases where we have simple, "constant", formulas (e.g. skillratio = skill_lv * 10 + 30;)
2. Cases where we have simple, "constant", formulas with a small condition (e.g. extra boost from a SC)
3. Cases where we have simple, "constant", formulas with extra RE level boost (i.e. simply call RE_LVL_DMOD after the formula)
4. Cases with 1 condition and 2 simple "constant" formulas (e.g. Bows causing half damage vs other weapon)
5. Cases with several conditions, logic, damage differences, etc
6. There are only 3 skills today that uses both Magical and Weapon formulas (the external switch), but as far as I can tell, we can easily work around them using SkillData fields. Those are the skills:
   • LG_SHIELDSPELL (Lv1 is WEAPON, Lv2 is Magical)
   • LG_RAYOFGENESIS (Does both magic and physical damage at the same time)
   • SO_VARETYR_SPEAR (Does both magic and physical damage at the same time)

My initial proposal is the following additions to skill_db.conf:

	SkillInfo: {
		// This will tell us that we need to perform a custom coded formula
		// While we could simply do a lookup whether we have a function, I think having
		// a field here makes clearer to people reading the DB.
		// like "Oh, ok, there is a ratio here, but I should expect more things on code"
		// Also allows us to detect missing formula functions during startup.
		CustomSkillRatio: true/false (boolean, defaults to false)
	}
	SkillRatio: {
		BaseLevelModifier: 0 (RE-only? Applies the RE_LVL_DMOD value)
		Lv1: 100
		Lv2: 100
		...
	}

And inspired on gepard-me suggestion in #73, we would have a function that populates a db of SkillID -> SkillRatio function for the skills that needs a formula.

Going back to the cases I mentioned above, we would have:

1. For simple constant formulas -- Simply expand the formula into SkillRatio values
2. For extra boosts from SC -- Create a function for CustomSkillRatio and use SkillRatio + function (we could use SkillDataN fields to help too, or some sort of new field if we want to make it generic)
3. For RE boost -- Simply expand the formula into SkillRatio + set BaseLevelModifier
4. For cases like bow does less damage -- Create a custom function and use SkillRatio + SkillDataN
5. Cases where everything is crazy -- probably just hardcode the entire thing in a function

We may expect to get a good amount of new, small functions, but I think this is fine(?)

For people with customization
For people with many customizations, this should not have huge impact, they could migrate their changes by simply making a "get all" function with their current switch/cases and make their skills a "CustomRatio" skill. Some manual work, but not a huge effort, I think.

It would look like that:

int skill_my_custom_ratios(... all parameters here ...) {
  int skillratio = 100; // current code gives skillratio = 100
  // original code
  switch(skill_id) {
     case My_Custom_Skill1:
          // original code
  }
  // ...
  return skillratio;
}

in the db setup:

idb_put(skill_ratio_db, My_Custom_Skill1, skil_my_custom_ratio);
// repeat for each custom skill

and adding this to every customized skill:

SkillInfo: {
   CustomSkillRatio: true
}

Describe alternatives you've considered
I have also considered tweaking a bit SkillRatio from the example above so instead of Lv1..Lv10 you could specify a "step". Since many formulas are like "start at 100, add 10 for each skill level". So we would have something like:

	SkillInfo: {
		CustomSkillRatio: true/false (boolean, defaults to false)
	}
	SkillRatio: {
		BaseLevelModifier: 0 (RE-only? Applies the RE_LVL_DMOD value)
		BaseRatio: 100
		RatioPerLevel: 10
		...
	}

Additional context
I think there are other aspects of skills that could follow similar approach, but I think it is better to take it slow so we can actually do it.

As I mentioned in the start, I can work on this change, but I want to get some feedback on the idea before I start coding it.