Cosa è cambiato in EDuke32, build per build

This fixes a problem where the texcache file could grow without limit if something managed to corrupt the texcache index.

Annoyingly, these functions are spelt differently on different OSes.

strerror_r has been available since FreeBSD 4.4 and OpenBSD 3.3 (both many years ago).

I see now that Todd was actually very wise.

Some TROR layers were blocking hitscan shots because of the low limit.

* clipmove() - No longer traverses sectors once a distance limit is exceeded, and at most traverses 64 TROR sectors at once. * hitscan() - TROR sectors added to clipsectlist after regular next sectors. Only adds TROR sectors in a single direction, and at most 64 at once. * A_RadiusDamage - only add TROR sectors if inside damage radius. Also increase MAXDAMAGESECTORS to 512, same as MAXCLIPSECTORS. Fixes glitches and error spam in maps that make heavy use of TROR.

The instruction pointer wasn't being updated properly.

This would previously attempt invalid array access with index -1.

If the sector contains a TROR bunch, then whenever clipupdatesector() would normally return 1, instead run updatesector() and return 0 instead. The old approach did not work out in all situations. In Fury, certain flying enemies could not pass some TROR layers properly, and in AMC, trying to submerge in TROR water had the player glitch out on the surface. This exact approach had previously been used in AMC without any major issues for 2 years, before the recent TROR changes.

The problem with the previous version was that it didn't take overlapping geometry into account. This should be a more conservative approach that doesn't affect non-TROR uses of the cansee() function.

Invalid sectnums could previously be added to the clipsectlist if a hitscan shot passed a tror layer.

Squishing is now prevented if SE7 is present (as previously intended), or when the actor is standing on submergible TROR water.

Risolve

terminx/eduke32#283

This resolves a bug in Duke3D where the player couldn't move while shrunk if a TROR sector was present on the map. It also ensures that the original clipping is used if no TROR bunch is present inside the sector in question. This should reduce the amount of backwards-compatibility problems.

The changes are now more conservative and only affect sprites on TROR layers.

- Add TROR-awareness in similar fashion to clipmove() and hitscan() - Continue scanning walls to damage even if MAXDAMAGESECTORS is reached - Increase MAXDAMAGESECTORS from 128 to 256

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.