[Feedback] Partially non-logarithmic training

[vadracas]

 I've always wanted to play something in this game where the stat caps are crazy high and your soldiers slowly become more and more skilled and powerful without ever truly maxing out.

Currently, this is impossible due to the formula that secondary stats are improved which is based on how much farther you have to go before hitting the cap.

What I'm thinking of doing is adding an option to change the point where a soldier's secondary stats grow logarithmically/exponentially(I don't know, I didn't graph it) to one of a few options.

If this was implemented, none of the values would be required in the .rul files, instead, if it didn't detect those variables then they would be set to the appropriate values for the game to act like normal.

1) To the training stat caps and after that it grows at a fixed(still partially randomized) rate, specified in the unit's .rul file by an integer named postTrainingGrowthRate or something. This integer would be required to be set to -1 if the unit has a defined training stat cap for the code to realize it isn't supposed to only grow up to training caps, and it should instead grow all of the way. If training caps aren't defined then all of this is irrelevant as it would never trigger.


2) A new stat set called something like logarithmicGrowthCaps which only has secondary stats as it's inputs. Then the same is done with this as option one except the growth and training can be separated and there's another set of values to put in the .rul file. This method would also require the growth rate integer mentioned above.


3) I'm open to suggestions for other ways to implement this.


Is this interesting to anyone as something they would want? Do I need to clarify anything in the above post? Just say so please.

[Bobit]

Use commendations and set all stat caps to 0.

They are bonuses treated like armor, so starting stats remain relevant. Getting starting melee 50->70 is just hard as getting starting melee 70->90, but the next 20 points can be much harder.

 They can scale logarithmically. They can make starting stats remain meaningful as the game progresses. They give you complete control  over how EXP is gained. They are far clearer to the player. They are cooler. They challenge the player to soar to 5 kills in one turn instead of boring them with skipping 20 turns on reaction. If properly designed they can't be gamed, and in fact are made better when players try to game them. I don't know why everyone is treating them as just cute flavor. Them seem like a fantastic mechanic.

[vadracas]

I was talking about a coding addition so that secondary stats with high caps don't spike by crazy amounts.

[Bobit]

Okay, just trying to give suggestions for a similar effect. Sorry if I waste thread space, I'm not very useful. You could also try using returnFromMissionUnit script  hook to override vanilla experience formulas with custom formulas e.g. https://openxcom.org/forum/index.php/topic,6619.msg104686.html#msg104686

[vadracas]

Don't apologize, I seem to be the one wasting thread space right now based on how no one actually has anything to say about my proposal...

If an idea of mine can be done with scripts, great. However, I am much more comfortable with pure c++ than I am with scripts.

[Bobit]

You can easily fork the relevant cpp code so long as you figure out how to search in files (e.g. in: on github and findstr on windows cmd) and compile OXCE. But this is very unlikely to be a directly supported feature, because the OXCE leads are wary of bloating the codebase and aren't so fond of balance tweaks. And really, I wouldn't recommend forking either, because it largely breaks compatibility with every future update and mod.

[vadracas]

omg, this was so misunderstood!

1. I wasn't asking if I could do this

2. I was asking for modders input if they wanted this/if it would be accepted into OXCE if I did it.

3. I was asking if the methods outlined in my post were desirable o if anyone had other methods of implementation within the codebase.


I really don't understand how these things weren't made clear by my first post and it's making me rethink how some things need to be laid out.

Is this interesting to anyone as something they would want? Do I need to clarify anything in the above post? Just say so please.

HOW IS THIS NOT CLEAR!?


I outlined my possible methods and asked if anyone was interested or if anyone didn't understand

[Bobit]

I don't want to get in your way if that's what you really want to do, but it's extremely rare for optional features not coded by Meridian/Yankes to make it into mainline OXCE. So if your goal is to get this implemented for your mod, you really should do it with commendations/scripts/forks. Maybe that's not the "purpose of the thread" but if it accomplishes your goal what does it matter? There's a little bit of "being misunderstood" but mostly it's that I think your solution won't work.

[Meridian]

...but it's extremely rare for optional features not coded by Meridian/Yankes to make it into mainline OXCE.

Last version:
- 5 new features by Finnik
- 5 new features by memmaker
- 1 new feature by fbacall

Version before that:
- 2 new features by Finnik
- 8 new features by memmaker... I basically spent 70% of the time just reviewing these PRs

etc.

Doesn't look so extremely rare to me

[Bobit]

That is a lot...heh...