Settings would work if you make them static, ie the entire game you have the same payment strategy. At least I wouldn't expect many users to change the settings during the game.
Hm, I personally probably wouldn't use exactly the patch suggested here, but yes, in a single player game changing the pricing (or at least a scaling parameter influencing it) in-game sounds senseful to me --- just because the parameters chosen are no exact science, and you always are somewhere in the range between "I go bankrupt" and "I am overflooded with money" - and this is not necessarily related with the question wether you play good or bad (whatever this means).
For example, on a somewhat bigger map, you can have well-used long-distance trains, and loose money nevertheless, just because the pricing algorithm makes the people pay you hardly anything for this. But: Is a distance of one, two, six or twenty months "long-distance" in game-sense?
The answer is, you can't decide that question, just because there is no clear concept of distances related to real world in OpenTTD.
So: When I identify such a problem, changing the concept of "what is a long distance" by adjusting one single numeric parameter sounds much more senseful to me than throwing away a game that I built up in a lot of real-world-time.
(and this, IMHO, is a disadvantage of NewGrfs here --- because you can't change the NewGrfs in-game, whereas some scaling parameter conceptionally of course can be changed safely in-game)
NewGRF and script however have CPU time, and they can monitor what happens (to some extent). They can dynamically change the pricing based on what they observe. That's an entire new dimension of game play opening up. Obviously, this can be further extended in several directions.
Honestly, sometimes in OpenTTD I would be glad to be able to customize conceptionally much simpler things ("how many passengers are produced per month?") in an easy way.
NewGrfs and scripts are nice, but sometimes as I player I just want to be able to disagree with respect to some scaling decision of a NewGRF author; in a sense like "do what you do, but multiply / divide it with a factor X".
You are however correct in the fact that few users can program a script, which would mean the settings would not be available for many users. I am not sure how to deal with that problem, and open for suggestions.
IMHO the answer is that some basic scaling parameters should be managable by using settings --- just because this is the place, where everyone can tune things based on the personal taste with minimum work required. And because this is the place, where settings that only influence calculations in a non-permanent way conceptionally can be changed in single player games in-game, without having all the trouble that are involved with replacing NewGrfs in-game
For example, already the question how much cargo is produced can alter the feeling of a game completely. And for influencing that one, you don't need to introduce "a zillion of parameters", one or two already can do a lot.
Or - the motivation of this patch: Some time ago, I analyzed why my trains don't earn money once the networks is enlarged (you see, the opposite problem the thread starter had
), and I ended up at the topic of cargo aging.
Of course, the 8-bit-Integer-arithmetic used there just has its limitations (i.e., the counter cannot have values > 255), but once I modified that by some factor, the problem was gone, and I actually could serve longer distances on a 512x512 map with trains of 1915 of the SBB set.
(what I did was more or less influencing the amount of days that are equivalent to "255", if I remember correctly)
Of course, what I did probably doesn't translate into a patch 1:1, but my point is that a few (*not* a zillion) well-chosen parameter settings in that regions of the game could give you a lot of influence on how the game feels.
(actually, collecting some changes like that into a patch is something I have in mind, but (real live...) not in the near future...)