english (us): 23 changes by 2TallTyler
luxembourgish: 63 changes by phreeze83
ukrainian: 72 changes by StepanIvasyn
catalan: 5 changes by J0anJosep
turkish: 5 changes by nullaf
english (us): 7 changes by HAJDog247
czech: 18 changes by PatrikSamuelTauchim
luxembourgish: 99 changes by phreeze83
serbian: 4 changes by nkrs
catalan: 20 changes by J0anJosep
french: 1 change by arikover
portuguese: 30 changes by azulcosta
swedish: 30 changes by kustridaren
spanish (mexican): 1 change by absay
japanese: 13 changes by Azusa257
vietnamese: 1 change by KhoiCanDev
estonian: 12 changes by siimsoni
czech: 6 changes by PatrikSamuelTauchim, 2 changes by tomas-vl
chinese (simplified): 88 changes by clzls
arabic (egypt): 16 changes by AviationGamerX
luxembourgish: 4 changes by phreeze83
korean: 34 changes by telk5093
italian: 16 changes by AlphaJack
german: 1 change by danidoedel, 1 change by Wuzzy2
slovak: 30 changes by FuryPapaya
catalan: 35 changes by J0anJosep
tamil: 16 changes by Aswn
dutch: 32 changes by Afoklala
portuguese (brazilian): 14 changes by Greavez, 5 changes by jpsl00
Before this commit, it scaled to map-height-limit. Recently this
could also be set to "auto", meaning players don't really know
or care about this value.
This also means that if a player exported a heightmap and wanted
to import it again, looking like the exact same map, he did not
know what value for "highest peak" to use.
This opens up the true power of the TGP terrain generator, as it
is no longer constrainted by an arbitrary low map height limit,
especially for extreme terrain types.
In other words: on a 1kx1k map with "Alpinist" terrain type, the
map is now really hilly with default settings.
People can still manually limit the map height if they so wish,
and after the terrain generation the limit is stored in the
savegame as if the user set it.
Cheats still allow you to change this value.
This better reflects what it is, and hopefully removes a bit of
the confusion people are having what this setting actually does.
Additionally, update the text on the setting to better inform
users what it is doing exactly, so they can make an educated
decision on how to change it.
Next commit will introduce an "auto" value, which should be the
new default. The rename has as added benefit that everyone will
start out on the "auto" value.
This setting influence the max heightlevel, and not as the name
suggests: the height of the generated map.
How ever you slice it, it is a very weird place to add this
setting, and it is better off being only in the settings menu.
Commits following this commit also make it more useful, so users
no longer have to care about it.
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.
Otherwise both the draw-thread and game-thread can do it both
at the same time, which gives rather unwanted side-effects.
Calling it from the draw-thread alone is sufficient, as we just
want to create some unpredictable randomness for the player. The
draw-thread is a lot more active (normally) than the game-thread,
so it is the best place of the two to do this.
Additionally, InteractiveRandom() mostly has to do with visuals
that are client-side-only, so more related to drawing than to
game.
v->tile for aircrafts is always zero when in the air. Only when
it starts its landing (or take-off) patterns it becomes a sane
value.
So instead, base the news on the last x/y coordinates of the plane.
english (us): 18 changes by 2TallTyler
korean: 17 changes by telk5093
german: 13 changes by danidoedel, 4 changes by Wuzzy2
finnish: 17 changes by hpiirai
catalan: 17 changes by J0anJosep
lithuanian: 33 changes by devbotas
spanish: 17 changes by MontyMontana
portuguese (brazilian): 20 changes by Greavez
polish: 9 changes by yazalo
This because video-drivers might need to make changes to their
context, which for most video-drivers has to be done in the same
thread as the window was created; main thread in our case.
This allows drawing to happen while the GameLoop is doing an
iteration too.
Sadly, not much drawing currently can be done while the GameLoop
is running, as for example PollEvent() or UpdateWindows() can
influence the game-state. As such, they first need to acquire a
lock on the game-state before they can be called.
Currently, the main advantage is the time spend in Paint(), which
for non-OpenGL drivers can be a few milliseconds. For OpenGL this
is more like 0.05 milliseconds; in these instances this change
doesn't add any benefits for now.
This is an alternative to the former "draw-thread", which moved
the drawing in a thread for some OSes. It has similar performance
gain as this does, although this implementation allows for more
finer control over what suffers when the GameLoop takes too
long: drawing or the next GameLoop. For now they both suffer
equally.
Drawing in a thread is a bit odd, and often leads to surprising
issues. For example, OpenGL would only allow it if you move the
full context to the thread. Which is not always easily done on
all OSes.
In general, the advise is to handle system events and drawing
from the main thread, and do everything else in other threads.
So, let's be more like other games.
Additionally, putting the drawing routine in a thread was only
done for a few targets.
Upcoming commit will move the GameLoop in a thread, which will
work for all targets.
The video drivers using the OpenGL backend are currently our only
accelerated drivers. The options defaults to off for macOS builds and
to on everywhere else.
Co-authored-by: Michael Lutz <michi@icosahedron.de>
chinese (traditional): 5 changes by benny30111
estonian: 1 change by siimsoni
italian: 1 change by AlphaJack
ukrainian: 4 changes by StepanIvasyn
tamil: 37 changes by Aswn
portuguese (brazilian): 19 changes by Greavez
Reworked how the screenshot command works while keeping it backwards
compatible. It can now more freely understand arguments, and has
the ability to make SC_DEFAULTZOOM screenshots.
In other words, it should only (!) return true if A comes for B.
This promise was broken for the situation where two values are
identical. It would return true in these cases too. This is of
course not possible: if two values are identical, neither come
before the other. As such, the sorter was not imposing strict
weak ordering relations.
libstdc++ handled this scenario just fine, but libc++ crashes
badly on this, as it allowed comparing of [begin, end] instead
of [begin, end).
libc++ considered this not a bug (and by specs, they are correct;
just this way of crashing is of course a bit harsh):
https://bugs.llvm.org/show_bug.cgi?id=47903
english (us): 4 changes by 2TallTyler
italian: 4 changes by troccoli
serbian: 251 changes by nkrs
german: 6 changes by ebla71, 2 changes by Wuzzy2
romanian: 3 changes by ALEX11BR
russian: 11 changes by Ln-Wolf
ukrainian: 2 changes by StepanIvasyn
lithuanian: 15 changes by devbotas
spanish: 2 changes by perezdidac
The bootstrap has the _switch_mode to SM_MENU, and never leaves
this mode. Neither is it considered a modal window (while in some
sense it really is). So .. we need to add another "draw anyway"
exception, to make sure bootstrap is being drawn.
When you are downloading a map, all the commands are queued up
for you. Clients joining/leaving is done by the network protocol,
and as such are processed immediately. This means that by the
time you are processing the commands, a client that triggered
it, might already have left.
So, all commands that do something with ClientID, shouldn't
error on an invalid ClientID when DC_EXEC is set, but
gracefully handle the command anyway, to make sure the
game-state is kept in sync with all the clients that did
execute the DoCommand while the now-gone client was still
there.
Additionally, in the small chance a client disconnects between
the server validating a DoCommand and the command being
executed, also just process the command as if the client was
still there. Otherwise, lag or latency can cause clients that
did not receive the disconnect yet to desync.
Strictly seen, there are "N" people -waiting- in front of you
in the queue, but it is nicer to show "N + 1" for the person that
is currently downloading the map. Avoids it showing:
"0 clients in front of you". That just feels a bit off.
swedish: 60 changes by kustridaren
norwegian (bokmal): 12 changes by buzzCraft
czech: 82 changes by PatrikSamuelTauchim, 1 change by tomas-vl
italian: 86 changes by AlphaJack, 9 changes by federico1564S
german: 16 changes by ebla71
romanian: 10 changes by ALEX11BR
ukrainian: 3 changes by StepanIvasyn
spanish: 1 change by MontyMontana
SendError() notifies all clients of the disconnect. This calls
CloseConnection() at the end, which also notified the clients
of the disconnect. Really no need to do it twice.
The status NETWORK_RECV_STATUS_SERVER_ERROR is only set by
SendError(), so in case that is the status, don't let
ClientConnection() send another notification.
CheckCompanyHasMoney() was also executed when not using DC_EXEC,
resulting in an error about shortage of money instead of the
estimation.
This mostly is a problem for AI players, as they will have no
way to know how much it would have cost.
Basically, follow_track.hpp contains a fix for half-tiles, but
this wasn't duplicated for when trying to find a depot and in
a few other places. This makes sure all places act the same.
MainLoop() is used to bootstrap OSX, where later a callback is
done to GameLoop() to execute OpenTTD. All other video drivers
don't need that, so what is in GameLoop is in MainLoop for all
other drivers. This is rather confusing. So, instead, name
GameLoop MainLoopReal to be more in sync with the other drivers.
This makes it a bit easier to follow what is going on, and
allow future subdrivers to hook into a few of these functions.
Reworked the code slighly while at it, to return early where
possible.
When we clip the region that is only been redrawn, something
weird happens on Windows. When pushing 60 frames per second on a
60Hz monitor, it appears that the clipped region is often shown
of another frame, instead of the current.
Examples of this are:
- pause the game, move your mouse to the left, and at the right
speed it totally disappears.
- fast aircrafts seem to be in several places at once, weirdly
lagging behind.
- in title screen, moving your mouse gives you the idea it is
jumping places, instead of smooth movements.
In the end, if you do nothing, everything is correct, so it is
eventually consistent. Just when we are firing many BitBlt in
a clipped region, the in-between is not.
What goes wrong exactly, I honestly do not know. On every frame
that we push to the DC is a mouse painted, but visually it
sometimes appears like it is not. Recording with external software
shows it really is there.
It is also not our eyes playing tricks on us, as the first example
makes it really clear the mouse pointer really is not painted.
And to be clear, with the mouse this is easiest reproduceable,
as high-speed objects are influences by this most. But this happens
for all movement that redraws small regions.
Either way, not using clipped regions resolves the issue completely,
and there appears to be little to no penalty (I failed to measure
any impact of drawing the full screen). So better have a good game
than fast code, I guess?
When drawing an 8bpp screen buffer, palette resolving was done for each
dirty rectangle. In areas with high activity, this would mean a pixel might
have been resolved multiple times. Also, if too many individual updates
were queued, the whole screen would be refreshed, even if unnecessary.
All other drivers only keep one overall dirty rect, so do it here as well.
These were special settings only for the win32-drivers, and
introduced in the very first version we track.
Time kinda had caught up with those variables, so it is time to
say farewell.
force_full_redraw was most likely a debug functionality "in case
our dirty-rect fails". This should no longer be needed.
display_hz was cute, as it had a max of 120. That is kinda
out-dated information, but I also doubt anyone was really using
this.
In file included from src/settingsgen/../string_func.h:30,
from src/settingsgen/settingsgen.cpp:11:
src/settingsgen/../core/bitmath_func.hpp:34:15: error: 'uint' does not name a type; did you mean 'uint8'?
34 | static inline uint GB(const T x, const uint8 s, const uint8 n)
| ^~~~
| uint8
WM_PAINT hits when-ever Windows feels like, but always after we
marked the screen as dirty. In result, it was lagging behind,
giving a sub-60fps experience.
With the new draw-tick there is no longer a need to be driven by
WM_PAINT, so it is better anyway to drive the drawing ourself. As
an added bonus this makes the win32 driver more like the others.
For some reason I only converted one of the two modal windows we
have, and completely forgot the other.
While at it, synchronize the way those two modal windows work
in terms of "next_update".
The higher your refresh-rate, the more likely this is. Mostly you
notice this when creating a new game or when abandoning a game.
This is a bit of a hack to keep the old behaviour, as before this
patch the game was already freezing your mouse while it was changing
game-mode, and it does this too after this patch. Just now it
freezes too a few frames earlier, to prevent not drawing windows
people still expect to see.
Most modern games run on 60 fps, and for good reason. This gives
a much smoother experiences.
As some people have monitors that can do 144Hz or even 240Hz, allow
people to configure the refresh rate. Of course, the higher you
set the value, the more time the game spends on drawing pixels
instead of simulating the game, which has an effect on simulation
speed.
The simulation will still always run at 33.33 fps, and is not
influences by this setting.
Sleep for 1ms (which is always (a lot) more than 1ms) is just
randomly guessing and hoping you hit your deadline, give or take.
But given we can calculate when our next frame is happening, we
can just sleep for that exact amount. As these values are often
a bit larger, it is also more likely the OS can schedule us back
in close to our requested target. This means it is more likely we
hit our deadlines, which makes the FPS a lot more stable.
Before, every next frame was calculated from the current time.
If for some reason the current frame was drifting a bit, the
next would too, and the next more, etc etc. This meant we rarely
hit the targets we would like, like 33.33fps.
Instead, allow video-drivers to drift slightly, and schedule the
next frame based on the time the last should have happened. Only
if the drift gets too much, that deadlines are missed for longer
period of times, schedule the next frame based on the current
time.
This makes the FPS a lot smoother, as sleeps aren't as exact as
you might think.
During fast-forward, the game was drawing as fast as it could. This
means that the fast-forward was limited also by how fast we could
draw, something that people in general don't expect.
To give an extreme case, if you are fully zoomed out on a busy
map, fast-forward would be mostly limited because of the time it
takes to draw the screen.
By decoupling the draw-tick and game-tick, we can keep the pace
of the draw-tick the same while speeding up the game-tick. To use
the extreme case as example again, if you are fully zoomed out
now, the screen only redraws 33.33 times per second, fast-forwarding
or not. This means fast-forward is much more likely to go at the
same speed, no matter what you are looking at.
_realtime_tick was reset every time the diff was calculated. This
means if it would trigger, say, every N.9 milliseconds, it would
after two iterations already drift a millisecond. This adds up
pretty quick.
On all OSes we tested the std::chrono::steady_clock is of a high
enough resolution to do millisecond measurements, which is all we
need.
By accident, this fixes a Win32 driver bug, where we would never
hit our targets, as the resolution of the clock was too low to
do accurate millisecond measurements with (it was ~16ms resolution
instead).
InvalidateWindowData with mode SBI_NEWS_DELETED was called on the
status bar when checking for a new item of news to be shown in the
ticker, even if there is no news queued and no change occurs.
When there are a lot of rects to redraw, of which one of the last
ones is almost the full screen, visual tearing happens over the
vertical axis. This is most visible when scrolling the map.
This can be prevented by using less rects. To simplify the situation,
and as solutions like OpenGL need this anyway, keep a single rect
that shows the biggest size that updates everything correctly.
Although this means it needs a bit more time redrawing where it
is strictly seen not needed, it also means less commands have
to be executed in the backend. In the end, this is a trade-off,
and from experiments it seems the approach of this commit gives
a better result.
During resizing, there can still be dirty-rects ready to blit based
on the old dimensions. X11 with shared memory enabled crashes if
you try to do this. So, instead, if we resize, reset the dirty-rects.
This is fine, as moments later we mark the whole (new) screen as
dirty anyway.
The first point was counted, but also initialized as "last". As
such, it didn't add to "total", but did add to "count", which made
the "count" 1 more than the total actually represents.
korean: 2 changes by telk5093
indonesian: 11 changes by dimaspaf14
russian: 2 changes by Ln-Wolf
finnish: 3 changes by hpiirai
french: 4 changes by glx22
The zoom level suggestion is based on the DPI scaling set in Windows.
We use 150% scaling as the threshold for 2X zoom and 300% scaling
as the threshold for 4X zoom.
We never change the real screen resolution on OSX. As such, offering a list
of resolutions is pointless. Instead of that, offer the user a list of
commonly used window sizes up to the current screen size.
Many of the member variables that are used in save/load are inside types
that are not standard layout types. Using pointer arithmetics to determine
addresses of members inside types that are not standard layout is generally
undefined behaviour. If we'd use C++17, it is conditionally supported, which means
each compiler may or may not support it. And even then using it for individual
array elements is syntactically not supported the the standard offsetof function.
Unfortunately, the trickery employed for saving linkgraph settings causes quite some
clutter in the settings ini files.
Many of the member variables that are used in the oldloader are inside types
that are not standard layout types. Using pointer arithmetics to determine
addresses of members inside types that are not standard layout is generally
undefined behaviour. If we'd use C++17, it is conditionally supported, which means
each compiler may or may not support it. And even then using it for individual
array elements is syntactically not supported the the standard offsetof function.
In testing, I could find no reason why this statement is here.
The comment is rather unclear (it states what it does, but not
why it would be needed).
This line of code was introduced with f4f40448, which gives no
further insight on why it would be needed to have it here.
As such, let's remove it and see if anyone else reports any
problems with it. If so, this commit can be reverted and a more
clear comment should be added what this line of code is dealing
with (the WHY, not the WHAT).
This means the code depended that the caller did this for us
before MakePalette() is executed, which is neither a
requirement nor a promise the code makes.
When the wayland SDL video driver is used, an EGL context is
created in the main thread. It is not allowed to update this
context from another thread, which is exactly what our draw-thread
is trying.
The other solution would be to move all of SDL into the
draw-thread, but that would introduce a whole scala of different
problems.
The wayland SDL backend is significantly faster than the
X11 SDL backend, but there is a performance hit nevertheless.
If a server is compatible, it falls back to sorting by clients.
This used to be in reverse, so full servers are on top. With
the codechange commit, this was removed by accident, and as
such empty servers were on top. This is silly.
It now follows more what the Win32 driver does, and has far less
exceptions and special casing.
MakePalette creates the Palette and prepares surface.
UpdatePalette updates the Palette.
CheckPaletteAnim checks if UpdatePalette needs to be called and
marks the whole screen dirty so DrawSurfaceToScreen will do a
full redraw.
Sometimes it returned an usererror(), sometimes Start() failed.
Now it always fails on Start(), so nothing else has to check again
what blitter is used.
AfterBlitterChange() can never change to a 0bpp, so it is sufficient
to guard this with an assert().
Additionally, tell exactly why the font failed to load, which
glyph was missing from the font. This hopefully helps the user
a bit more in the right direction.
This makes no sense, that a free-wagon-chain could be larger than
the maximum length of a train, as you cannot put an engine in
front of that anyway. And it prevents run-away AIs making very
silly long free-wagon-chains.
The current "restart" command is now called "reload", as that is
what it does.
The old "restart" command is now called "restart", as that is what
it did.
As this has not been in any official release yet, this shouldn't
harm any kitten.
For non-NewGRF planes, "count" is never above 1. So planes can
smoothly be guided to their destination. For NewGRF planes, they
can go as quick as "count" values of 20. This easily overshoots
the target. So, calculate if the plane will overshoot, and start
nudging him to the destination earlier. You won't notice this
either way, as it all happens within a single tick.
Although meant as a funny joke towards the player, our social
standards have changed since 2004, and such "jokes" are no
longer acceptable by the community as a whole.
The only value of the message is that people are informed the
information is stored in the savegame. This is mostly useful for
us, developers, as some of those cheats can have side-effects
which people report.
While at it, styled the GUI a bit better, as the way the text
was presented was odd.
korean: 2 changes by telk5093
finnish: 2 changes by hpiirai
dutch: 49 changes by Afoklala
spanish: 16 changes by Luis45ccs
french: 7 changes by dimensi0n
polish: 2 changes by yazalo
This change allows a user to see what is available and what will become
available before it is available, instead of only disabling the button
with no further explanation. It also always allows building roads and
canals, even if no vehicles are available for road / water.
For rail/road/tram, a dropdown with available types is shown. If
none are available, it reads "None". If the type is not yet available,
it is greyed out.
For dock/airport, this always open the toolbar, but building airports,
docks, and depots buttons are disabled till vehicles are available
for those.
Road is the only exception, with the primary road always being
available. Here too, stations and depots are disabled till vehicles
become available. It does mean you can now always build roads to
for example help towns grow.
Before it was shown as a normal order, but the vehicle was skipping
it. This was rather unclear to the user. Now it is red and contains
text with some hints what is going on.
The text is prefixed rather than post-fixed, as we have many
post-fixes already.
This reverts commit c1fddb9a6a and 639cfa43d2.
access_mode "none" is only supported by GCC11, but introduced
after it branched. So there are GCC11.0s out there that do not
support it. We will have to wait for GCC11.1 to hit before we
can re-add this.
Without hills, not all industries can be generated, which means
that with a default configuration you get errors. This is far from
optimal, of course.
This now forces that there is at least some hills, even when you
are using very-flat. This is a stopgap solution, but a proper
solution requires a full rewrite of the terrain generator, which
is not a 2 minute (or even 2 week) job.
To make sure flat is still flat-ish, reduce the default
snow-line-height to 10, making it look a lot better on smaller maps.
This is a compromise between being able to have flat maps and
still having all industries on arctic.
This means that for rail tunnel/bridges, the rail is first sold,
and the tunnel/bridge is destroyed after. This means destroying
tunnels/ bridges now often makes you money, instead of costing.
Similar, with road/tram tracks. Destroying a road+tram
tunnel/bridge now costs the same amount of money as first
removing the tram tracks and than destroying the road
tunnel/bridge. Especially as tram tracks generate money when
removing, this is a noticeable difference.
It only considered the end-tile (or start-tile) for the bridge,
instead of both. This is obvious in the rest of the code which
constantly does "+ 2"; this being the only place that does a "+ 1".
Despite what it looked like, you could never really change the
ending-year (it was always reset to 2050 on start-up). See commit
683b65ee1 for details. As a side-effect, the variable that was
suppose to store the ending-year was just zero, never containing
a real ending-year.
MAX_YEAR is set to 5000000, but having an ending-year set to the
same meant you could bypass this, and play till the uint32 wrapped.
The game can either show highscore or wrap year, not both. When
you would do both, every year you get the highscore dialog.
By changing the maximum value of ending-year to 4999999 we prevent
this issue.
spanish (mexican): 5 changes by absay
korean: 5 changes by telk5093
finnish: 5 changes by hpiirai
latvian: 14 changes by lexuslatvia
spanish: 23 changes by SeveralCircles, 10 changes by Luis45ccs
polish: 5 changes by yazalo
The selected group was not reset when drag&drop was aborted. When
after that vehicle drag&drop was successful, group drag&drop code
was still executed, causing weird behaviour or even crashes.
When a multi-tile house is rebuild, it always used the most northern
tile to build the new house. This can very easily lead to houses
wandering off in the north-ish direction (either NW or NE).
To prevent this, pick the tile closest to town center when rebuilding
on a multi-tile house. This still means a house can be build away
from a road, but it is no longer wandering around finding another
town to call home.
This is a much better location for this button, as you send
money from one company to another company, not from player
to player.
This is based on work done by JGRPP in:
f820543391
and surrounding commits, which took the work from estys:
https://www.tt-forums.net/viewtopic.php?p=1183311#p1183311
We did modify it to fix several bugs and clean up the code while
here anyway.
The callback was removed, as it meant a modified client could
prevent anyone from seeing money was transfered. The message
is now generated in the command itself, making that impossible.
When a vehicle is cleaned up, all news that points to the news is
also removed. This was a bit evil, as it would also remove any
news related to crashed, acting like the crash never happened.
This left players a bit in the dark what was going on exactly.
This means that if you start OpenTTD with "-c" to indicate another
location to store files, it can still read the content you already
downloaded from your PERSONAL_DIR. This folder is, however,
read-only.
This is useful for situations where you downloaded OpenGFX via
the content-service, but want to run the regression or want to
run with a clean configuration. With this change, you no longer
need to download OpenGFX again.
When running with -dsl=2 it is very easy to miss important information
as there was a lot of noise in between too. This tunes the debug
levels a bit to be less noisy while keeping the important bits.
The previous fix 887e9481ff0e70df6bf93ce15a3899a03f124c50 only worked for roads and failed to consider a multiplier used for the infrastructure totals for tunnels/bridges.
Also, depots and bus/truck stops are counted as 2 road pieces on creation but were only counted as 1 road piece on conversion because the function DiagDirToRoadBits() was used, which only ever returns single-piece road segments.
Co-authored-by: A. S <admin-git@sotai.tk>
You can do: "startai myai.3", which starts version 3 of "myai".
This is very useful for testing save/load code between different
versions of your AI.
However, when using this syntax, the AI got saved as "myai.3" as
name of the AI, instead of "myai". This caused several problems,
like indicating to the user the AI could not be found, but still
load the AI. But in all cases, the AI never got the chance to
load the saved data, making the whole reason this exists pointless.
By splitting the name and version already in the console command,
the code becomes simpler and AIs started this way now follow the
normal flow after initialization.
It was rather confusing that "library_name" was calculated, and
then not used to do the FindLibrary() call. Flipping those two
blocks around makes it a bit more sane to read.
When link graph jobs are cleared due to abandoning the game or exiting,
flag the job as aborted.
The link graph job running in a separate thread checks the aborted flag
periodically and terminates processing early if set.
This reduces the delay at game abandon or exit if a long-running job
would otherwise still be running.
Check if the job is still running two date fract ticks before it is due
to join, and if so pause the game until its done.
When loading a game, check if the game would block immediately due to
a job which is scheduled to be joined within two date fract ticks,
and if so pause the game until its done.
This avoids the main thread being blocked on a thread join, which appears
to the user as if the game is unresponsive, as the UI does not repaint
and cannot be interacted with.
Show if pause is due to link graph job in status bar, update network
messages.
This does not apply for network clients.
Various of PatchPacks (Spring 2013, Joker, ChillPP) used versions
slightly higher than ours. Of course, as time went by, this
caught up with us, and we are now almost pushing a new version
that would conflict with them. To avoid users creating unneeded
issues about "why can I not load my savegame", lets be ahead of
the curve and flat-out refuse to load them.
Version-wise, this is totally fine. We have ~32k versions to go
before we run out (0x8000 is masked by JGRPP; we should avoid
using that). At the rate we bump savegames, this is not going to
happen in any sane reality.
Apple Clang version 12 (bundled with Xcode 12) complaints about copying
small objects in range loop (-Wrange-loop-analysis introduced by -Wall).
This warning can be easily avoided by removing the reference from
the const pointer type.
This means that for NE/NW, it should have one more in case of
freeform-edges, and in case of SE/SW it should have one less.
Reminder: freeform-edges only adds VOID tiles on X=0 and Y=0.
This is for consistency; most other objects add a # to indicate
it is the Nth of that object, except for Trains / RVs / Ships /
Aircrafts.
This becomes painfully apparent with unnamed vehicles in groups,
which do get a "#".
This mode doesn't wrap the mouse constantly, but requests SDL
to lock the mouse pointer. This is needed, as with Emscripten
you are not allowed to change the mouse poisition (only to lock
it into place).
Emscripten compiles to WASM, which can be loaded via
HTML / JavaScript. This allows you to play OpenTTD inside a
browser.
Co-authored-by: milek7 <me@milek7.pl>
This commit prepares for the next commit, as Emscripten needs to
have a way to trigger a single iteration of the main loop. To
keep the real changes more clear, this commit only unrolls the
loop, and makes no changes to the logic itself.
With \x, we sometimes had to do the "" trick, as the length is not
predefined. With C++11 bringing \u to the specs, which has a preset
length, we no longer need the "" trick.
We set the strings to u8, to ensure all compilers use UTF-8 encoding
for the \u characters.
This was triggered by newer CLangs, which start to warn if you
use "" in the middle of a string, wondering if that was your
intention. It is a good question. And this is our answer :)
On Windows, relative folders don't work so well. So we need to
lookup the full path. This is best done in DetermineBasePaths()
and as a bonus that only sets SP_WORKING_DIR once.
Basically, with '-c' you now create a sandbox. It will still use
your personal-dir and global-dir to find files you installed there,
but all new files are stored with a base folder identical to the
folder the configuration is in.
This is a bit of an old bug, that we many have tried to solve in
various of different ways. The code has grown sufficiently complex
that it is hard to see what consequences of actions are. This is
in my opinion the most harmless solution, while increasing the
usefulness of the '-c' flag.
In essence, the problem was that empty folders were always created
in the directory where the configuration was, but as that directory
wasn't added to any searchpath, files weren't stored there, unless
by accident it was a folder already on the searchpath. For example,
if you do './openttd -c local.cfg', it did work as expected. But
in the more generic variant, it did not.
With this patch, you can run './openttd -c /new/folder/local.cfg',
and it will create and prepare that folder to receive new files.
'content_download' is also stored in the directory the
configuration is in; this was already the case. Important to
note that there is only one search-path for 'content_download'.
In other words, when using '-c', it will not look in '~/.openttd'
inside the 'content_download' folder.
This was just weird. With XDG _personal_dir was created already,
but later on it was checked if it was different from config_dir,
and the creation was skipped. All this checking and validation
makes my head spin .. let's make it a bit more simple.
Formally it was only done on exit. This means that if it crashes
changes in settings were not stored. This is often rather
frustrating. Additionally, targets (like emscripten) where people
are unlike to use "Exit Game", will never see their configuration
stored.
The drawback is that on every setting change there is some minor
I/O of writing the ini file to disk again.
If I explicitly tell the system I do not want sound, I still get
presented a nice message I do not have any BaseSounds available
on my system, and that I should download one to enjoy sound. Well,
let me tell you, with "-snull" that is really really not going to
help. So please, be quiet, and let me enjoy the game without
"boooooo" and "DING DING DING".
Thank you.
The intention of this function was that you could download
everything after a filter was applied; but this never really
took off. Instead, a select few people used this functionality
to download every available package on BaNaNaS. This is not in
the spirit of this service. Additionally, these few people were
good for 70% of the consumed bandwidth of BaNaNaS.
This is, by specs, undefined behaviour. See
https://reviews.llvm.org/D67122
In cases where this is done, optimizations done by LLVM can
generate code that causes crashes.
GetVariableAddress() had two (legit) ways this could happen:
- For SaveLoad set to global
- For SaveLoad set to SLE_VAR_NULL, where sld->address is always
a nullptr, and object could or could not be a nullptr.
italian: 1 change by AlphaJack
romanian: 13 changes by ALEX11BR
finnish: 6 changes by VeeraKoo
slovak: 202 changes by FuryPapaya
spanish: 240 changes by MontyMontana
When the restart command is issued, a normal map is always spawned.
This improvement takes into account the current state of _file_to_saveload to check if a savegame/scenario/heightmap was previously loaded, and loads the same resource again.
When compiling with '-Og', GCC warns about variables that are
initialized by reference in the condition of a 'while' loop.
This commit silences the warning by explicitly initializing the
variables in question to their respective 'invalid value' markers,
which will most likely be optimized out when the compiler realizes
the values are never used.
This changes the error when you attempt to convert a road owned by a town to another road, specifying that it's owned by the town rather than simply being incompatible. As the original poster of the issue pointed out, these seemed to be the only occurences of the incompatible road string, so now it's unused, but they would be left untouched in case of future use or since changing it to a different error would do the work of removing it then. If requested, it likely wouldn't be too difficult to remove the string entirely.
In 11ab3c4e the number of cargo types was changed from 32 to 64.
The save/load of Town::cargo_accepted was not updated, such that
only half of the data structure is saved/loaded in savegame versions
199 to 218.
Discard and regenerate data from all savegame versions prior to 219.
In 63ccb36e BaseConsist::name was changed from a malloced char*
to a std::string.
OrderBackup inherits from BaseConsist.
The saveload of OrderBackup::name was not updated.
Remove static buffer form of NetworkAddress::GetAddressAsString.
This is used in multiple threads concurrently, and is not thread-safe.
Replace it with a form returning std::string.
This fixes a bug that can reproduced with these steps:
* Start openttd in fullscreen mode
* Turn off fullscreen mode
* Try to resize the window. The window can't be resized.
CMake works on all our supported platforms, like MSVC, Mingw, GCC,
Clang, and many more. It allows for a single way of doing things,
so no longer we need shell scripts and vbs scripts to work on all
our supported platforms.
Additionally, CMake allows to generate project files for like MSVC,
KDevelop, etc.
This heavily reduces the lines of code we need to support multiple
platforms from a project perspective.
Addtiionally, this heavily improves our detection of libraries, etc.
Initialization code for GRFFile::roadtype_map was copied from
railtype_map. But while RailType is a byte-sized enum and could thus
be initialized via memset, RoadType doesn't have a defined size.
Previously the internal content list was invalidated and sorted for
every new item added. Now the sorting is delayed until the GUI is
drawn, which means we only sort once per GUI tick.
Since the amount of incoming items per GUI tick is not controlled by
the GUI but rather by network speed, we were previously doing a lot
of duplicate work per tick, causing the mouse cursor to lag while
the list was initialized.
Allow more direct player-initiated interaction for Game Scripts, by letting the GS put push-buttons on storybook pages. These buttons can either trigger an immediate event, or require the player to first select a tile on the map, or a vehicle.
Additionally this reworks how the storybook pages are layouted and rendered, to allow for slightly more complex layouts, and maybe speeding drawing up a bit.
Variable-length values would write threshold values with a byte too many.
System Exclusive messages would cause write to fail since the end byte was treated as part of next message.
Jonathan G Rennison
Tyler Trahan
stormcone
milek7
Charles Pigott
translators
Patric Stout
Mike
Milek7
Koen Bussemaker
Michael Lutz
frosch
dP
Peter Nelson
Matt Kimber
Didac Perez Parera
sean
Eddi-z
Limyx826
Owen Rudge
Niels Martin Hansen
SamuXarick
Joe Stringer
Tegas Aziz
Wuzzy
glx22
Johannes E. Krause
Kuhnovic
Loïc Guilloux
embeddedt
Chris Stevens
gooball
Matt Kimber
Andy
J0anJosep
cirdan
Bernard Teo
Bernard Teo
Xaroth Brook
Byoungchan Lee
Tyler Trahan
jostephd
Rasmus Jonsson
Lars Wendler
FuryPapaya
Galigator
Berbe
Łukasz Hryniuk
TechGeekNZ
Abdurrahmaan Iqbal
TrevorShelton
ilayaraja97
duck
nikolas
arikover
Miguel Horta
Marcus Calhoun-Lopez
Yexo
Yexo