This reduced the load on compilers, as currently for example MacOS
doesn't like the huge settings-tables.
Additionally, nobody can find settings, as the list is massive and
unordered. By splitting it, it becomes a little bit more sensible.
LoadCheck makes it sound like something is really broken while
loading savegames, while it really is perfectly normal, as most
chunks do not implement LoadCheck.
num_liveries indirectly contained the same information, but this
makes reading these things pretty difficult. So use IsSavegameVersionBefore()
like everywhere else instead.
IsSavegameVersionUntil() did a [0, N] check, not [0, N) as the
name suggests.
Until can be a confusing word, where people consider it to be
including the upperbound. Dictionary states it means "before",
excluding the upperbound. There are long debates about who is right.
So, simply remove away from this ambiguity, and call it "before"
and "before or at". This makes the world easier for everyone.
We no longer need them. If you want to remove a field .. just
remove it! Because of the headers in the savegame, on loading,
it will do the right thing and skip the field.
Do remember to bump the savegame version, as otherwise older
clients can still load the game, but will reset the field you
have removed .. that might be unintentially.
We won't be able to make it fully self-descriptive (looking at you
MAP-chunks), but anything else can. With this framework, we can
add headers for each chunk explaining how each chunk looks like
in detail.
They also will all be tables, making it a lot easier to read in
external tooling, and opening the way to consider a database
(like SQLite) to use as savegame format.
Lastly, with the headers in the savegame, you can freely add
fields without needing a savegame version bump; older versions
of OpenTTD will simply ignore the new field. This also means
we can remove all the SLE_CONDNULL, as they are irrelevant.
The next few commits will start using this framework.
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.
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
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.
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.
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.
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.
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.
This can avoid out-of-memory situations due to single scripts using up the entire address space.
Instead, scripts that go above the maximum are killed.
The maximum is default 1 GB per script, but can be configured by a setting.
The last use was for storing a list of memory blocks. As the way these lists are accessed is very
specific, it is easier to just write an explicit destructor instead of trying to exactly match the behaviour.
This is a C++11 feature that allows the compiler to check that a virtual
member declaration overrides a base-class member with the same signature.
Also src/blitter/32bpp_anim_sse4.hpp +38 is no longer erroneously marked
as virtual despite being a template.
It is the only library we use that calls itself with 'lib' in the
name. This might be confusing, but with the arrival of cmake a lot
of these things are automated. And detection will find 'liblzma',
not 'lzma', like with 'lzo', 'zlib', ..
Rubidium
Stephan
Patric Stout
glx22
Loïc Guilloux
Tyler Trahan
PeterN
William Davis
Milek7
Michael Lutz
dP
Matt Kimber
Charles Pigott
Matt Kimber
cirdan
Jonathan G Rennison
Niels Martin Hansen
TechGeekNZ
Yexo
SamuXarick
Johannes E. Krause
frosch
S. D. Cloudt
Jack Baron
JMcKiern
Henry Wilson