'Fix' race condition where rope is cut as someone mounts the rope

[AACO]

When merged this pull request will:

• Prevent ace menu option jump. When three people try to mount two ropes, the way the ace menu jumps basically guarantees that the slower person will accidentally cut the rope, instead of mount the rope. Just adds a condition to the canCut where if all ropes are mounted you cant cut the ropes.
• Related to three people trying to mount two ropes, when the rope gets cut it's possible for the 'dummy' to be at 0,0,0 so when the actual fast ropers are attached to the dummy, they get dumped into the origin. This fix will just let the actual fast ropers fall. (sucks for them, but they normally should be revivable)
• Minor doc corrections

[AACO]

Not ready yet

[AACO]

Fixed the hook logic

[jonpas]

Should we rather just prevent cutting ropes if anyone is currently fast roping? That would solve interaction issues fully.

[AACO]

Fallout from the option ''jumping'
https://youtu.be/-8bIM4zgoiA?t=97 (3rd person)
https://youtu.be/5ki_kko3Go4?t=4 (1st person)
Given, that situation could be better managed with better communication.

Forced example of the 0,0,0 teleportation issue (happened to three groups of two in the above example)
https://youtu.be/u7j5xr50VEU

Its worth a discussion on what you guys would prefer. I first had it where you can't cut when anyone was on, but I dialed it back to just prevent the jumping issue itself

[jonpas]

We recently ran a fastroping training session, just to get the procedure into our heads to avoid all sorts of shenanigans Arma throws at us. The only complaint at the very end was that jumping interaction. I'd say it's best if we just prevent cutting if anyone is on the ropes. If that's at all possible due to how things are tracked (something on server?).

About teleportation issue "fix", it's definitely better that you fall than getting teleported to 0,0,0. Nice catch!

[BaerMitUmlaut]

I'm not sure how this stops the teleport from happening. Can you explain what causes it in the first place? When the rope gets cut, the dummy is simply deleted 60 seconds after, it doesn't go to [0, 0, 0].

[AACO]

It's only something that can happen in a latency environment, but what happens in essence is two people hit the fast rope option and one other person immediately after (accidentally) cuts the ropes. When the rope is cut, the hook is removed, but the dummy is still active, so the fast ropers who are still going through the local PFH get attached to the dummy which is at 0,0,0

On deploy:

• The hook is created at [0,0,0] point
• The hook is attached to the hook points
• The dummy is created a meter lower than the hook point

What happens to the fast ropers when the rope is cut:

• Both ropers set _vehicle setVariable [QGVAR(deployedRopes), _deployedRopes, true]; and begin a server and local PFH which (have the deployed rope passed in as parameters) that are waiting for the unit to move out.
• The cutter wanted to fast rope, but the menu jump forced them to cut the rope instead, which instantly deletes the hooks (making them objNull) and resets the deployed ropes array (which doesn't matter for the ropers since the arrays are already passed to the PFHs)
• The server PFH will then set the dummy to the origin private _origin = getPosASL _hook; _dummy setPosASL (_origin vectorAdd [0, 0, -2]); (getPosASL objNull will return [0,0,0])
• The local PFH will attach the unit to the dummy (note this can happen before or after the server PFH moves the dummy, but the result is the same).
• The unit will then be detached since they're on the ground (or water)

Edit:
So my fix is two fold, never allow cutting the rope if there are units on it, and if it's force cut (by scripting or what have you) do not attach the units to the ropes if the hook is null (as it will put them at 0,0,0).

[BaerMitUmlaut]

I took a deeper look now with the help of your explanations. Great work finding this bug.

Your fix prevents the player being attached to the dummy when the rope was already cut. That's good so far. For future reference, I'll explain this in my own words again just so I can understand what was done here:

• player starts fastrope
• rope gets cut while player is moved out of the vehicle, hook gets deleted during cut
• the player is attached to the dummy
• the server PFH detects that the player has moved out of the vehicle and sets the dummy to its initial position, which is 1m below the (now deleted) hook, thus the dummy gets set to [0, 0, -1]
• next frame, the server PFH detects the player being "on the ground" and removes the PFH, fastroping considered finished
• local PFH cleans up animation etc.

With this PR the player is not attached to the dummy at all, and just starts falling which is intended behaviour.

---

However, I'm also concerned about the following situation:

• player starts fastrope
• player is moved out of the vehicle, attached to the dummy
• at the same time, rope gets cut, hook gets deleted
• server PFH just now arrives at L27, and the dummy position gets set, teleport to [0, 0, -1] happens
• just now local PFH with your fix runs, after the teleport

This would not be prevented by this PR. I'm not sure how likely that is and if it can happen at all with Arma's networking, but I'll fix it in a seperate PR just to be sure.