Settings-menu for changes on the fly.

[Leartin]

We all know: It's possible to call the settings menu. If a pakset does not provide a button, most of us are able to write up their own menuconf and access it anyway.

However, whenever someone asks on the forums, we would tell them the following: Sure, there is a menu, you can use that, but you should make a backup of your savestate, and there is no guarantee that it works.

Can't we do better than that? Stating which of the settings are save and which aren't, and for those that aren't have a disclaimer (please save, might not work)? Or even make it so that they only take effect upon confirmation, at which point a backup save with the old settings is created and one with new settings reloaded? Otherwise, having the player to tick a checkbox in the style of "I know what I'm doing" before the settings are available might work as well.

Personally, I think the first step - no matter the implementation - would be to analyse which settings are save (eg. display stuff - I don't think the compass position could cause trouble?), which require a reload (I guess routing, jit?) and which shouldn't be touched at all. (bits_per_month, station coverage, seperate halt capacity - might not break the game per se, but are too likely to break a map).
After all, even if nothing is implemented in the game, having a list of which you can change and which you can't (or shouldn't) would still be beneficial to link whenever the settings menu comes up.

[Mariculous]

changing bits_per_month is not such a big deal.
The only thing that breaks in extended are schedules, which standard does not have at all.
For sure, increasing bits_per_month by 1 will double profit but a month will simply represent twice the amount of time, in per second meaurement, nothing changes.
Thus, it's really just a factor of how fast the timeline passes by.
increasing bits_per_month by two around the 90s didn't break any of my 3 maps so far.

[Matthew]

We all know: It's possible to call the settings menu. If a pakset does not provide a button, most of us are able to write up their own menuconf and access it anyway.

However, whenever someone asks on the forums, we would tell them the following: Sure, there is a menu, you can use that, but you should make a backup of your savestate, and there is no guarantee that it works.

Can't we do better than that? Stating which of the settings are save and which aren't, and for those that aren't have a disclaimer (please save, might not work)? Or even make it so that they only take effect upon confirmation, at which point a backup save with the old settings is created and one with new settings reloaded? Otherwise, having the player to tick a checkbox in the style of "I know what I'm doing" before the settings are available might work as well.

Personally, I think the first step - no matter the implementation - would be to analyse which settings are save (eg. display stuff - I don't think the compass position could cause trouble?), which require a reload (I guess routing, jit?) and which shouldn't be touched at all. (bits_per_month, station coverage, seperate halt capacity - might not break the game per se, but are too likely to break a map).
After all, even if nothing is implemented in the game, having a list of which you can change and which you can't (or shouldn't) would still be beneficial to link whenever the settings menu comes up.

Doesn't Simutrans already have this in principle? Display stuff is supposed to go in the Display Settings window and deep, hidden secret stuff goes in the Settings window. It's just that newer features have been added to the Settings window instead, perhaps because redesigning the Display Settings window is a distraction when out lovely coders are trying to fix/add more important things (I think the jargon is 'technical debt').

changing bits_per_month is not such a big deal.
The only thing that breaks in extended are schedules, which standard does not have at all.
For sure, increasing bits_per_month by 1 will double profit but a month will simply represent twice the amount of time, in per second meaurement, nothing changes.
Thus, it's really just a factor of how fast the timeline passes by.
increasing bits_per_month by two around the 90s didn't break any of my 3 maps so far.

Breaking schedules is a very big deal in Extended and my non-coder's impression is that bits_per_month is a very fundamental value that affects a large amount of the codebase. So maybe the coders would do their successors a favour if bits_per_month were kept untouchable in both versions of the code, to make it easier to port features between them. But those of you who actually write code obviously know better than me whether that makes sense.

[Mariculous]

Breaking schedules is a very big deal in Extended

Sure it is. The point is that standard does not have schedules!

[Leartin]

Doesn't Simutrans already have this in principle? Display stuff is supposed to go in the Display Settings window and deep, hidden secret stuff goes in the Settings window. It's just that newer features have been added to the Settings window instead, perhaps because redesigning the Display Settings window is a distraction when out lovely coders are trying to fix/add more important things (I think the jargon is 'technical debt').

I guess that makes sense, since the display settings were only changed to a much more flexible layout with tabs recently. So we are now at a point where these things could be moved rather easily - I'll look into that since that might be literal copypaste.

However, there are other settings that wouldn't harm an ongoing game - essentially everything that is only checked at a specific point in time. For example, allow_underground_transformers would only come into play once a player tries to build a transformer underground. In that very moment, the game would check whether it's allowed. Turning it off wouldn't make existing underground transformers disappear either. I think the maximum convoi length only checks while you are composing a convoi in the depot, but shortening it would not cause existing longer trains to collapse.

For the rest, I'm not sure they should be hidden. Even if they could cause issues, I'd prefer them to be readily available, but with a warning label. Or the other way around, even if they are hidden, I think they should have a warning label for those who find it.

changing bits_per_month is not such a big deal.

That's the thing though: I don't really know what is a big deal. Neither would a common player. I guess what changing bits per month would do is messing up statistics, since longer months would naturally have higher values of everything. Even if you can certainly play with it, it's 'a bigger deal' then any change that would not have that problem. Eg. if you change jit-settings, if your network was already balanced, it should not change anything at all.

Note that in any case, I'm all for allowing players to change every setting. The goal is not to have a 'hidden' or 'forbidden' setting, but a visible setting with enough information for a player to make an informed decision. Even if bits_per_month was classified as something the player should not change, it would not be worse than the current situation where it's also classified as something the player should not change (hidden in a secret setting), but so is the compass position...

[prissi]

The setting window is not officially available, since most of these options do not work without a reload. This is due to the fact that many settings (all gamestate relevant ones) are saved with the game. Otherwise there could be no network gaming.

So there is no easy way out apart from changing and saving, reloading, and see how many things are partly broken afterwards (like the recent discussion of changing just_in_time showed. bits_per_month is almost as severe.) This this is why it is hidden in pak64 and not officially supported.

One may discuss of course, if one or the other option should not be easier accessible by the "display" settings (which is rather the "common" settings by now). But this must be, by definition, a non gamestate altering one.