There had never been a legit use of tpt.beginGetScript (or indeed, tpt.getscript) that didn't involve the exact parameters 1, "autorun.lua", 1. The most infamous alternative parametrization was 2, "autorun.lua", 1, which would install TPTMP where you'd normally install the script manager. Absolute madness.
The callback parameter also goes away with this change, because no other script needs to know when the script manager is done being installed. I also fixed a problem where the function might be called from the wrong context and thus get delayed in handling the completion of the HTTP request. With the earlier removal of checking for existing destination files and bailing out if found, this function is now bullet-proof(tm).
This restores the tpt.getscript(1, "autorun.lua", 1) usage pattern, albeit only from the console.
It's not worth the trouble to ask questions (this was the old behaviour), the next best thing (in terms of preserving old behaviour) is to overwrite unconditionally. There is no situation in which the file name would be specified but the user wouldn't want the file to be written to.
A sim event being an event that takes place in the context of the simulation. Currently, this simply means that the RNG math.random uses is the sim's rather than the UI's.
SaveRenderers populate their own Simulation with Simulation::Load, which may call various callbacks now that these SaveRenderers know about custom elements. Make sure these callbacks don't try to call into the main thread's Lua state.
Seeing as these callbacks now need to be protected from races too, the scopes of some of the exclusive locks of the graphics property mutex needed to be extended.
Mostly. They are now const but only in graphics functions called from secondary Renderers. The primary (main thread) Renderer still allows graphics functions to mutate Simulation; this is required for correct in-PIPE rendering of custom elements.
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.
This causes a crash when using luajit on aarch64 Android builds. I didn't remove the lua_pushlightuserdata usage in LuaLuna.h because that's external code and beyond my understanding
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.
Mainly the new ones I added >_> Don't use lua_pcall, kids. tpt_lua_pcall records when control flow was "last seen" on the C++ side, so you have to call it rather than just lua_pcall if you want to avoid timeout ("script not responding") errors.
For the record, I had a really hard time reproducing these errors. I had to tune the timeout to such a low value that the errors might as well have not been spurious, i.e. not much could have been done in such a short period of time anyway, bugs or no bugs.
The problem is that Engine outlives GameController and thus also LuaScriptInterface. The solution is to not try to access LSI's lua_State if it doesn't exist; this is the case in Engine's dtor.
This is ugly as hell and the root of the problem is the cursed ownership model of LuaComponents and Windows by Engine, which I don't think I'll be fixing any time soon.
Notable changes:
- tpt.{input,throw_error,message_box,confirm} have been superseded by ui.begin{Input,ThrowError,MessageBox,Confirm}, each with an extra callback argument and no blocking behaviour, but otherwise the same semantics as their predecessors.
- The "script not responding" error doesn't wait for user confirmation anymore, it fires without asking. Future exercise: maybe let the user configure the timeout.
- Remove the confirmPrompt argument of tpt.getscript; this also means it unconditionally fails if the destination file exists.
Not useful anymore, it can only fail if the GameSave passed in is nullptr, which this commit guards against.
Also make Simulation::Load and Simulation::Save take block-oriented positions and rects.
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.
