This is more of a feature suggestion than request. Given how flexible uncapper already is, adapting it in a few ways would be absolutely brilliant. And if anything already is a feature, I guess that would fall down to documentation.
[LevelSkillExpMults\CharacterLevel\OneHanded]
# no config, will search next section(s) until one is found
[LevelSkillExpMults\CharacterLevel\TwoHanded]
# define a function for all intervals
funcn=linear-interp
1=10
10=1
[LevelSkillExpMults\CharacterLevel\Enchanting]
# define functions every interval
func1=linear-interp
func2=exponential
# define variables each function is documented having
f1x=3
1=0
40=1
85=4.44
Having some formulas to apply, per interval (potentially) would make a lot of what is done with it simpler through extended syntax. Some basic equations like:
- linear interpolation
- polynomial
- asymptotic
- etc.
Generalizing as needed, so long as it's documented (perhaps even graphed for documentation purposes).
An asymptotic implementation, in Java so not exactly Rust, could look like:
/** Function with asymptotic features.
*
* This method makes the following assumptions:
* 1) input value is in the range (0,1)
* 2) a return value in the range (0,1) is expected and desired
* */
public static double HorizontalAsymptote(double value, double power, boolean positive, boolean increasing){
if (value > 0) {
double q = 1 - power;
double r = q / (value + q);
r = RemapRange(r, 0, q / (1 + q), 0, 1);
if (positive && increasing) {
return 0 - r + 1;
} else if (positive) {
return r;
} else if (increasing) {
return -r;
} else {
return r - 1;
}
} else if (value > 1) {
return 1;
}
return 0;
}While extending config syntax, might as well apply some DRY by allowing sections to act like a switch. (ie. looking to the next line(s) for config values to use)
// A
switch(x){
case 0:
// empty code
break;
case -1:
case -2:
case -3:
// negative values code
break;
case 1:
case 2:
case 3:
// positive values code
break;
default:
// invalid value
break:
}Edit:
I've been doing a lot of modding of my skyrim lately, and another thought that occurred to me was that it would also be desirable to have global multipliers. This would also contribute to simplifying some setups, or making more nuanced ones.
A global multiplier for the different sections (i.e. [SkillExpGainMults] or [LevelSkillExpMults] granularity into *\BaseSkillLevel and *\CharacterLevel would be optional)
For example maybe the player is using the not a novice mod to start with skills, but doesn't want that to affect their level much. They could achieve that a few ways:
[LevelSkillExpMults/Global]
1 = 0.12
2 = 0.24
3 = 0.48
5 = 1.00
50 = 0.50
- if adding global multipliers to subsections
[LevelSkillExpMults/BaseSkillLevel/Global]
0 = 0.00
15 = 0.25
20 = 0.50
30 = 1.00
This sort of thing, could also curtail some of the need for DRY features. A benefit, I think, is that this should be backwards compatible. (non-functioning, but non-breaking as well)
This is more of a feature suggestion than request. Given how flexible uncapper already is, adapting it in a few ways would be absolutely brilliant. And if anything already is a feature, I guess that would fall down to documentation.
Having some formulas to apply, per interval (potentially) would make a lot of what is done with it simpler through extended syntax. Some basic equations like:
Generalizing as needed, so long as it's documented (perhaps even graphed for documentation purposes).
An asymptotic implementation, in Java so not exactly Rust, could look like:
While extending config syntax, might as well apply some DRY by allowing sections to act like a switch. (ie. looking to the next line(s) for config values to use)
Edit:
I've been doing a lot of modding of my skyrim lately, and another thought that occurred to me was that it would also be desirable to have global multipliers. This would also contribute to simplifying some setups, or making more nuanced ones.
A global multiplier for the different sections (i.e.
[SkillExpGainMults]or[LevelSkillExpMults]granularity into*\BaseSkillLeveland*\CharacterLevelwould be optional)For example maybe the player is using the not a novice mod to start with skills, but doesn't want that to affect their level much. They could achieve that a few ways:
This sort of thing, could also curtail some of the need for DRY features. A benefit, I think, is that this should be backwards compatible. (non-functioning, but non-breaking as well)