Use uint16 to avoid truncation issues
Don't reserve memory for unused cargoes
Store history as ring buffer
Update history graph immediately on storage date
Show total waiting cargo
This makes it easier to spot chunks that have a save_proc that
is a nullptr, but also prevents confusion, where it looks like
the CH_ type of a chunk has influence on how it is being read.
It is not, it is only used for saving.
Basically it is very similar to Vehicles, where there first is
a type field, followed by data of that type. So this commit makes
it looks like how Vehicles solved that.
This removes a lot of custom "keeping track of length" stuff.
This adds two byte extra to those chunks, and might feel a bit
silly at first. But in later changes we will prefix CH_ARRAY with
a table header, and then this change shines.
Without this, we could still add headers to these chunks, but any
external reader wouldn't know if the CH_RIFF has them or not. This
way is much more practical, as they are now more like any other
chunk.
This means that during loading we can validate that what is saved
is also that what is expected. Additionally, this makes all list
types similar to how they are stored on disk:
First a gamma to indicate length, followed by the data.
The size still depends on the type.
In the end, the code was already doing the right thing, but a few
functions deep, and not really obvious. When validating what objects
can handle SLE_VAR_NULL, it is nicer to just have this obvious.
Using SL_ARR for this gives us a bit of trouble later on, where we
add a length-field to SL_ARR. This of course is not the intention
of SLE_CONDNULL. So better seperate it.
The current SaveLoad is a bit inconsistent how long a length field
is. Sometimes it is a 32bit, sometimes a gamma. Make it consistent
across the board by making them all gammas.
This helps external tooling to understand if a SL_STRUCT should
be skipped when reading. Basically, this transforms an SL_STRUCT
into a SL_STRUCTLIST with either 0 or 1 length.
This wasn't consistently done, and often variables were used that
were read by an earlier blob. By moving it next to the struct
itself, the code becomes a bit more self-contained and easier to
read.
Additionally, this allows for external tooling to know how many
structs to expect, instead of having to know where to find the
length-field or a hard-coded value that can change at any moment.
There was a lot of code duplication for no real reason. Now with
SLEG_STRUCT support, we can just re-use the code, hopefully making
it easier for future-us to make changes to this, without breaking
everything for old games.
With the new SLEG_STRUCT it is much easier to embed a struct
in a struct, where the sub-struct has limitations on when it is
being used.
This makes both the code easier to read (less magic) and avoids
the SaveLoad needing to know all these things about Stations
and Vehicles.
The commits following this will use this new functionality.
Currently, a few places do this manually. This has as drawback that
the Save() and Load() code need to be in sync, and that any change
can result in (old) savegames no longer loading. In general, it is
annoying code to maintain.
By putting everything in a description table, and use that for
both Save() and Load(), it becomes easier to see what is going on,
and hopefully less likely for people to make mistakes.
You can easily mistake SlList / SL_LST to be a list of SL_VAR, but
it is a list of SL_REF. With this rename, it hopefully saves a few
people from "wtf?" moments.
Prepare the full description and send it to SlObject. This does
require some code to be able to read to a SLE_VAR_NULL, like strings
etc, as there is no way to know their length beforehand.
It was rather confusing which one was for what, especially as some
SaveLoad flags were settings-only. Clean up this mess a bit by
having only Setting flags.
Basically, this changes "SaveLoad *" to either:
1) "SaveLoadTable" if a list of SaveLoads was meant
2) "SaveLoad &" if a single entry was meant
As added bonus, this removes SL_END / SLE_END / SLEG_END. This
also adds core/span.hpp, a "std::span"-lite.
This includes:
* CBID_VEHICLE_32DAY_CALLBACK
* CBID_VEHICLE_REFIT_COST
* CBID_VEHICLE_MODIFY_PROPERTY
This is on a per-property basis
The main benefit of this is to avoid callbacks not handled by the
vehicle's current sprite group from using the full graphics chain as
the "default" branch in the callback switch.
In the case where the graphics chain is long/expensive, a lot of work
had to be done before a callback failure result was eventually returned.
It now follows very simple rules:
0 - Fatal, user should know about this
1 - Error, but we are recovering
2 - Warning, wrong but okay if you don't know
3 - Info, information you might care about
4 -
5 - Debug #1 - High level debug messages
6 - Debug #2 - Low level debug messages
7 - Trace information
(Or when reloading NewGRFs)
If an overriding house type which newly fit in the limit changed the
tile layout, existing houses on the map could have the wrong layout
See: #243
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.
By default this setting is set to 2500% normal game speed.
(cherry picked from commit c3dc27e37e)
# Conflicts:
# src/gfx.cpp
# src/gfx_func.h
# src/settings_type.h
# src/video/cocoa/cocoa_v.mm
# src/video/video_driver.cpp
# src/video/win32_v.cpp
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.
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.
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.
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.
(cherry picked from commit d8c8f4e72d)
Fix group overrides affecting template image when cloning vehicle
Update template when changing company colours
Update template images on demand instead of at load
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.
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 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.
Jonathan G Rennison
rubidium42
Andreas Schmitt
Patric Stout
Tyler Trahan
glx22
PeterN
William Davis
Loïc Guilloux
Milek7
dP
Michael Lutz
Matt Kimber
Charles Pigott
Matt Kimber
Niels Martin Hansen
cirdan