What changed in EDuke32, build by build

Using non-keypad [-]/[+] or LMB + mousewheel, it was broken when a void tile was in between.

Specifically, if the first wall of the sector-to-split is to the left or right of the *start* of the splitting line AND the sector has no TROR extensions, make these two the new nextwalls of the respective split sectors.

This is done by pressing LShift and - holding down the left mouse button for scaling, or - the right mouse button for rotating the highlighted walls/sprites with respect to a pivot point determined as the center of the bounding box of all highlighted points. Note that scaling sectors isn't that easy and the current functionality is very rudimentary: there's no z scaling, no xrepeat correction, and sprites aren't touched expect for their position. The user is responsible to maintain map consistency, for example to prevent wall-lines of the same sector crossing each other.

This fixes a bug where it's not possible to split a sector under certain circumstances, reported by Micky C here: http://forums.duke4.net/topic/1348-mapster32-problems-and-bugs/page__view__findpost__p__138380 Also, don't allow zero in various 'F functions: Resize selection and Global {shade, visibility} divide.

When LShift is pressed and the mouse is over a linking sprite (as determined by the tag labeling system), lines are drawn to all other sprites, and pressing [ or ] will cycle these then. False positives and missed sprites are possible. Additional changes: - consider SE 31 and 32's lotag to NOT be linking, since the ACTIVATOR is what matters. The original maps are inconsistent there. - When pressing Alt+[ or Alt+] and there are no corruptions, say so instead of doing [ or ].

Instead of having 'noalreadyrefd' as a 'corruptcheck' subcommand. This way, TAB completion can be had.

Requested auto-correction will place such sprites at their sector's first point.

This is really an artifact of overloading the sector fields for different uses. For copy-pasting TROR'd portions, the bug still persists.

Because rotating sectors "smoothly" by 1 BUILD ang will quickly accumulate roundoff error, this lets the user first do that as a preview and then use the manual angle rotation do carry it out for real.

This was actually broken all the time except when ALL sectors were selected (which was what I tested incidentally when I wrote the first "fix"). D'oh!

This was exposed by Clang with -ftrapv, which apparently also traps those.

Usage is from 3D mode only. When a sector (or wall) is committed to the clipboard, it (or the wall's sector) is saved, and is subsequently used when auto-aligning [;-ENTER] another sector's ceiling or floor against the reference one's. This temp. sector is reset on any structurally modifying operation except setting first walls; also, aligning extended ceilings or floors is impossible as they use .*xrepeat internally. The auto-alignment does not change picnums (this can be accomplished with the ['+ENTER] combination), but copies the orientation bits 2^{2..6} to the alignee. Afterwards, if the reference is relative-aligned, it tweaks them, so that every case where the two firstwalls are either parallel or perpendi- cular is handled correctly. It does not yet calculate the panning values.

Also factor out the code (2x) setting the alignment bits for sprites.

We were writing into a string literal. Ouch!

This checks for about every possible type of sprite list corruption and reports back with a corruption level 5 if one of the 14 validations fail.

The reason was that drawmasks(), which was where the resetting of the fake RoR textures happened under Polymer, can be called from polymer_displayrooms() when mirrors are present. I was assuming that drawmasks() was only ever called after the 'main' drawrooms and that hence the sequence of fake RoR tile tweaking was set, reset, set, reset, ... which it was not. Now, do the resetting explicitly after every drawmasks() in the editor.

The implementation uses the recently introduced updatesector_onlynextwall when setspritez fails.