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

Codechange: Don't explicitly unset _generating_world outside of genworld.cpp #9418

merged 1 commit into from Jul 10, 2021


Copy link

@glx22 glx22 commented Jul 8, 2021

Motivation / Problem

While trying to understand the cause for #9407, I noticed some

_generating_world = true;
_generating_world = false;

They are relatively safe (mainly used in GUI code), but I think it can (and should) be done safer.
The only place _generating_world can be explicitly set to false is in _GenerateWorld(), ie during the real generation.


I just followed the idea of ffec9b4, and used Backup to replace all direct writes to _generating_world from outside _GenerateWorld().
One place was already doing a proper backup, but without using Backup, so I updated it too.


Checklist for review

Some things are not automated, and forgotten often. This list is a reminder for the reviewers.

  • The bug fix is important enough to be backported? (label: 'backport requested')
  • This PR affects the save game format? (label 'savegame upgrade')
  • This PR affects the GS/AI API? (label 'needs review: Script API')
    • ai_changelog.hpp, gs_changelog.hpp need updating.
    • The compatibility wrappers (compat_*.nut) need updating.
  • This PR affects the NewGRF API? (label 'needs review: NewGRF')

Copy link

LordAro commented Jul 8, 2021

Of course, the better solution would not be relying on _generating_world all over the place...

@glx22 glx22 merged commit ddb6024 into OpenTTD:master Jul 10, 2021
14 checks passed
@glx22 glx22 deleted the generating_world branch Jul 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

Successfully merging this pull request may close these issues.

None yet

3 participants