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.
Resolve the object to a vmobjptridx once, and use it as needed. Replace
some uses of ConsoleObject with the local player, since those should be
the same, and local player is already computed.
Commit 81dd23b151 ("Only charge player for weapons that fire successfully")
added an early return when `objnum == object_none`, so if execution
reaches the call to `multi_send_fire`, then the object is guaranteed to
exist. Access the track_goal without rechecking whether the object
exists.
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.
- 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.
Every caller passes `1`, so remove the parameter and always use `1`.
For backward compatibility with the previous network protocol, continue
to send a `1` in the network message.
Previously, rendering the preferred bomb type could also change it if
the active type was exhausted. This is undesirable, since it depends on
the user to have a HUD mode which causes the bomb type to render.
Switch to only change the active type if the user tries to drop a bomb
while the active type is unavailable. Some call sites already switch
bomb types automatically on depletion. Those sites will still do so.
gcc and clang disagree about how to disambiguate when an identifier is
both a typename and a member. Avoid the disagreement by renaming the
member.
Reported-by: Kreeblah <https://github.com/dxx-rebirth/dxx-rebirth/issues/532>
As reported in pull #507, the D1 implementation of the reduction was
incorrect and never reduced laser power. Therefore, when D2 emulates
D1, D2 should emulate the effect of the bug, by not reducing laser
power.
The code that provides the 0.75x multiplier to laser bolts when they're fired
using the quad laser is present in D1 as in D2, however it is incorrect and
results in it not being applied. As such, it is more accurate to exclude the
multiplier when compiling D1.
Thanks to SaladBadger for the tip.
Commit 2bcc7bb371 restricted
Laser_create_new to only create lasers for known weapon types. This
seemed like a good idea, but broke custom levels that use undocumented
laser types. It also replaced logic that coerced invalid weapon numbers
into a type 1 laser with logic that prevented firing such weapons at
all. This rendered robots with unknown or broken weapon data unable to
fire.
Commit 0c30fa7cf3 relaxed the logic to
prevent firing only in editor builds, but allow firing unknown or
invalid weapon types in release builds. Firing unknown weapon types may
work. Firing invalid weapon types may cause the game to crash when data
is accessed beyond the end of the defined weapon data. This caused the
crash reported in issue #506.
Revert to the 0.58.1 rule that invalid weapons are coerced to be a
player level 1 laser. Add a diagnostic when such a weapon is fired,
since the level author should have requested that weapon explicitly if
that was intended.
Reported-by: heftig <https://github.com/dxx-rebirth/dxx-rebirth/issues/506>
Fixes: 2bcc7bb371 ("Only create lasers for known weapon types")