These were arrays because that made them easy to compose, but that's a UI task, it makes no sense to propagate them internally. That said, RenderView is still confusing because it still has checkboxes that control multiple bits of render mode and display mode at once; I'm not dealing with that for now.
The game now prefers the item-type preferences Renderer.RenderMode and Renderer.DisplayMode over the array-type preferences Renderer.RenderModes and Renderer.DisplayModes. It'll preserve the old ones for compatibility if found and derive the new ones from them. The corresponding Lua functions are now deprecated and will just return single-item arrays from now; the similarly named replacements operate with integers.
More precisely, move them to RenderableSimulation, which Simulation now inherits from. This type is copyable and so is easy to send off to be rendered, potentially on a different thread.
Simulations as big as 2048 by 2048 had been possible, but this change enables sizes such as 1900 by 2100, which would have failed the originally very power-of-2-oriented check. Very useful, no doubt.
Also make the tags button span the entire window, fixing the annoying gap or overlap with other buttons when changing the sim size.
I had been under the impression that .data() on containers returns a const pointer and so hadn't been using it too much. I was wrong; I think that may be limited to std::basic_string. EDIT: I've checked, even std::basic_string has a non-const .data() since C++17, nice.
I got the escaping wrong so on windows, where the path to the script has characters that need to be escaped, the script wouldn't be found, leaving all dependents stale, triggering rebuilds of all resources.
This causes these dependencies to be rebuilt if the script chanages, which is heaps better than having to remember to clean the build directory every time.
So they get copied into the build site even if you invoke only the powder build target, rather than all build targets by not specifying one. Case in point:
meson compile
vs
meson compile powder
wherein the latter will build powder.exe but will not copy the dlls into the build site, which are required by powder.exe.
It's getting triggered because the lifetime of some objects that own RequestHandles are not exactly deterministic, to put it lightly. I'm not dealing with those.
Timing is now such that the input to the gravity process (the point masses and the mask derived from gravity walls) is passed in BeforeSim and the output of the gravity process (the 2D force field) is taken also in BeforeSim, at the same time. This means that input generated by particles in frame n is passed to the gravity process at the beginning of frame n+1, the corresponding output is available by the beginning of frame n+2, and so it is visible to particles in frame n+2. Thus, gravity is now properly and predictably one frame late, though, sadly, it's displayed two frames late.
This is in contrast with the case of not being late at all, which would be the case if input generated in frame n produced visible output by frame n+1, and also in contrast with what we've had until now, which was that gravity was *at least* one frame late, but it could be more out of sync than that if the gravity process for some reason took more time to produce output.
Further, both input and output now make it into snapshots and saves, which fixes one half of what causes the phenomenon wherein beams of PHOT under the effect of gravity wiggle for a few frames before stabilizing after a save is loaded. The other half is that velocities are saved at very a low precision, so overall, the effect of this change on this phenomenon is negligible.
It is not crucial that a client understands this new piece of info, as clients have been fine not getting gravity data from saves for years. Thus, its presence does not restrict the save to client versions newer than the one that adds this feature.
An interesting question this brings up is whether settings, crucially, the enabled state of Newtonian gravity, should be considered simulation state and be also included in saves.
Gravity data is now also included in the output of sim.hash, so Newtonian gravity no longer has to be disabled in order to ensure local determinism.
The diff is large because I gave up on being non-invasive and renamed important structures that lots of elements use. gravp, which was functionally just hypot(gravx, gravy), was removed, because it was only ever used to display a single value in the HUD. I've also taken a few detours and made changes that really should have been in separate commits, see below, but oh well.
This commit also includes a complete rework of the gravity wall area of effect discovery algorithm. The old implementation was extremely broken even beyond the usual C99-isms.
Also fix Simulation.NewtonianGravity being read as an integer from powder.pref, even though it's a boolean and is in fact saved as a boolean. It's pure luck that it's worked fine until now.
Also introduce PlaneBase for use with PlaneAdapter. PlaneBase is a very budget version of std::span from C++20, so budget in fact that it doesn't even store span size; this is fine because PlaneAdapter knows the span size anyway. std::basic_string_view worked for char types but this new code deals with floats.
Also include blockAir data in saves unconditionally. It used to be included only if ensureDeterminism was enabled, like rngState and frameCount, but those last two are conditionally included only because some assumptions are broken if they are included, such as that of expecting a saved simulation to take different paths of evolution after each reload. blockAir has no such effect.
Also remove sim.resetGravityField aka tpt.reset_gravity_field because it was agreed that it's really weird that the output of the gravity process can be changed at all from Lua, not to mention that it can only be reset to zero. No scripts to my knowledge ever used these functions.
This is already a fairly obscure part of the codebase, and that NT and ST are only used in element files but not where *Transition properties are processed really doesn't help. This change makes usage of these constants easier to search for. Sadly, this doesn't help the case of IPL, IPH, ITL, ITH, whose handling is still implicit. I dared not rework the code to check for them explicitly because eww, floats.
The lambdas were originally there to allow for different ways to determine whether the version offered by the website is indeed an update. The lambdas became identical in a9cbd784f7 however, which is when this change should have been made.
The separation from the server variables doesn't really serve any purpose other than making it require very conscious effort to accidentally start connecting over plain http, but we already have enforce_https for this purpose. Beyond that, it just makes prototyping with a local server really annoying.
It somehow never got the upgrade where a drawing primitive looks at the current event context and chooses a graphics backend based on it. All the others primitive got it in c5b72b213b.
- Fix error when submitting comments being ignored, meaning you'd only know if your comment got rejected if your comment wasn't there after the comments refreshed
- Fix issue in Request::ParseResponse where "Could not read response" is always included on all website errors
- Add ability to refresh comments by clicking the Submit button with an empty textbox
The assumption was introduced by 7e674a887d, where find_program('python') was used instead of Meson's built-in python discovery services. This turned out to be a bad idea because of course there are systems in 2024 where python is not python 3.
[10:44 AM] jacob1: You're still credited that way in-game, should it be changed?
[10:44 AM] Pilihp64: I guess so, I think my github is actually Pilihp64 as well
May fix pipeline failures on ghactions where makeico or toarray just exit with a non-zero status for no reason.
Also makes it easier (possible, rather) to build TPT using a cross-compiling msvc toolchain on windows; you can't have two different msvc toolchains in PATH on windows because of course you can't.
toarray had been python before, maybe I converted it to cpp to avoid pulling in python as a dependency, I'm not sure. With android vanilla development (hopefully) gaining traction soon, we'll be relying anyway on helper scripts I've written in python, so python will be a dependency sooner or later. Meson implicitly makes python a dependency, but there could be Meson implementations out there that don't rely on python, who knows.
