This is an indication value; the game tries to get as close as it
can, but due to the complex tropic rules, that is unlikely to be
exact.
In the end, it picks a height-level to base the desert/tropic
line on. This is strictly seen not needed, as we can convert any
tile to either. But it is the simplest way to get started with
this without redoing all related functions.
Setting the snow coverage (in % of the map) makes a lot more sense
to the human, while still allowing the niche player to set (by
finding the correct %) a snow line height they like. This makes for
easier defaults, as it decoupled terrain height from amount of snow.
Maps can never be 100% snow, as we do not have sprites for coastal
tiles.
Internally, this calculates the best snow line height to approach
this coverage as close as possible.
This used to work by accident: originally the code checked if
GenerateWorld was threaded. If not, it would abort the function.
This worked for placing trees, because it was also returning false
when it was not active.
With the recent changes, that check got removed, and this crash
started to happen. So now check if we have a modal window, which
is a very solid indication we are generating the world.
chinese (simplified): 2 changes by clzls
korean: 2 changes by telk5093
slovak: 9 changes by FuryPapaya
catalan: 4 changes by J0anJosep
polish: 4 changes by pAter-exe
swedish: 1 change by kustridaren
estonian: 1 change by siimsoni
russian: 5 changes by Ln-Wolf, 3 changes by SecretIdetity
ukrainian: 7 changes by StepanIvasyn
lithuanian: 31 changes by devbotas
portuguese: 54 changes by azulcosta
english (us): 8 changes by 2TallTyler
estonian: 16 changes by siimsoni
korean: 5 changes by telk5093
italian: 32 changes by AlphaJack
german: 5 changes by Wuzzy2
danish: 15 changes by achton
lithuanian: 89 changes by devbotas
spanish: 3 changes by MontyMontana
french: 8 changes by arikover
portuguese (brazilian): 3 changes by Greavez
polish: 17 changes by yazalo, 2 changes by pAter-exe
For example, if you have a config that defines OpenGFX as baseset
but for some reason you have no basesets anymore. In that case
bootstrap downloads OpenGFX for you, but it will still show the
error that "OpenGFX was not found" after the bootstrap. This was
an error generated before the bootstrapped kicked in.
Simply muting all errors during bootstrap solves this; as we cannot
show them anyway, this is fine. Any errors that remain after
bootstrap will be generated again anyway.
There are various of ways bootstrap can fail:
- Failing network connection
- Incomplete download
- No write permissions
- Disk full
- (others I forgot)
They all result in a screen with no windows. To ensure we at least
always show something when anything bad happens, if the bootstrap
is not successful, show a screen what the next step for the human
should be.
english (us): 7 changes by 2TallTyler
estonian: 17 changes by siimsoni
hungarian: 100 changes by pnpBrumi
ukrainian: 8 changes by StepanIvasyn
dutch: 24 changes by Afoklala
spanish: 338 changes by MontyMontana
french: 29 changes by MalaGaM
portuguese (brazilian): 1 change by Greavez
This means if you execute a script from a script from a script, ..
for more than 10 times, it bails out now. This should be sufficient
for even the most complex scripts.
MaskWireBits always returns its input unchanged if the input
has only 0 or 1 track bits set.
Having only 0 or 1 track bits sets (i.e. non junction tiles)
is by far the most common case.
Examining the state of neighbouring tiles and the subsequent
masking logic is relatively expensive and can be omitted in this case.
It didn't sit well to me, how I wrote the commit initially. First
casting a variable into another, only to write it back into the
originally feels wrong.
This flow makes a bit more sense to me.
Otherwise that might cause calls to the video-driver, which are
already shut down by now. This causes, depending on the video-driver
crashes or weird effects.
Basically, modal windows had their own thread-locking for what
drawing was possible. This is a bit nonsense now we have a
game-thread. And it makes much more sense to do things like
NewGRFScan and GenerateWorld in the game-thread, and not in a
thread next to the game-thread.
This commit changes that: it removes the threads for NewGRFScan
and GenerateWorld, and just runs the code in the game-thread.
On regular intervals it allows the draw-thread to do a tick,
which gives a much smoother look and feel.
It does slow down NewGRFScan and GenerateWorld ever so slightly
as it spends more time on drawing. But the slowdown is not
measureable on my machines (with 700+ NewGRFs / 4kx4k map and
a Debug build).
Running without a game-thread means NewGRFScan and GenerateWorld
are now blocking.
gui_zoom was never clamp'd between zoom_min/zoom_max.
zoom_min controls how zoomed-in we load sprites. For a value of 1,
no quad-sizes sprites are loaded. If gui_zoom would be 0, meaning
it wants quad-sized sprites to display, it was printing random
stuff to the screen, which could or could not result in crashes.
