This was requested by a user in early 2018. However, the proposed
prototype was susceptible to various forms of desynchronization, and was
unsuitable for merging. No further revisions were proposed, and the
feature languished. This commit enables the guidebot in cooperative
games and addresses the known synchronization problems, as well as some
other bugs that were uncovered during light testing. This is classified
as an experimental feature because it has not been heavily tested in
complicated games.
Requested-by: cfeuersaenger <https://github.com/dxx-rebirth/dxx-rebirth/issues/364>
`make_nearby_robot_snipe` computed the `robot_info` of every `object` in the
area before checking whether those `object`s were of type `OBJ_ROBOT`. This
is wrong, but usually harmless since it checked the type before using
the resulting `robot_info`. Starting in commit 9f26e2211, this triggered
a warning whenever `make_nearby_robot_snipe` checked nearby non-robot
`object`s.
Rewrite the tests to check for type `OBJ_ROBOT` before reading the
`object`'s id.
Reported-by: zicodxx <https://github.com/dxx-rebirth/dxx-rebirth/issues/429>
Fixes: 9f26e2211e ("Warn on invalid object ID access")
Commit 9898d13 fixed a crash on long filenames, but also tried to
optimize the Destination Saturn hack. However, this optimization was
implemented incorrectly, and caused the game to read only the
Destination Saturn highest_level entry when playing the First Strike
campaign, rather than using the greater level of Destination Saturn or
First Strike.
Restore the old logic, but restrict it to D1X. D2X never used an empty
string for the First Strike campaign, so this logic could not trigger
there, which is also how the bug was missed in initial testing.
Reported-by: zicodxx <https://github.com/dxx-rebirth/dxx-rebirth/issues/428>
Fixes: 9898d136f1 ("Fix fortification crash loading missions with long filenames")
In multiplayer, the host sends a destroy message for both sides of the
wall. `do_exploding_wall_frame` processes both, but
`num_exploding_walls` is only decreased by 1, causing an assertion
failure at the end. Remove the assertion, since the wall does not
explode instantly on join, despite being marked as WALL_EXPLODING.
PhysFS 3.0 tests whether archive members are directories, but treats a
symbolic link that points to a directory as distinct from the underlying
directory, even when symlink following is enabled. As a result, if
$D2X_REBIRTH_HOME/missions is a symlink to a directory, then it is
ignored and no missions are available. In PhysFS 2.0, the link was
followed and the missions were available.
Add a trailing dot to the path, which already has a trailing slash, to
force PhysFS to consider the underlying directory, not the link.
If register_compile_target=0, `self.builddir` on DXXProgram was used but
not set.
```
AttributeError: 'D1XProgram' object has no attribute 'builddir':
File "/s/SConstruct", line 5263:
main(register_program)
File "/s/SConstruct", line 5218:
''.join(['%s:\n%s' % (d.program_message_prefix, d.init(substenv)) for d in dxx])
File "/s/SConstruct", line 4853:
self.register_program()
File "/s/SConstruct", line 4895:
exe_target = self.builddir.File(exe_target)
```
In one path, load_briefing_screen is called with `br->background_name`
as an input. This caused a call to `snprintf(a, sizeof(a), "%s", a);`,
which is undefined behavior. Switch back to the prior style of
unconditionally declaring a local array, performing filename
manipulation in that array, and copying the array back to
`br->background_name` afterward.
Reported-by: zicodxx <https://github.com/dxx-rebirth/dxx-rebirth/issues/420>
pkubaj proposed extending the if/elif tree. This patch instead switches
to a loop, which avoids repeating any strings and is cleaner to extend
when another platform shows up needing normalization.
Requested-by: pkubaj <https://github.com/dxx-rebirth/dxx-rebirth/pull/426>
clang treats -Wunused as a request for -Wunused-lambda-capture, which is
good, except that -Wunused-lambda-capture is overzealous. It should
warn for captures that are not used in the body. It should not, but
does, warn for captures which are used in the body when such captures
are not required by the standard. Since 4 of the supported gcc versions
require that capture, removing the capture is not an option at this
point. Add a test to suppress the clang warning in this case, and hope
that eventually clang will warn only for uses that are actually unused.
This removes the need for parts of <https://github.com/dxx-rebirth/dxx-rebirth/pull/426> (by pkubaj).
Remove use of object_guidebot_cannot_reach and instead track the
reachability of the object as a separate flag. This allows the game to
remember when an object was found, but unreachable. Previously, it
would store only that some unreachable object was found. Now, it stores
the index of the unreachable object. This extra information is not used
yet.
Reported-by: Dainslaif <https://github.com/dxx-rebirth/dxx-rebirth/issues/421>
Fixes: c3cead4319 ("Move Escort_goal_index to d_unique_buddy_state")
Commit 0e81c05 moved the offending line, but it was already wrong in
54d57a37c9.
Fixes: 0e81c0594e ("Move settings that affect the build to UserBuildSettings")
When reading [announcement](https://www.dxx-rebirth.com/news/dxx-rebirth-rebooted/) it referenced the README file for reporting issues but there isn't a root README... and the ISSUE_TEMPLATE.md wasn't referenced by the README files within the sub-folders... and generally it felt like there should be a README
... every project should have an up front README file. (This is one.)
`blast_nearby_glass` calls `check_effect_blowup`, but ignores the result.
If `check_effect_blowup` executes a blow-up effect, and the blown object
is a switch, the return value will instruct the caller to execute the
associated trigger. Since `blast_nearby_glass` ignores the return
value, it never executes a trigger. This was originally masked by a bug
that passed undefined data from `blast_nearby_glass` to
`check_effect_blowup`, which usually confused `check_effect_blowup` into
treating the explosion as not originating from the player. This
confusion then forced an early return when a switch was hit, effectively
accidentally making switches invulnerable to `blast_nearby_glass`.
Commit f6352e7 fixed the data confusion, allowing `check_effect_blowup`
to recognize that the explosion came from a player's weapon. However,
it did not add handling for the trigger, so now `blast_nearby_glass` can
destroy the switch without activating the trigger. This is at the least
annoying, and in some levels may make progress impossible. There are
two ways to resolve this:
- Fix the logic to always execute the switch when the switch is
destroyed, whether by direct hit or by `blast_nearby_glass`.
- Restore the quirk that switches are invulnerable to
`blast_nearby_glass`.
Conveniently, the `force_blowup_flag` is set by `blast_nearby_glass` and
clear for all other callers, so it can be used to recognize that the
caller will not handle the switch. Use this to implement choice 2.
Even with this change, a direct hit by a missile can still destroy a
switch and activate its trigger, since that is handled through
`collide_weapon_and_wall`. Thus, players can still use the technique of
using a guided missile to activate an otherwise impossible switch.
Fixes: f6352e7957 ("Pass correct object to check_effect_blowup")
Reported-by: wm4 <https://github.com/dxx-rebirth/dxx-rebirth/issues/419>
gcc-9 warns on taking the address of an unaligned member in a packed
structure. This structure does not need to be packed. Remove
__attribute__((packed)) and fix the code to implement I/O correctly
without packing.
gcc-9 rejects `std::enable_if<false,
std::integral_constant<std::integral_constant, 1> 0>::type` before it
notices that the whole expression is eliminated due to SFINAE. Use
`std::common_type` to coerce the inner integral_constant to an
appropriate integer type, which allows the expression to be well-formed
enough to reach the SFINAE check from enable_if, then be silently
removed from the overload resolution set.
Users who do not install Boost cannot include <boost/config.hpp>.
SConstruct handled this by disabling the macro DXX_BOOST_FALLTHROUGH,
but did not override gcc's default-enabled (via -Wextra)
use of -Wimplicit-fallthrough=3, so users would get a fallthrough
warning and the build would fail. Adjust this area to explicitly probe
for -Wno-implicit-fallthrough when Boost.Config is not available.
Fixes: 063bf29225 ("Enable -Wimplicit-fallthrough=5; fix resulting breaks")
Reported-by: Jayman2000 <https://github.com/dxx-rebirth/dxx-rebirth/issues/417>
