Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: Player can become immortal when changing group right after fast travelling #3164

Closed
thegamecracks opened this issue Mar 5, 2024 · 1 comment · Fixed by #3196
Closed
Labels
Bug Something isn't working Exploit Issue/PR that addresses an exploit.
Milestone

Comments

@thegamecracks
Copy link

Describe the bug

When fast travelling, it is possible to become permanently immune to damage when changing groups soon after fast travel has completed.

From a cursory glance at the source code, I think it might be due to fn_fastTravelRadio.sqf not keeping track of the group's original units before it runs _x allowDamage true, letting the player bypass it by changing group:

sleep 5;
{_x allowDamage true} forEach units _groupX;

If this theory is correct, it should be fixable by storing units _groupX in a variable instead of re-evaluating it across the file.

How to reproduce

  1. Start a multiplayer game
  2. Make a new group in the [U] Group Management dialog
  3. Start fast travelling to a location like HQ
  4. Once it finishes fast travelling, open Group Management, leave the group, and create a new group (verify that the group name has changed)
  5. After some time, check isDamageAllowed player in debug console

Version

3.5.1.e520f09

Have you altered the code?

No

What i have changed

No response

Map

Tanoa

What server?

Private dedicated server

Time bug occured (Server time/UTC)

No response

Mods

No response

Additional context

No response

@jaj22 jaj22 added Bug Something isn't working Exploit Issue/PR that addresses an exploit. labels Mar 5, 2024
@jaj22
Copy link

jaj22 commented Mar 5, 2024

fastTravelRadio needs a rewrite, but if that's not done before the next release then we can quick-fix.

I feel like I've written this exact thing before for the same function...

@jaj22 jaj22 added this to the 3.6 milestone Mar 5, 2024
@Bob-Murphy Bob-Murphy modified the milestones: 3.6, 3.5.3 Apr 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Something isn't working Exploit Issue/PR that addresses an exploit.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants