New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Setting for a year that repeats forever #7938
Conversation
If this setting is a thing, it should probably also affect
|
it might be useful to check whether this is a repeat year, and ignore any of those effects in that case (so it would advance normally if you date-cheated to the next year) |
This comment has been minimized.
This comment has been minimized.
Just to make this clear, this PR in no way tries to simulate, facilitate, replace or in any other way achieve any kind of "daylength". in the current state, it just moves the already existing feature of looping a certain year over and over, which historically was in the year 2090, and currently the year 5.000.000 (MAX_YEAR), to an arbitrary year chosen by the user. PS: i don't think you're using the word "desync" correctly. |
Option 1/2 combined to the Transport Fever 2 model, where the economy is simulated on "real time" and there is a separate "technology date" that can advance at any speed. The economy time still has days, months, and years (for all the bookkeeping purposes) but they don't need to quite follow a special calendar, and economy events can be presented via real-world time units (seconds, minutes, hours) that approximate how long it takes when the game runs at full speed. I started a branch with that concept, calling it NoCalendar, but it's a lot of work and I've shelved it for now. The approach in this PR is fine too, it just needs to handle the case when the year is cheated past the loop year in an appropriate way. The MAX_YEAR value also needs to be observed no matter what, since its purpose is to avoid integer overflow. |
i thought of that, and changed the
that should be fine, the setting ought to be clamped to |
These PRs are such a double-edge sword. We can sell it as "making a setting out of something that was a constant", but we all know it is not :) Mostly, the game mechanics kinda assumes it never loops till 2090. After that, it really doesn't matter which year loops, as they would all act the same. In the years before that, it is a bit more special. As pointed out in earlier comments. The biggest of course is inflation. While looping, inflation keeps happening, and never stops. That would make such games barely playable. But .. on the other hand, this is a choice you make when using this with inflation. There will be many more places that will act weird when using this .. but those will never be addressed if not found. So I find myself at a cross-road. On one hand, this doesn't hurt adding, as really, nothing much changes. On the other hand, this could use some more attention to detail, how to solve these weird cases. But all of them are heavily opinionated, depending on what type of player you are. So that only results in this PR become unmergeable :) I just rebased this PR, but I cannot push in your branch. Sad panda ... I am going to sit on it for a bit .. but I am very tempted to just merge this for now, and deal with the fallout after. But I cannot deny there will be a fallout :) |
In words of the author:
Or in wise words of @frosch123 :
Let's do it before! (mostly referring to stuff like: inflation, engine aging, etc etc) Please feel free to open a PR with intentions of the PR and where the concerns are addressed; happy to take in such patch :) |
Hm, whatever the initial reason was I'd kinda like this setting for a different reason. As I'm running servers where environment doesn't change with time (gs controls engine availability, etc) so now I have to start them in 2060 just so it doesn't try to change anything even though logically it's more like 1990 (no mono and maglev). This also limits my options with other year-dependant stuff like oil wells for example. |
A place to continue this conversation: |
No description provided.