I had discovered a set of bugs in the fix he sent me involving when the user decided to move the mouse in the opposite direction. This fixes the bug where the scale would start sliding around.
From Richard: There are a bunch of things I changed...mainly I eliminated all the grid_offset nonsense and instead simply calculate the tick index for the current drag position and use that to generate a snapped position as needed. I still use approx_equal because I want grid numbers to light up even when they aren't the axis you are currently snapping to.
There was a lot of repeated division that was obscuring meaning, along with a variable that was always identical to another preexisting variable. This last was probably an archaism, and was just due for removal.
The highlighting code assumed that the axis of the scaling movement was aligned with the scale tick marks - e.g. one of the cardinal directions with respect to the OBB of the selection. This was and is NOT true when dragging from the corner, aka scaling more than one axis at a time. The solution was to calculate the measured distance by projecting the snapped distance along the snap direction onto the axis of the relevant snap guide. This gives the correct values, and is nice and clean - both in the change involved, and in the values returned.
However, while the fundamental misunderstanding in the code has been cleaned up by this change, the tick_val variable has so much jitter in the bottom end that the is_approx_equal function doesn’t come true > 98% of the time. This is the next problem to solve.
If a marker file indicates that an installer has been downloaded and verified
and is ready to install, but that installer file does not exist, log it and
revert to checking for update.
Also add logging to every code path that can remove the installer explicitly,
in case the missing installer is actually being killed off by some weird
sequence of state-machine transitions.
Ricky Curtice