Previously it checked the position in non-driving direction to "guess" whether
a ground vehicle was using the function, so on tunnels/bridges it could either
return the Z of the (virtual) ground compared to the Z of the path the vehicle
would take.
This is accomplished by changing it to a single member struct with the
appropriate operator overloads to make it all work with not too much
source modifications.
This is using a non-intrusive type-traits like templated system, which
allows compile-time validation that the command table and the command
enum match up.
Prior to this change, trees tended to either cover the entire map like an ancient forest, or alternatively you turn off their growth which breaks industry. Furthermore there are these ugly random tree clumps at the beginning of the game which look like squares on the map someone placed there.
This change adds a new tree placing setting which removes the ugly random clumps and only slightly modifies the initial placement. The actual growth causes trees to bunch up in higher levels as usual but on the lower 4 levels their growth works differently. The number of trees per tile is limited and the trees spread out over a wider area instead of only to the neighboring tile. That spreads them out more and makes for a nicer look.
This also allows cacti to spread, since they can now use that same algorithm and avoid bunching up, but spread as they should.
This means that random tree generation density is higher on small maps and lower on large maps. This difference is enough to make the Lumber Mill impractical to use on large maps.
This change skips ticks on maps smaller than 256x256 and increases iterations or shortens the interval on maps larger than 256x256.
(cherry picked from commit b972ed8604)
This means that random tree generation density is higher on small maps and lower on large maps. This difference is enough to make the Lumber Mill impractical to use on large maps.
This change skips ticks on maps smaller than 256x256 and increases iterations or shortens the interval on maps larger than 256x256.
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.
