A DestinationID is either a DepotID or StationID, where the aircraft hangar
being conceptually a depot is actually a StationID. When making those types
stronger, a lot of casts would need to be added, but this shows the intent
much better.
This allows cargo packets and cargo flow data to be empty if not in use, which is the case for the majority of station goods entries, and data is allocated when needed.
This reduces the initial size of a Station from 9192 bytes to 2024 bytes (on 64 bit platforms), although an allocation of 120 bytes is made for each active cargo type at a station.
Based on similar changes in JGRPP.
Rail station tile flags now use bits that were (long ago) used to store railtype.
During Afterload, there are some calls that need the state of station tile flags to be correct which were executed before the station tile flags were set.
* Codechange: Add AssignBit function to assign the value of a single bit
* Codechange: Replace various uses of SB with AssignBit
* Codechange: Replace various uses of SB with a constant with SetBit
Standardises how the class index is stored in the spec, instead of relying ot the Spec structs having the same members.
This allows retrieving class_index and index without searching or using pointer arithmetic.
'cls_id' is renamed to 'class_index' to make it clearer that it is an index rather than the multichar label of the class.
During b0e73277 we removed loaded_at_xy, but I kinda forgot that
it was a union with next_station. Now next_station wasn't copied
anymore, or checked in AreMergable.
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.
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.
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.
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.
