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.
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.
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.
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.
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.
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.
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.
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.
This change is a controlled by a game setting, located under Environment ->
Industries which allows toggling the behaviour. It defaults to enabled.
"Company stations can serve industries with attached neutral stations"
When enabled, industries with attached neutral station (such as Oil Rigs) may
also be served by company-owned stations built nearby. This is the traditional
behaviour.
When disabled, these industries may only be served by their neutral station.
Any nearby company-owned stations won't be able to serve them, nor will the
neutral station serve anything else other than the industry.
Introduce a new default algorithm for town cargo generation (passengers and mail), and a game setting to choose between the new and original algorithm.
The original town cargo generation algorithm has the property of the generated amount relating to the square of each building's population, meaning large towns easily produce more cargo than can realistically be transported. The problem is excessive cargo is amplified if playing with cargodist.
The new algorithm introduced instead has a linear relation to the population. The result is that smaller towns will produce slightly more cargo, while the largest towns will produce about a fourth of what they would with the original algorithm.
Existing savegames will use the original algorithm, while new games will default to the new algorithm.
