Use of `partial_range` will trap invalid counts, but will throw an
exception and terminate the program. Change the logic to log a
diagnostic and clamp the count to the maximum legal value, so that users
can play the level. The level may still be impossible to complete, if
the triggers within the valid range do not open an exit door. However,
level authors always have the ability to get that wrong, so the logic
with recovery is better than the logic without it.
Also, add a new diagnostic for invalid side in a control center trigger,
and a new diagnostic for invalid segment in a control center trigger.
For the latter, add a special case to reduce the severity when playing
`Descent 2: Vertigo`, since there is a known bad trigger in a Vertigo
level, and users cannot fix it.
This default-zero allowed the bug introduced in
68b47307b4 (and fixed in
4c371734b5) not to generate a compiler
warning for `-Wuninitialized`, since it was initialized to `0`.
However, `0` is not a correct starting value for this variable. Remove
the initialization and require every code path to assign a meaningful
value.
Switch to use `std::in_range` to validate that no truncation occurs, and
trust that the compiler will optimize this out when the type passed to
`std::in_range` can represent all values that the argument can
represent.
Prefer memcpy with a predetermined length, rather than strncpy, which
could leave the buffer without a terminator. No current callers could
cause the lack of a terminator, but gcc-13 warns about it, so rearrange
the code to fix the warning.
gcc-13 was released with -Wextra implying -Wdangling-reference, but
-Wdangling-reference as released warns on cases that are safe. Add a
configure test to detect when the compiler warns incorrectly, and
disable the warning in those cases. When a future compiler emits fewer
false positives, the suppression of the warning should stop.
Reported-by: ziplantil <https://github.com/dxx-rebirth/dxx-rebirth/issues/718>
Testing for `object_none` is insufficient. Games saved before the fix
for 14cdf1b352 may have a `last_hitobj` of
`0x1ff`, which triggers an exception when constructing `icobjidx_t`.
Treat any invalid object index as `object_none`.
Reported-by: Quix0r <https://github.com/dxx-rebirth/dxx-rebirth/issues/716>
The index of the guidebot is set by loading the level data, and this is
usually sufficient. However, if the user kills the guidebot, then uses
cheats to create a new one, the new guidebot will often have a different
index than the original guidebot. If such a game is saved and then
reloaded, then after the reload, the computed guidebot index will be
reverted to the index of the original dead guidebot. This causes
various problems, including potentially a crash. Recompute the guidebot
index after loading the objects from the save file, so that it matches
the live guidebot.
Reported-by: GitInMotion <https://github.com/dxx-rebirth/dxx-rebirth/issues/713>
Various code assumes that Buddy_objnum maintains the invariants:
- If the guidebot exists, Buddy_objnum must refer to it.
- If no guidebot exists, Buddy_objnum must be object_none.
This was not enforced, so if the guidebot is killed, Buddy_objnum can
continue to refer to its last index. That can cause spurious errors
later. For example, when the player enters an energy center, if the
guidebot is dead and the guidebot's last goal was "Find energy center",
then the console reports:
```
BUG: buddy is object 28, but that object is type 255.
```
Fix that by clearing the guidebot index when the guidebot is killed.
Prefer non-static data member initializers over leaving the member
undefined in the constructor and relying on the caller to zero the
member afterward.
The pointer is only used by the constructor, so there is no need to
store it in the object.
Rework the allocation of the trailing storage to avoid the use of
placement new on a uint8_t[].
Pass a mutable buffer from the caller, and allow
PHYSFSX_addRelToSearchPath to adjust the capitalization in that buffer,
rather than creating a copy in a stack local. This can slightly affect
status messages that use the name, but otherwise should have no effect
on the game.
Store an owned pointer in MVEFILE instead of storing an unowned pointer
there and requiring the caller to keep the owned pointer alive for the
lifetime of the MVEFILE.
This has been broken since b1c5307eb1
changed the type of gr_palette from `uint8_t[256*3]` to
`array<rgb_t, 256>`. Remove it, since no one has reported it in 10
years.
Kp