What changed in EDuke32, build by build

Previously, that was the case only with DRONE and COMMANDER. This makes non-falling enemies pass properly through TROR bunches.

Also, some minor stylistic cleanup.

- Add declarations of C functions to defs.ilua, names to dynsymlist, fix typo in con_lang.lua, ffi.string() calls in control.lua - Assert that G_LastMapInfoIndex() is always called with ud.last_level >= 1. (A stricter requirement than necessary to prevent follow-up oob accesses, but logically the most meaningful.) - In G_PrintParTime() and G_PrintDesignerTime(), return "<invalid>" if the above does not hold. This can happen from EVENT_NEWGAME, for example. Add a test to lunatic/test/qgetsysstr.con. DONT_BUILD.

Since TILE_TILT is only allocated once, it must be done with the maximum possible size.

Exposed by Valgrind. DONT_BUILD.

This fixes the out-of-bounds read of former g_player[] in VM_EventCommon_().

By default, the following enemies have this flag set: OCTABRAIN, COMMANDER, DRONE. DONT_BUILD.

This is where things are changed at last. This fixes lizmen walking on water.

Factor out condition for whether a z offset is added or not ("fix for flying/jumping monsters getting stuck in water", etc.) into a function A_GetWaterZOffset() (and a helper A_GetVerticalVel()).

In VM_Fall(), keep a temp preliminary new z position of the actor and assign only when we return. This is to each ease watching its value in GDB. DONT_BUILD.

This makes sure that the engine arrays have sufficient space allocated for usage in Mapster32's 2D mode, for example from drawmapview().

- t{sector,wall}type are simply typedef'd to the non-t versions - make FORCE_INLINE unconditional of DISABLE_INLINING (otherwise there are multiple definitions of these functions) - update lunatic/doc/lpeg-lunatic.patch to apply against the LPeg 0.12 I just downloaded

In setview(), we now assert windowx2 < xdim. The only calling places where its non-violation is non-trivial to ascertain are (1) showview from CON and (2) draw-to-tile for look-sideways in game.c. AFAICS case 1 should be fine. Case 2 is adapted; see comments there.

By setting DISTRECIPSIZ to 131072, as far as I can see the absolute maximum that's possible with the integer scaling convention of the voxel drawing code. BUILD_LUNATIC.

- Work around a sequencing issue (assignment of searchstat) in M32_DrawRoomsAndMasks() - When having sprites highlighted and changing shade, since r1943 change every highlighted sprite's shade if one of them is aimed at. With this revision, if SHIFT is pressed while doing that, only change the aimed at sprite's shade - a.m32: Use 'break' from a state instead of 'return'. The former may be "sticky" in a way that is not intended. Needs to be debugged later. - Update instructions in m32script_ex.map DONT_BUILD.

DONT_BUILD.

Also for polymost_scansector(). These were likely of little consequence because collection in scansector() is the exception than the rule (see added comments), and because the redundant drawwalls() would find the x range done the second and following times. Also, add a bound check for sectorborder[] (the limit was probably rarely hit in practice, but the check is mandatory nontheless) and add functions printscans() and printbunches() in the DEBUGGINGAIDS=2 build.

There were various issues with that code. - It does not seem to be very meaningful to do so. - It was carried out on the same range as the sprites sorted by z coordinate (those with equal x/y) just a few lines away, effectively overriding it. The former is very meaningful, though. - It led to inconsistencies between editor and game, see http://forums.duke4.net/topic/775-eduke32-20-and-polymer/page__view__findpost__p__214873

- factor out calculation of player-relative and screen+clipped-player-relative coordinates into get_rel_coords() and get_screen_coords(), respectively - the usual beautification stuff, especially since we're now on C99

Previously, the C function clipmove() returned negative values when hit a wall (32768+wallnum) or sprite (49152+spritenum) because internally, these values were encoded into a *signed* 16-bit integer. This made no difference to C code using it, since it always proceeded by bit checks, but was inconsistent with documentation on CON 'clipmove' on the wiki. The following commands are affected too, since they use the value returned by clipmove(): 'clipmovenoslide', 'movesprite'. Also, the value of actor[].movflag ('htmovflag' from CON). Also, fix 'clipmove*' in LunaCON and add lunatic/test/checknearwall.con as an example of how to implement a being-close-to-a-wall checker as requested in http://forums.duke4.net/topic/7869-determining-closeness-to-a-wall/

Introduced in r3207. Oops.

This may happen if no title/end music is defined from CON. Thanks to Zaxtor for the bug report.

In A_RadiusDamage(). The code snippet that is disabled for such actors increases the damaged actor's .xvel by (4 times the) damage amount and is responsible for the strange effect of enemies becoming faster TOWARDS the player on being hit with an RPG frontally. Thanks to Fox for a keen eye.

DONT_BUILD.

The one introduced with r4569.

That is, make interpolation work properly there -- both when 'using' a VIEWSCREEN and when rendering the scene onto a TILE_VIEWSCR. This makes a difference only if the camera is in a moving sector.

- At a given time, at most one viewscreen may display TILE_VIEWSCR, namely that one which is g_curViewscreen - sync kinds of distance to compare against VIEWSCREEN_ACTIVE_DISTANCE (was Manhattan vs. dist(), now both the latter) - fix resetting to VIEWSCREEN tile when player is greater from it than that distance. When the player is closer to it again, it is *not* reset to TILE_VIEWSCR. - more sync'd g_curViewscreen and sprite[i].yvel (for 'i' being the viewscreen sprite) Note: in a multiplayer context, this needs to be thought about once more.

These will be bitwise-OR'd.

Fixes bug reported here: http://forums.duke4.net/topic/1348-mapster32-problems-and-bugs/page__view__findpost__p__213759

The only semantic change is that an out-of-sync instance of a distance to check (viewscreen sprite <-> player sprite) is changed in actors.c:G_MoveStandables(), from 2048 (as in Duke3D 1.5) to 8192, now represented by the define VIEWSCREEN_ACTIVE_DISTANCE. I have not yet observed any change in behavior regarding this change (but there ought to be one). Also, in DNCOORDS display, print 'totalclock' count, too.

This prevents displaying W_FORCEFIELD+1 masks (as e.g. in front of viewscreens) completely black with ART mapping. The old behavior, which is inconsistent with classic, is kept for one-sided masked walls, though.

So that stack traces can be gotten with optimized DEBUGANYWAY builds, e.g. for Linux's 'perf' --> flame graphs. DONT_BUILD.

DONT_BUILD.

Also, some minor style cleanup in game.c. DONT_BUILD.

BUILD_LUNATIC.

Now passed as last arg 'noFloorPal' to makepalookup(). Used as follows: - from loadlookups(): *false*, i.e. do take over floor pal. - from generatefogpals() [default fog pals] and fillemptylookups(): *true*, i.e. don't take over floor pal - from DEF 'fogpal': true - from DEF 'makepalookup': take over flag from pal from which we are remapping, or set to true if remapping from pal 0 - (CROSSHAIR_PAL: true) This should make the issue reported in http://forums.duke4.net/topic/775-eduke32-20-and-polymer/page__view__findpost__p__197583 resolve in a natural manner.

- 'nofloorpalrange' DEF token: now handled for both game and editor (for the latter, it's effective only for "shade preview" mode, [']+[X]). - in generatefogpals(), assign g_noFloorPal[] = 1 for every generated (default) fog pal; get rid of its return value / g_firstFogPal

This reverts/corrects two semantic changes of r4639 as far as what is now voxmodel.c (formerly part of mdsprite.c) is concerned. One correction ends up having no effect (m->bscale is always 1.f for voxel models, as far as I can see), but is the proper rewrite. Also, in osdcmds.c:registerosdcommands(), tweak two help strings.