What changed in EDuke32, build by build

This fixes a bug reported by Micky C on 2016-01-11 where too few points were marked to be inserted. See AMC TC SVN r2308.

Make it always one of the colors that the 2D color cycles to (base color + offset in [0 .. 4]) instead of <base color>-3, as that one might be in a different color ramp.

Currently, this checks for effector sprites that are not face-aligned. See https://forums.duke4.net/topic/8324-icestation-colossus-map-broken

The latter allows one to specify a color to keep, but with r5302 the fillsector() highlights are drawn with transparency, thus making it ineffective. Add an argument to toggle transparency to fillsector() (now fillsector_maybetrans()) and two wrapper functions.

Bug noticed and fix located by The Mechanic.

With 3 modes: 0: auto-correction and warning disabled 1: auto-correction enabled (default, current behavior) 2: auto-correction and warning enabled

I didn't produce a case when this could actually have happened, but reading the code, in the case of variable 'j' it seems possible with an empty map.

That is, in m32_is2d3dmode(), also check if 2d and 3d mode resultions are the same. Otherwise, oob writes (e.g. via tileinfo_doprint()) and other thinkable niceties may ensue.

The winding of a loop -- with clockdir() -- is determined by examining the two line segments spanned between the points following a leftmost point of the loop. If the loop contains a leftmost point that belongs to the "right" side (as can happen with sliding door constructions), there's a chance that an outer loop is misclassified.

Such as "vid_gamma". In that case, setbrightness() would have been called without basepaltableptr having been initialized. The fix is by moving the preparational setbasepaltable() call from ExtPostStartupWindow() to ExtInit(), just before the OSD command dispatching.

This could happen when building outside the "classic" grid limits and would then lead to e.g. incorrect loop assignment on sector splitting. Bug reported by MetHy.

Inspired by http://forums.duke4.net/topic/7506-tror-question/page__view__findpost__p__199151 the corruption checker now checks for certain conditions of the loops of each sector. Recall that CW loops are outer and CCW loops are inner. - If a sector has no or more than one outer loop, count that as corruption (level 4 and 3, respectively). - (Disabled) For sectors with exactly one outer loop, check that all inner ones are inside it. This is currently not compiled due to an asymmetry of loopinside() for degenerate cases, similar to pre-r3898 inside().

Selected by writing e.g. 'corruptcheck tryfix 1-14 ??' in the console. Like with the first alternative, the corruption numbers / range (here, 1-14) must be given.