`build_colormap_good` only took `used` to clear it. Only one caller
needed it cleared. Move the clear into that caller. Remove the
parameter from all calls.
The Windows build did not explicitly include <time.h> or equivalent, but
used `time` and `gmtime`, which are only available when <time.h> is
included. Other platforms include <time.h> incidentally.
Fixes: 131c1b9f4d ("Add support for PNG screenshots")
This is a longstanding cosmetic issue. Appending a tuple to a list
retains the tuple structure, which is then printed later. Append it as
a list so that it is flattened.
OpenBSD clang does not handle `-print-prog-name=as` in a useful manner.
Since this query is purely diagnostic, add an undocumented knob to
suppress the query.
User TRUEpiiiicness reports that valptridx<player>::check_index_range
traps when "The Apocalyptic Factor"[1] level 14 boss fires its Omega-based
weapon. Code inspection shows that this is expected, since the original
designers assumed OMEGA_ID would only ever be used by players, and coded
various shortcuts accordingly. No one told the level author this. The
boss is an interesting concept and not difficult to support, so adjust
the code to handle this situation correctly:
- Check that the shooter is a player before checking its player ID.
Without this, a robot that happened to have the same ID as the player
would interpret robot data as player data, likely causing corruption
when it tried to update the omega cannon charge. Even if the robot ID
does not match, this step causes a diagnostic[2] reporting that a
robot ID is being misused as a player ID.
- Remove the shortcut that assumes the shooter is a player. Store the
shooter's actual type.
- Remove the unnecessary and counterproductive path that:
1. Uses the object pointer to get the player's ID
2. Uses that player ID to get a player pointer
3. Uses that player pointer to get an object number
4. Uses that object number to get an object pointer
When invariants are maintained, the pointer derived in step 4 is equal
to the pointer used at the start of step 1. Use that pointer directly
instead of rederiving it. The reported exception was due to step 2,
which requires that the player ID is in range. When the shooter is a
player, this is true. When the shooter is not a player, it may not
be true.
[1] http://www.enspiar.com/dmdb/viewMission.php?id=418
```
sha1sum af.hog af.mn2
133c52fb4b4e5fd40bf7b2321789841b727d1d0b af.hog
0bb5f0dd1803b0fc1aac7c2023eacc97e9ab872b af.mn2
stat -c '%s %Y %n' af.hog af.mn2
4024838 1094445016 af.hog
566 1013524628 af.mn2
```
[2] `similar/main/laser.cpp:560: BUG: object 0x555556078958 has type 2, expected 4`
Reported-by: TRUEpiiiicness <https://forum.dxx-rebirth.com/showthread.php?tid=1038>
AddressSanitizer in gcc-7 inhibits deletion of certain otherwise
unnecessary nullptr checks, causing otherwise absent references to
class null_pointer_exception. As a convenience to AddressSanitizer
users, instantiate all valptridx templates when AddressSanitizer is
enabled. This is slightly excessive, but users building for
sanitization are not aiming for a minimal size build anyway.
