What changed in EDuke32, build by build

In the normal game, these arrays are conceptually [MAX_WEAPONS][MAXPLAYERS], allocated as CON per-player gamevars (e.g. WEAPONx_WORKSLIKE). For Lunatic, they are replaced with weapondata_t g_playerWeapon[MAXPLAYERS][MAX_WEAPONS].

Specifically, have a weapondata_t type mimicking the aplWeapon* arrays. Keep a list weapondefaults[] which undergoes some static->dynamic tweaks and then makes its way to the WEAPONx_XXX per-player gamevars.

This fixes 2nd and following rotatesprite calls drawing differently from the first in a context with custom set-up aspect, as reported by Lezing here: http://forums.duke4.net/topic/775-eduke32-20-and-polymer/page__view__findpost__p__143090 Also, back up and restore the aspect state across EVENT_DISPLAYREST.

This means that the internal change done to these sprite members in r3159 is hidden from CON for backward-compatibility purposes. Note that .cstat and .{ceiling,floor}stat aren't touched, and will return unsigned values to CON.

... in the 'default' case (non-FEM* tiles).

This currently says that MP saving/loading isn't supported, but doesn't really work correctly. Also, properly bound-check the immediate argument to CON's 'save' command and one more ... -> G_HandleAsync().

... and use it in three places. In two of these uses, 1) CON {read,write}arrayfromfile and 2) G_SavePlayer, display an error message if the file name such generated is too long. In the CON commands of 1), also error out if the file couldn't be opened.

For reference, they are the following: - cache1d.c: suckcache() - build.c: compare_wall_coords() - make switch-invisible heuristic - Mapster32: old sprite search - Mapster32: manual z range - m32script: read/writearray, qgetsysstr - menus.c: savetemp()

Basically, base palettes with lower indices trump higher ones. For example, when one player is underwater and the other above, the normal palette takes precedence.

ROTATESPRITE_MAX is moved to build.h and all orientation bits from CON commands using rotatesprite are ANDed with (ROTATESPRITE_MAX-1). Some of the functions use ROTATESPRITE_MAX for different internal purposes, which will not be exposed to CON now (a good thing). Also, dorotspr_handle_bit2 is made clearer.

This makes sounds like DUKE_GET (item pickup) be heard for the second player in the splitscreen mod, too.

This includes mirrors, rooms and masks. Any value other than 0 or 1 that is returned is considered an error (reserved for future use).

... against invalid weapon indices and arguments accessed from arrays/structs.

This was narrowed to int8_t in r1625, breaking CON code that wanted to lock the player for a longer time than 127 game tics.

The event is run after drawing the scene, but before the overlays. To make a screenshot from a script, set DOSCRSHOT to non-zero. It will then be scheduled to run once after the drawing but before the above-mentioned event. The screenshots will be called mcapXXXX.{png,tga}.

The editor colors are the ones listed on page 9 of the Mapster32 built-in help.

The latter shows that "int32_t ksqrt(int32_t)" also copes with values in the range INT32_MIN..-1, effectively interpreting them as uint32_t (i.e. adding 2**32). However, this should not be relied on from CON.

Bang! One more invalid internals exposure squashed. Maybe one day we'll be able to call EDuke32 "stable"... Actually the offending sprite IS drawn as face sprite with shade 32 and xrepeat and yrepeat 255 for the convenience of the CON coder who will have to debug it.

This fixes the glitches/corruption whereever showview is used from EVENT_DISPLAYROOMS while the scene is actually rendered to a tile instead of the frame buffer, for example because we have a tilted view or "pixel doubling" enabled. Fixing it for real (i.e. so that the showview actually completes) will require more effort.

This is done by kopen4loadfrommod'ing and immediately closing the file (since the checker is still run from there when not ingame). On my system, times were like 0.12 ms, 0.2 ms and 0.5 ms for each openfrompath/findfrompath, openfrompath/Bopen and SHGetFileInfo respectively, so it shouldn't have a too noticable impact on initial loading times.