tome / Tales of MajEyal · Commits

Rewrite functions for scaling with diminishing returns approaching a limit

**Why change anything**: current limit scaling functions have an issue where they are very frontloaded and give scaling curves where the vast majority of scaling is done within the first few talent levels. The combatTalentLimit (cTL) function is particularly egregious for this, and it is to the point that @Shibari, @razakai and myself all do not use it and rather use math.min or math.max(combatTalentScale) for better scaling curves. This tends to be an issue most often when the limit is close to the value desired at talent level 5, which is a common use case for cTL of talent cooldowns, talent range, debuff duration, etc.  


**Happy happy math fun time**: the formula I wrote for cTL uses a general calculation of limit*(1-exp[a*√(x)+b]) as opposed to the current formula using a general calculation of limit*(x + a)/(x + b), where for both functions a, b are determined based on the parameters giving for scaling. Both of these are sigmoid functions, i.e. are bounded by a limit and will monotonically either increase or decrease as desired at a slowing rate. The primary desired aspect of the replacement function I suggest is that it will exhibit less drastic increases within the first few talent levels and show more growth from moderate talent levels.   
Similar exponential decay functions are proposed to replace combatStatLimit and combatLimit for consistency; however, these functions do not have as much issue as cTL. As such, I used x^0.75 rather than √x which will provide more similar results to existing combatLimit and combatStatLimit.

See merge request !636

1.7 Tree based rare+ gen

Changes how rare+ enemies are generated to be based off trees instead of scattered talents. This serves two main purposes:  
1. Fix an issue where the third and fourth talents in trees are extremely rarely taken (by rough simulations by Shibari, about 3% of the time for 3rd and 2% for 4th in High Peak).  
2. Make randbosses feel slightly more coherent and easier to evaluate at a glance.  

The tree system works by assigning major and minor trees, with major trees seeing randbosses taking 3 to 4 talents and minor  trees only 1 to 2 with reduced point investment. Biasing based on whether a tree starts locked or unlocked for a class and by whether a tree is generic or class is currently not implemented, but could be desirable. (Previous randboss generation did not bias by these factors either.)  

Current tuning for balance is based around randboss level and is as follows:  
* Rares:  
  * Major trees: first between 8-10, second between 25-35, third between 50-70  
  * Minor trees: two by base, third around 12-30, fourth around 40-80  
* Unique randboss:  
  * Major trees:  one by base, second around 20-40, third around 50-90  
  * Minor trees:  one by base, second around 11-14, third around 30-60, fourth rarely around 70-90  
* Boss randboss:  
  * Major trees:  one by base, second around 11-23, third around 35-75, fourth rarely around 80-90  
  * Minor trees:  one by base, second around 12-20, third around 40-80  

Note that the amount of trees of each type is slightly randomized, thus why level ranges are provided. Lines 2171-2181 contain the exact functions for numbers of each type of tree at each level if specifics are desired.

See merge request !634

Talent tuning

Tuning of various talents that are excessively powerful on NPCs.  
This accompanies !634, which causes tier 3 and 4 talents to show on NPCs with regularity. 

See merge request !635

otowakotori 1.7 misc fixes



See merge request !630

i18n Misc updates

misc refactor and updates on `i18n_helper.lua` to suit working on multiple locale on a same repository

See merge request !628

This may still be a bit too strong on NPCs

This should arguably be outright banned instead