The caller has the player object, and can provide the orientation matrix
from it. Use that instead of letting multi_send_fire recompute the
object in order to get the matrix.
When the player fires a generic secondary, the choice of proximity bomb
versus super-mine is never read. When the player specifically drops a
bomb, only that choice needs to be read. Pass the chosen weapon as an
argument, and avoid computing the choice on the path where it is never
read.
Two paths are always local. One path is always remote. Split the
handler function to remove the locality test and rely on the caller's
knowledge of whether the affected player is local.
Instead of sliding the entire queue down one element at a time, move the
non-expired elements in one step, and wipe all the trailing elements
in a single pass.
The only values for any given player are true/false, so use a bitset
instead of a byte per player. Some implementations may use a uint64_t
internally, negating the space savings. Even so, this version is
an improvement for requiring the use of playernum_t as an index.
The function had one caller, which always passed `0`. Inline that.
Next, observe that `sent` is only ever modified `if (!(Game_mode &
GM_NETWORK))`. As a multiplayer function, `multi_send_robot_frame`
should never be called in single-player, so this test should always be
false. Delete it, and observe that `sent` is now `const`.
Remove unused return value of `multi_send_robot_frame`.
Instead of passing a bare `int` named `secret_flag`, define it as an
`enum class : uint8_t` to name the two special values.
Rework the passing of this value, to deal with some confusing
inconsistencies when reading the code.
Before this change:
In D1:
- Multiplayer will always go to the secret level, regardless of which
exit door the player used.
In D2:
- Flying through a D1 secret exit in multiplayer shows the on-HUD error
"Secret Level Teleporter disabled in multiplayer!", and does not exit
the level. This is at best confusing, and at worst dangerous, since
D1 secret exits are only available during the countdown, so the player
has little time to realize that the normal exit must be used instead.
- Like D1, multiplayer will request to go to the secret level regardless
of the exit used. Unlike D1, the caller ignores the flag and always
advances to the next regular level.
After this change:
- No observable differences for the player in-game. The questionable D2
secret exit handling for D1 is retained.
- The code makes clearer that secret exits do not work in D2
multiplayer, by way of `#if defined(DXX_BUILD_DESCENT_I)` guarding the
existence of the parameter and all updates to it.
Using `netplayer_info` in `UDP_sequence_packet` defined many unused
fields. Replace this with per-message types that carry only the
required fields. Make these fields `const` where possible.
Remove the definition of FQ_CHECK_OBJS and all uses of it. Add a new
fvi_query member d_level_unique_object_state *LevelUniqueObjectState.
If object checking is enabled, pass &LevelUniqueObjectState in that
member. If object checking is disabled, pass nullptr in that member.
Change fvi_sub to use this member to decide whether to perform object
checking.
If FQ_CHECK_OBJS is used, a valid object is required. Copy the
icobjptridx_t from fvi_query into a local vcobjptridx_t to force a
validation, then use that validated copy for later work.
- Make all members constant, and pass an anonymous temporary fvi_query
to find_vector_intersection.
- Change `p0`/`p1` to `const vms_vector &`, since the positions are
mandatory. Callers can no longer pass `nullptr` or an uninitialized
value here.
- Change `thisobjnum` to `icobjptridx_t`. Calls to fvi_sub built an
objptridx at need, so moving it to the caller allows it to be
constructed once per find_vector_intersection call.
- Move `flags` and `rad` out of fvi_query, since calls to fvi_sub may
use other values than the ones in fvi_query. This prepares for
passing fvi_query to fvi_sub.
Embedding it in d_level_shared_robot_info_state is reasonable from a
relational perspective, but interferes with referencing
d_robot_info_array when only a forward declaration of
d_level_shared_robot_info_state is available.
clang-13 needed an operator==(const exact_type<T>&) defined to avoid an
ambiguity. Now that C++20 mode is enabled, switch to a
compiler-generated operator== instead of manually defining the
equivalent function.
In C++ 20 mode, clang-13 gets confused about how to handle operator==.
Rewrite the test to encourage it to pick the correct version.
```
common/include/gr.h:129:12: error: use of overloaded operator '==' is ambiguous (with operand types 'dcx::grs_main_bitmap *' and 'exact_type<dcx::grs_bitmap>')
if (this == &r)
~~~~ ^ ~~
common/include/pack.h:31:17: note: candidate function (with reversed parameter order)
constexpr bool operator==(const T *rhs) const { return p == rhs; }
^
common/include/gr.h:129:12: note: built-in candidate operator==(struct dcx::grs_bitmap *, struct dcx::grs_bitmap *)
if (this == &r)
```
clang-13 in C++20 mode fails:
```
similar/main/newmenu.cpp:202:18: error: ISO C++20 considers use of overloaded operator '==' (with operand types 'exact_type<const dcx::grs_font>' and 'exact_
type<const dcx::grs_font>') to be ambiguous despite there being a unique best viable function [-Werror,-Wambiguous-reversed-operator]
return &cv_font == &game_font ? "\202" : "\207"; // 135
~~~~~~~~ ^ ~~~~~~~~~~
common/include/pack.h:31:17: note: ambiguity is between a regular call to this operator and a call with the argument order reversed
constexpr bool operator==(const T *rhs) const { return p == rhs; }
^
```
Add an operator== that exactly matches the input types so that clang
does not attempt a conversion.