Both Save and Load were recently migrated to block coordinates, see 7ef02a6c0b. The expected behaviour for Save is to extend the particle-oriented rect it gets to the smallest enclosing block-oriented rect and save all blocks inside that rect, but exclude the particles that fall outside the original rect. Using block coordinates made this exclusion impossible.
Since b393050e55, surface normals were calculated incorrectly because blocking cells were detected as blocking only if they were within the heading of the scout process (see that commit for terminology). This had been true even before that commit but it had had less visible effects because both processes would traverse their neighbours in the same order, which the initial heading approximation code (direction_to_map, removed in this commit) had worked better with.
This commit fixes this by separating information about blocking entirely from information about current heading, as it should be. This fixes a few prism-type saves such as id:1188302, but is also not entirely backwards-compatible, for all saves that are considered broken as far as normal calculation code is concerned (e.g. the surfaces are not long enough or are wobbly) will now be broken differently from before. This affects for example many coalescing laser-type saves such as id:482187 that rely on very specific arrangements of very few particles of reflective material behaving as perfect 45deg mirrors.
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.
When PHOT fails to move (do_move or eval_move return "no move"), it looks for
a surface (a contour of boundaries, as reported by is_boundary) along its path
and reflects off (or refracts into, see below) it, using get_normal_interp to
find the point of incidence and get_normal to deduce the surface normal.
get_normal is given the point and angle of incidence, and attempts to traverse
the surface the point belongs to by running two "surface scout" processes.
These processes remember their own position and "heading", a subset of the
eight cardinal directions on the grid. They are initialized with the point of
incidence and a heading that includes all directions whose dot product with
the angle of incidence is non-negative (see direction_to_map). They then
perform a few iterations (SURF_RANGE).
In each iteration, the processes check all eight neighbours of the cell they
are on and select the first neighbouring cell they find that is both a
boundary (as reported by is_boundary) and that is within their heading. They
then move to this neighbouring cell and update their heading by discarding
directions that are not similar enough to (differ by more than 45 degrees
from) the one that took them where they are now (see find_next_boundary). If
they find no such neighbour, they stop.
Continuing the militaristic line of thinking introduced by the term "surface
scout", you can imagine the two processes as two paratroopers who arrive from
above, land on a horizontal surface, and one starts going left, while the
other starts going right. They initially expect the surface they land on to be
close to horizontal, but are also prepared for not too erratic changes in its
angle as they go. Changes too erratic (imagine a precipice) scare them and
force them to stop.
Once the processes finish, an imaginary line segment is drawn between the
cells they ended up on. If the line segment is long enough (estimated by j,
and compared against NORMAL_MIN_EST), get_normal returns a normal that is
perpendicular to it. If it is too short, get_normal gives up and returns
nothing (which results in the PHOT being killed).
This amounts to our paratroopers attempting to get the "lay of the land" by
walking away from where they landed and comparing where they end up. They also
know that if they are still relatively close to each other at the end of their
walk, their measurement is probably wrong and their mission should be aborted.
The bug this commit fixes is that get_normal returns bogus surface normals
when it encounters thin walls of particles, defined as walls exactly two
layers of particles thick. One-layer walls are not really walls, as movement
code allows particles to penetrate these, and three-layer and thicker walls
are too thick for the bug to manifest.
The bug manifests for two-layer walls because the "left" scout process is
drawn to the side of the wall opposite to the one with the point of incidence.
This is because scout processes check neighbours in a clockwise order, and
always select the first suitable neighbour they find. As particles on the
other side of the wall are both boundaries and are within the heading of the
processes, they also qualify as suitable neighbours, so whether a scout
process selects the correct side of the wall depends on the order in which
neighbours are checked.
Essentially, the paratroopers look at their immediate surroundings in a
clockwise order. The right paratrooper always finds the ground and knows where
to step. The left paratrooper finds the Upside Down from Stranger Things and
teleports there.
This bug also affects refraction into and out of thin walls, but since these
walls are thin, the path the PHOT takes inside them is rather short and the
incorrect angle of travel is difficult to see. Furthermore, upon exit, the
same normal deduction bug causes the PHOT to take a path whose angle is almost
identical to that of the path that took it to the wall, so much so that it is
also difficult to see over shorter distances.
The solution is to have the left scout process check neighbours in reverse
order, so that it prefers the right side of the wall over the wrong one. This
does not affect its behaviour when facing thicker walls, but fixes its
behaviour when facing two-layer walls.
The changes in this commit also make find_next_boundary interact with
is_blocking directly to detect a change between the blocking trait of
immediate neighbours. This makes more sense than relying on is_boundary
because find_next_boundary is meant to find a transition from non-blocking to
blocking neighbours within the current heading, rather than to find any
boundary particle. The difference is subtle but important.
Allows finer control over whether you want none included or not.
Fixes some invalid things being allowed for element 0 in legacy lua api
Fixes {ctype} signs showing 0 instead of NONE
Currently only affects the smudge tool. I'd have to look
into the others to decide if they need chaging. They probably
do though, they're not exactly intuitive.
I also fixed a bug with DropDowns where their popup would
show up in some random place if the parent window was a
ScrollPanel, and changed a few alignments here and there.
Notably, DropDowns now align the popup so that the currently
selected item is vertically centered and doesn't move when
the popup is opened.
Update save format to optionally store type as two bits
PIPE now stores element in ctype
Disallow uploading saves using two bytes in type or other fields
update save format to store pmapbits and automatically convert data
Simulation::Restore used to call Simulation::RecalcFreeParticles. The problem with that was that RecalcFreeParticles does more than just what its name suggests: it also decrements life values. Restore shouldn't do that. The solution is to tie decrementing life values to an argument in RecalcFreeParticles. This is also makes to code more future-proof as it lets everyone know that they have to keep their eyes peeled when invoking RecalcFreeParticles.
