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

Open
wants to merge 1 commit into
base: master
from

Conversation

@Eddi-z
Copy link
Contributor

Eddi-z commented Jan 15, 2020

No description provided.

@Eddi-z Eddi-z force-pushed the Eddi-z:groundhog branch from 4ac3a92 to b136ff9 Jan 15, 2020
@Eddi-z Eddi-z force-pushed the Eddi-z:groundhog branch from b136ff9 to bf5e346 Jan 15, 2020
@frosch123
Copy link
Member

frosch123 commented Jan 15, 2020

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 was marked as off-topic.

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants
You can’t perform that action at this time.