They were marked done as far as Libcurl.cpp semantics went, but they weren't noticed by the Worker loop and thus weren't actually marked done with MarkDone.
Broken by 0cc179ae4e where I quietly (i.e. no mention of this in the commit message >_>) replaced curl_multi_wait with curl_multi_poll, the former of which would return after some time even if nothing happened and the latter of which doesn't. Thus, the request manager loop kept iterating, if slowly, and masked this issue: these half-baked requests ended up being noticed in the iteration of the Worker loop that came after the one during which they were marked done.
Also fix the MotD being finalized improperly in Client.
SetLastError will always cause the error to show up in the console. Use tempfile->GetError() instead, which will return the same error message anyway unless the stamp doesn't exist.
It doesn't make much sense for a Lua function to vary depending on whether the user holds shift or not.
This restores the original behavior of includePressure in 6931f35520, which was accidentally removed later in a407aba087. Since I doubt anyone used this parameter, I'll just keep it at position 6 instead of moving it back to 4.
Rather than when the active tool is the property tool. Solves the problem of not being able to sample "away" from the property tool when it's already selected. Also bring up the property window after each such sampling of properties.
These fire just after RenderBegin (read: really early) and just before RenderEnd (read: really late, but before the zoom window is drawn), respectively.
Lua graphics calls now also decide whether they should draw using simulation graphics or user interface graphics based on which event is being handled. This fixes element graphics functions being unable to draw with graphics calls.
This fixes many saves that use 1-px mirrors, for example, id:1077513 id:828603 id:2845200 id:30082
PHOT refraction, which was wildly broken in 97.0, is unchanged, and still works. In Simulation::get_normal, I simply check if REFRACT is set, and if it is, apply the new logic
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.
More precisely, fix reaching the particle limit while pasting onto a sim with no stacking, which shouldn't be possible at all, because pasting removes stacking at any position that has particles, and if the sim doesn't already have stacking, in the worst case we should end up filling the screen, which would use exactly as many particles as the limit allows.
The problem was that the removal of stacking happened after all particles were done being pasted, which meant that the particle limit could be reached halfway into the process. The solution is to remove on demand the particles wherever we're pasting one.
This works because assuming there is no stacking in the sim (this is the only case we care about) and that pmap is up to date (it is, we call RecalcFreeParticles early), then a spot that is being pasted over is either free (and therefore there are also slots free in Simulation::parts) or has exactly one particle, which we remove before creating the one we're pasting.
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.
I was hoping SDL2 would get this functionality eventually, but nope, proper clipboard support is staged for SDL3, which we're not going to see much of for at least a few more months. This will have to do for 98.0. The feature can be disabled at runtime from powder.pref.
Implementation status:
- windows (via winapi): has the most friendly api so of course the implementation is flawless and uses every available optimization >_>
- macos (via cocoa): I'm bad at cocoa so this is only as good as absolutely necessary; TODO: on-demand rendering
- x11 (via xclip): I am NOT implementing icccm2; TODO: remove reliance on external tools
- wayland (via wl-clipboard): oh god wayland oh why, you're almost as bad as x11; TODO: remove reliance on external tools
- android: TODO; is there even a point?
- emscripten: TODO; the tricky bit is that in a browser we can only get clipboard data when the user is giving it to us, so this will require some JS hackery that I'm not mentally prepared for right now; also I think the supported content types are very limited and you can't just define your own
x11 and wayland support are handled by a common backend which delegates clipboard management to xclip-like external programs, such as xclip itself or wl-clipboard, and can load custom command line templates from powder.pref for use with other such programs.
The real fix was made in Simulation::kill_part, where photons[y][x] wasn't cleared when i = 0 because the pmap branch triggered instead. Broken since ff7428fc70, which only partially fixed some related bug. I decided to also fix every other case, even if they are not strictly necessary because they write 0 to pmap/photons anyway.
Reproduce with
sim.loadSave(3062273, 1)
sim.ensureDeterminism(true)
tpt.setfpscap(2)
local function F()
print(sim.framerender(), sim.randomseed())
if sim.framerender() == 0 then
local a = 3498763327
print(sim.hash(), a)
sim.framerender(1200)
sim.reloadSave()
sim.randomseed(a, a + 1, a + 2, a + 3)
tpt.set_pause(0)
end
end
event.register(event.tick, F)
c4dcb37de4 added a kill_part without a return 1.
Reproduce with
sim.loadSave(3062273, 1)
sim.ensureDeterminism(true)
tpt.setfpscap(2)
local function F()
print(sim.framerender(), sim.randomseed())
if sim.framerender() == 0 then
local a = 2247503365
print(sim.hash(), a)
sim.framerender(1200)
sim.reloadSave()
sim.randomseed(a, a + 1, a + 2, a + 3)
tpt.set_pause(0)
end
end
event.register(event.tick, F)
As in, before element properties were populated. This broke everything that depended on can_move, probably most notably particle displacement based on the Weight property. It didn't help that once element properties were populated, any secondary call to init_can_move would fix the symptoms, such as when any custom element is added with Lua.
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.
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.
And a bunch of other member functions. This got rid of some nasty assumptions documented only in the form of comments, in exchange for some nasty template nonsense.
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.
Rather than member function pointers, which are not necessarily simple pointers and are not necessarily convertible to void * sensibly. This also gets rid of the last instance of lua_pushlightuserdata, which apparently isn't super well-supported by luajit, and which thus often crash on android.
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
Thus dropping the minimum required libcurl version to at least 7.64, possibly further. We have compatibility macros all the way to 7.55 so yeah.
Also fix RequestManagerImpl::~RequestManagerImpl not doing a wakeup after setting running = false. This meant that in the worst case the worker would wake up 1000ms later and only then notice running = false and exit, making the game take overall longer to exit.
That is, in some cases (read: starcatcher, which uses the very last component of the user agent to determine the build ID), you'd get all changelog entries ever, not only the ones between the current version and the one the update server has.
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.
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.
This looks slightly nicer on very pixel-dense screens (scale factors 5 and up) than nearest neighbour fractional upscaling does.
Also fix window icon disappearing at times and the window being resized after configuration changes.
We should maybe start preserving window size also at some point, the way we do position now.
By not using SDL_RenderLogicalToWindow if it's not available.
Because of course ubuntu 20.04 has sdl 2.0.10, which of course doesn't yet have SDL_RenderLogicalToWindow which was added in 2.0.18, which is of course needed because of course SDL_SetTextInputRect takes window coordinates rather than logical coordinates. At least official static linux builds are not affected because tpt-libs uses much newer sdl.
Namely when the main window is resizeable and its size isn't the same as it would be with the active scale mode with resizing disabled.
Also fix window position not being restored when the main window is resizeable.
By zero-initializing pointers in OptionsView so they don't crash when they don't get initialized, which up until very recently they always had. In the cases of the emscripten and android ports, certain components are never created.
Another rat's nest; I'm still not entirely satisfied.
This introduces "frame personalities": one for embedded frames (emscripten), one for handheld devices and everything else that doesn't really work with windows (android), and one for everything else. For now these affect which frame options are configurable by the user and what values they are forced to take if they are not configurable, and whether optimal scale is guessed based on screen size.
Also introduce a future TouchUI config node to allow switching between normal and touch-optimized UI on android. Again, because chromebooks and other android devices with mouse and keyboard support are a thing.
Also enable debugging of debug builds of android. It took me hours to attach a stupid debugger to the process; see:
- https://www.sh-zam.com/2019/05/debugging-krita-on-android.html
- https://source.android.com/docs/core/tests/debug/gdb#app-startup
I also had to adb forward the port that lldb was supposedly talking to lldb-server over because otherwise it wouldn't attach; I don't get it either.
