`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.
AlexanderBorisov reported[1] a broken demo that ultimately traced to
incorrect reuse of stale data. The campaign[2] includes per-level robot
definitions for level 3. Descent incorrectly accessed Robot_info before
reloading it for the new level, so it used the level 3 data on level 4
robots during a warm start of level 4 for regular play, but used only
the level 4 data for a cold start of level 4 for regular play and for
playback of a demo recorded solely on level 4. The particular
customizations applied on level 3 caused a level 4 demo recorded with
level 3 robot customizations to use different record lengths than a
level 4 demo recorded with level 4 robot customizations. Since demos do
not record their record lengths, mismatched record lengths lead to
effectively corrupt demos. In this case, it manifested as writing 8
anim_angles (per model_num 108, the model incorrectly inherited from
level 3) instead of 1 anim_angles (per model_num 37, used only on cold
starts). The extra anim_angles were then misinterpreted as a run of 42
ND_EVENT_EOF, because the extra angles were unused and the newdemo code
defines the null byte as EOF (separate from receiving an actual EOF
indicator from the file I/O library). That run of spurious EOF caused
the demo playback code to refuse to play past the spurious EOF,
resulting in a seemingly broken demo.
As an unfortunate, but unavoidable, consequence, this change modifies
the common path (warm playthrough of every level in the campaign) to
work like the uncommon path (cold start of each level). Further, the
affected robot triggers a trap in d2x::do_silly_animation[3] when using
the correct model_num, because that polygon model has too few models for
the joints used by the robot. When using the incorrect level 3 data,
the robot animates without trapping.
[1] https://forum.dxx-rebirth.com/showthread.php?tid=1023
[2] http://www.enspiar.com/dmdb/viewMission.php?id=212
```
sha1sum ENTROPY.HOG ENTROPY.MN2
7bc7a12d00a1ddd3ae92ce90eb67d581ecab004a ENTROPY.HOG
f2688a634f22b30a02c43d8fa1a049deb5a03f70 ENTROPY.MN2
stat -c '%s %Y %n' ENTROPY.HOG ENTROPY.MN2
2402638 875757712 ENTROPY.HOG
511 875757164 ENTROPY.MN2
```
[3]
```
799 if (jointnum >= Polygon_models[objp.rtype.pobj_info.model_num].n_models) {
800 Int3(); // Contact Mike: incompatible data, illegal jointnum, problem in pof file?
801 continue;
802 }
```
