Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

Eddi-z
Copy link
Contributor

@Eddi-z Eddi-z commented Jan 15, 2020

No description provided.

@frosch123
Copy link
Member

If this setting is a thing, it should probably also affect

  • _year_engine_aging_stops
  • AddInflation
  • Possibly more things that have incremental effects.

@Eddi-z
Copy link
Contributor Author

Eddi-z commented Jan 15, 2020

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)

@James103

This comment has been minimized.

@Eddi-z
Copy link
Contributor Author

Eddi-z commented Jan 16, 2020

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.

@nielsmh
Copy link
Contributor

nielsmh commented Jan 16, 2020

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.

@Eddi-z
Copy link
Contributor Author

Eddi-z commented Jan 16, 2020

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.

i thought of that, and changed the year == MAX_YEAR+1 to year > loop_year

The MAX_YEAR value also needs to be observed no matter what

that should be fine, the setting ought to be clamped to MAX_YEAR

@TrueBrain TrueBrain added candidate: yes This Pull Request is a candidate for being merged size: small This Pull Request is small, and should be relative easy to process labels Dec 14, 2020
@TrueBrain
Copy link
Member

TrueBrain commented Dec 15, 2020

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 :)

@TrueBrain TrueBrain added the work: needs rebase This Pull Request needs a rebase label Dec 15, 2020
@TrueBrain
Copy link
Member

In words of the author:

i think the intention was "daylength is too complicated, let's do this instead", which is probably a bad reason to do it

Or in wise words of @frosch123 :

you can either have the discussion before merge, or after merge

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 :)

@TrueBrain TrueBrain closed this Dec 15, 2020
@ldpl
Copy link
Contributor

ldpl commented Dec 15, 2020

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.

@TrueBrain
Copy link
Member

A place to continue this conversation:

#8384

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
candidate: yes This Pull Request is a candidate for being merged size: small This Pull Request is small, and should be relative easy to process work: needs rebase This Pull Request needs a rebase
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants