Cosa è cambiato in EDuke32, build per build

This commit adds a failsafe which corrects the given origin and destination sectnums of the "cansee()" function, by checking if the corresponding (x,y,z) coordinates are actually contained within the given sectors. The problem with TROR in particular was that the calculation done to determine the point of intersection on the TROR layer requires the coordinates to be within the given sectnums. Else, cansee() would simply return 0, even if there was a clear line of sight. This should also implicitly fix any other cases where the coordinates of the cansee() call do not exactly match up with the given sectnums.

And fix problems introduced by 9070cd2bff6d4547f0765fc483ffd4f923e24383.

Also fixes sprite shadows being drawn floating above floor slopes.

The sprite is now properly copied for each sector it stretches across.

- Vertically attached sectors are now added to the clipsectorlist - Entirely remove the previous TROR hack from hitscan() - Instead, hitscan() now also uses clipsectorlist, and detects whether a TROR transition floor or ceiling was hit. If so, any subsequent wall hits in the same sector are skipped. This fixes the following: - Collision and hitscan checks where a sprite stretches vertically across more than 2 TROR layers. - Hitscan shots being unable to clear sloped TROR surfaces. - A potential out-of-bounds array access in hitscan()

Analogous to the previous commit, it also checks the sprites of the upper and lower TROR bunch of the sector. This handles the case where a sprite is intersecting layers, and fixes hitscan shots not hitting enemies properly in such cases.

This makes it so that the sprites of the ceiling and floor bunch sectors of the sector being checked are also iterated over. This handles the case where a sprite is intersecting TROR layers, and fixes projectiles not hitting enemies properly in such cases.

When checking if a point (x,y,z) is contained within a sector, then if x,y is contained, but z is not, it also checks all attached TROR layers. This fixes terminx/eduke32#24

This caused two problems: - The change with AC_FZOFFSET caused BLOODPOOL to jitter in Duke3D - The change with water floors caused various actors to jitter in Fury More trouble than it's worth.

TODO: Polymost

If you made saves since then, loading them will likely scramble your cfg settings, but you should not lose any progress at least.

And apply some cleanup to the code in question.

Risolve

terminx/eduke32#275

Coautore

Evan Ramos

Defer setting kickback_pic setting to lower block. Make adjustments to prevent errant behaviour this may cause.

Behaves like Atomic Edition now. Avoids breaking WW2GI.

This fixes a division by zero crash if zoom == 0.

Risolve

terminx/eduke32#272

Previously, this would be the default selection and say "CVAR"

Risolve

terminx/eduke32#273

These would default to 0 after loading the savegame.

This prevents a visual jitter effect from sprites that aren't moving, but use the "fall" command in a water sector (zombie actors, pickups, etc).

More cleanup to come.

Same fix as applied for Mapster32 in c7aa59b001

Also fix an error log message in engine.cpp logging the wrong variable.

Also fix editor checking for "else" tokens on whilevarl.

Also fixes attempts to read data for sprite no. -1 in case of no parent sprite.

This bug was introduced in 36af1bb2 and caused the subsequent mapster32 linking to fail. The obj dump folder now has "_dump" as suffix. For regular duke3d builds, this temp folder had the name "obj/eduke32", and hence did not conflict with the "obj/duke3d" folder.