That is, undo the decoupling of the effective save version from what is today the upstream display version done in 7fc3fb4c15. This enables taking advantage of new features, for example the comprehensive palette, in saves that do come with a comprehensive palette, which is a 98.0-and-above feature.
Also fully populate GameSave::version before making checks against it and fix GameSave::fromNewerVersion reflecting the relationship between only the major components of version numbers.
Newer saves include an element palette which maps save-space element numbers to element identifier strings, see 29189693b3. This is useful because the numbers of custom elements can change, while their identifiers are expected to not change. Not all elements make it into the palette, only the ones that are in use in the save.
98.0 is staged to extend this feature in two ways. First, it'll warn the user of missing custom elements when loading a save that uses such elements, see 36800a76cd. Second, it'll do a better job of deciding what to put in the element palette, see a13c29875f.
In order for detection of missing elements to work, a save's palette has to account for every element number used in the save, including built-in elements. To dispel a misunderstanding regarding that last part: yes, including built-in elements is not crucial if the set of built-in elements only ever grows, but this is not guaranteed.
98.0 creates such palettes, but older code didn't, for various reasons. One reason is that the palette at some point wasn't meant to include built-in elements, see e0d982367b, although this was rectified later in 67b87b1dab. Another reason is that not all cases of element numbers encoded in particle properties were considered, see for example f45d0d1683 and 1f1062408c.
Palettes in existing saves being thus incomplete didn't use to be a problem because older code would just assume that whatever element number wasn't listed in the palette referred to a built-in element and would just map such save-space element numbers to the same simulation-space element number, hence identity mapping.
However, this approach doesn't cover custom elements whose numbers can change, nor does it cover extra built-in elements added by a mod. Worse, a different mod with different extra built-in elements may map save-space element numbers not listed in the palette to its own extra elements.
As a solution to these problems and making use of the fact that palettes are now complete and comprehensive, 98.0 no longer does this default identity mapping, see 73be29aa61. Removing this identity mapping in itself would have broken older saves that use the old identifiers of some elements; that commit works around that by remapping these early in the loading process. By the way, these changes in identifiers are perfect examples of the set of built-in elements changing in ways other than growing.
This still doesn't address the problem in the case of pre-98.0 saves though. Such saves have seemingly valid element numbers (although it's impossible to tell whether these refer to built-in elements from vanilla or extra built-in elements from a mod) but no corresponding entry in their palettes. The user is warned about such elements also, see 9f8449357f. Lacking a better solution, this commit assumes that these elements are indeed vanilla elements and re-enables the default identity mapping for such saves.
In summary, this commit fixes the loading process for saves that were made in 97.0 or some older version and use built-in vanilla elements in ways that didn't trigger their inclusion in the element palette.
For example, until a13c29875f, CONV's tmp was not considered by the palette code, so any CONV with tmp set to an element that wasn't a built-in vanilla element, and which also wasn't used anywhere else in the save, would have been potentially corrupted by the loading process. An example a save that demonstrates this behaviour is id:2633868, which has CRAY particles on the right with ctype set to LIGH, but until this commit, these ctypes would have been set to 0 and the user would have been warned about element number 87 (LIGH) missing from the palette.
By factoring element and other static-ish data out of Simulation and protecting basic graphical element properties (i.e. everything that contributes to graphics other than the Graphics callback) with an std::shared_mutex. This is taken exclusively (std::unique_lock) by the main thread when it changes these properties, and inclusively (std::shared_lock) by non-main-thread code that uses Renderer.
The idea is to have the following version information included:
- 1-component save version
- 2-component under the hood but the minor component shouldn't ever change again
- see currentVersionMajor in GameSave.cpp
- 1-component website API version
- again, currently 2-component because that's what the website code expects
- see apiVersion in requestmanager/Common.cpp
- 2-component display version, entirely cosmetic
- exposed as meson options display_version_major and display_version_minor
- see APP_VERSION in Config.template.h
- 1-component business logic version aka build number
- exposed as meson option build_num
- see APP_VERSION in Config.template.h
- variant id aka mod id, tightly coupled with the build number
- exposed as meson option mod_id
- see MOD_ID in Config.template.h
- display and business logic versions repeated for the upstream
- exposed as meson options upstream_version_major, upstream_version_minor, and upstream_build_num
- we'll have to update these alongside display_version_major, display_version_minor, and build_num, but mod owners can just merge our changes
- see UPSTREAM_VERSION in Config.template.h
- update channel, makes sense in the context of the variant (and yes, this would later enable mod snapshots)
- currently not exposed as a meson option but derived from meson options snapshot and mod_id
- see IDENT_RELTYPE in Config.template.h
- vcs tag aka git commit hash
- set by build.sh in ghactions workflows
- see VCS_TAG in VcsTag.tempalte.h
Rather importantly, the save and website API versions are now allowed to change independently of the display version.
These changes also allowed me to remove the ugly sed hacks in build.sh used to provision some manifest files; they are now provisioned by meson.
Also add version info for windows and android.
For this to work, loading code needed to stop trusting DEFAULT_PT_ identifiers, which it trusted because there have been some identifier changes between vanilla releases. I dug these up and listed them explicitly; they are now taken into account as needed when loading old enough saves.
Saving blockair/blockairh is nice because RecalculateBlockAirMaps uses the sim rng, which means the sim rng would get advanced in Simulation::Load. Also rename RecalculateBlockAirMaps to ApproximateBlockAirMaps because that's what it is, an approximation, and it's needed only if there are no block air maps in the save.
Simulation::frameCount keeps track of frames elapsed since the beginning of the simulation, zeroed at clear_sim. It overflows when it reaches the 64-bit limit, which means anything that depends on it should either handle this, or not fail catastrophically. sandcolour (the only thing that depends on it as of now) is a good example of the latter: sandcolour has a periodicity of 360 frames, which means that there is one sandcolour period that is cut short by the overflow. This is not "handled" (the period is cut short, which is detectable by users) but is not catastrophic either (it's not a big deal, and it won't ever happen unless someone hacks the save).
Also restrict saves with determinism data to 98.0.
Achieved by adding a new element property called CarriesTypeIn, whose bits signal to save loading code which properties of particles of the element class in question carry element IDs. The bits in this property are numbered the same way as sim.FIELD_* constants for consistency. One would signal from Lua that a custom element carries element IDs in its tmp like this:
elem.property(id, "CarriesTypeIn", 2 ^ sim.FIELD_TMP)
"Carrying an element ID in a property" is to be interpreted as follows: the property is treated as a combination of a PMAPBITS-bit (so, currently 9-bit) unsigned integer lower part holding an element ID and a 32-PMAPBITS-bit (so, currently 23-bit) signed integer upper part holding whatever makes sense for the element. CONV, for example, uses this signed integer in its ctype as the extra "v" parameter for particle creation.
Some operator[]s that know the size of the container they wrap like to assert(index >= 0 && index < size), which is bad for us because we sometimes use &container[size]. This is not undefined behaviour until that pointer is dereferenced, but certain operator[]s choose to ignore this fact and err on the side of caution. The solution is to use &container[0] + size instead of &container[size].
I took extra care to not mess up signedness in readOPS in ab600780d0, but apparently didn't do the same in readPSv.
Also fix a bound check that was broken since aac6b7258c. It's a good thing this was broken, because this allowed negative type values from broken signedness readPSv to get past and cause a crash later on, rather than just cause particles to disappear or something.
Namely:
- get rid of unsafe memory management;
- use vectors / Planes everywhere;
- return a vector from serialization functions;
- have read functions take a vector;
- improve constness;
- hide a few implementation details from GameSave.h;
- get rid of GameSave copy constructor;
- better member initialization;
- use the slightly more C++-looking BZ2 wrappers.
The BSON library still takes ownership of the data it parses, and GameSave
ownership is still a joke. Those will need to be fixed later.
... and everything built around them.
A GameSave would hold at least one but sometimes two representations of a save:
one serialized, and one "friendly", accessible for modification. Thus, a
GameSave would have three states:
- "Collapsed": only the serialized representation was present; this was the
initial state of GameSaves loaded from files;
- "Expanded With Data": both the serialized and the friendly representations
were present; this was the state of GameSaves loaded from files after a call
to Expand;
- "Expanded Without Data": only the friendly representation was present; this
was the initial state of GameSaves being prepared for being saved to files.
A GameSave would be able to go from Collapsed to Expanded With Data with a call
to Expand, and back with a call to Collapse. Of course, this latter transition
would discard any changes made to the friendly representation, for example with
Translate. A GameSave would however be unable to go from Expanded Without Data
to any other state; a call to Collapse in this state would have been a no-op.
There were two instances of Collapse being called, one in the GameSave
constructor taking the serialized representation, immediately after a call to
Expand, and another in SaveRenderer, which would Collapse a save "back down" if
it had originally been Collapsed. Now, consider that there reasons for
constructing a GameSave from the serialized representation are as follows:
- loading an online save at startup from the command line;
- loading a local save at startup from the command line;
- loading a local save when it is dropped into the window;
- loading a local save for placement of the most recently used stamp;
- loading a local save for stamp placement via Lua;
- loading an online save for preview generation while browsing;
- loading a local save in the stamp browser for thumbnail generation;
- loading a local save in the local save browser for thumbnail generation.
In some cases, the friendly representation is needed for thumbnail generation
by ThumbnailRendererTask. ThumbnailRendererTask operates on its own copy of the
GameSave, because it runs SaveRenderer on a thread different from the main one
and cannot be sure of the lifetime of the original GameSave. It destroys this
copy when it is done rendering, so the call SaveRenderer makes to Collapse is
pointless.
In all other cases, the friendly representation is needed immediately. In some
of these, SaveRenderer is used from the main thread, but since the friendly
representation of the GameSave will be needed for pasting anyway, the call
SaveRenderer makes to Collapse is pointless again.
So, Collapse goes away. This also means that it is pointless for GameSaves to
hold on to the serialized representation, since in all cases in which they have
access to it, the friendly representation is needed immediately, and with
Collapse gone, they will never need it again.
Also Disallow linking against non-C++ system Lua, unless configuring with -Dworkaround_noncpp_lua=true, add -Dworkaround_elusive_bzip2 and friends, and get rid of the -image_base hack for macos.
This made it possible to get rid of two GameSave constructors.
Also clean up Client::LoadSaveFile, Client::ReadFile, and Client::WriteFile in the process, and remove unused SaveRenderer::Render
Also restructure meson.build and the ghactions workflow a bit, and enable -ffunction-sections and -fdata-sections.
Note that starcatcher uploads have not been tested and most likely don't work.
Empty stamps are those whose block width or height is 0. While they are technically valid and certain parts of the game are prepared to handle them, others aren't, so it's safest to just adjust the definition of valid stamps to exclude empty ones.
Repurposing the comment I added because I'm lazy: pavg[1] used to be saved as a u16, which PressureInTmp3 elements then treated as an i16. tmp3 is now saved as a u32, or as a u16 if it's small enough. PressureInTmp3 elements will never use the upper 16 bits, and should still treat the lower 16 bits as an i16, so they need sign extension.
The code that was originally responsible for this somehow got lost in the tmp3/tmp4 migration.
Also add GameSave::PressureInTmp3 to check for elements with pressure memory and fix TUNG not sampling pressure on creation. This does not in itself fix#822 because tmp3 and tmp4 are still saved in 16 bits each, so full ctypes still don't fit in tmp3.
