Dragging - Fix corpse position desync

[Dystopian]

When merged this pull request will:

• fix corpse position desync after dragging in multiplayer;
• move code to function.

Over the last few months, I've noticed that corpse dragging often fails to move a dead body to its new position in multiplayer on a dedicated server. I'm not sure when this started, maybe since some Arma update (2.20?).

I preserved the original @johnb432 command order (setDir + setPos, followed by awake true + awake false in the next frames) and added a PFH to handle desync.

So far tested this only in dedicated server + client + headless client and hosted multiplayer + client configurations.

The following script can be used to reproduce the issue (create a player and a unit with health = 0):

[player, cursorObject, 4] spawn {
    params ["_p", "_c", "_n"];
    for "_i" from 1 to _n do {
        [_p, _c] call ace_dragging_fnc_startDrag;
        sleep 1.5;
        player setPosATL (getPosATL player vectorAdd [-7+random 14,-7+random 14,0.1]);
        sleep 0.1;
        [_p, _p getVariable "ace_dragging_draggedObject"] call ace_dragging_fnc_dropObject;
        sleep 2;
    };
}

The issue occurs most frequently on the first drag+drop operation after a server #restart.

[PabstMirror]

sample trace, triggered by commenting out exit on line 57

TRACE: 63575 moveCorpse: _dir=450.031, getDir _corpse=294.994, _posATL=[3191.88,5053.16,0.248856], getPosATL _corpse=[3192.43,5054.86,-10], getPosATL _corpse distance _posATL=10.6377 z\ace\addons\dragging\functions\fnc_moveCorpse.sqf:30
TRACE: 63575 initialMove: getDir _corpse=90.0312, getPosATL _corpse=[3191.88,5053.16,0.248856], getPosATL _corpse distance _posATL=0 z\ace\addons\dragging\functions\fnc_moveCorpse.sqf:56
TRACE: 63578 retryMove: _frameCounter=3, getDir _corpse=86.4784, getPosATL _corpse=[3191.72,5053.04,0.00062561], getPosATL _corpse distance _posATL=0.320841 z\ace\addons\dragging\functions\fnc_moveCorpse.sqf:86
TRACE: 63584 retryMove: _frameCounter=9, getDir _corpse=88.336, getPosATL _corpse=[3191.33,5052.37,0.242172], getPosATL _corpse distance _posATL=0.963143 z\ace\addons\dragging\functions\fnc_moveCorpse.sqf:86
TRACE: 63591 retryMove: _frameCounter=16, getDir _corpse=88.319, getPosATL _corpse=[3191.22,5052.2,0.189209], getPosATL _corpse distance _posATL=1.16147 z\ace\addons\dragging\functions\fnc_moveCorpse.sqf:86
TRACE: 63594 retryMove: _frameCounter=19, getDir _corpse=88.319, getPosATL _corpse=[3191.64,5052.81,0.212769], getPosATL _corpse distance _posATL=0.419844 z\ace\addons\dragging\functions\fnc_moveCorpse.sqf:86
TRACE: 63599 retryMove: _frameCounter=24, getDir _corpse=88.336, getPosATL _corpse=[3191.34,5052.37,0.148926], getPosATL _corpse distance _posATL=0.956702 z\ace\addons\dragging\functions\fnc_moveCorpse.sqf:86
TRACE: 63604 retryMove: _frameCounter=29, getDir _corpse=88.336, getPosATL _corpse=[3191.34,5052.37,0.113876], getPosATL _corpse distance _posATL=0.956633 z\ace\addons\dragging\functions\fnc_moveCorpse.sqf:86
TRACE: 63609 retryMove: _frameCounter=34, getDir _corpse=88.336, getPosATL _corpse=[3191.34,5052.38,0.0789185], getPosATL _corpse distance _posATL=0.957328 z\ace\addons\dragging\functions\fnc_moveCorpse.sqf:86
TRACE: 63615 retryMove: _frameCounter=40, getDir _corpse=88.336, getPosATL _corpse=[3191.34,5052.38,0.0439301], getPosATL _corpse distance _posATL=0.959857 z\ace\addons\dragging\functions\fnc_moveCorpse.sqf:86
TRACE: 63620 retryMove: _frameCounter=45, getDir _corpse=88.336, getPosATL _corpse=[3191.34,5052.38,0.00894165], getPosATL _corpse distance _posATL=0.963527 z\ace\addons\dragging\functions\fnc_moveCorpse.sqf:86
TRACE: 63625 retryMove: _frameCounter=50, getDir _corpse=88.336, getPosATL _corpse=[3191.35,5052.4,0.00637817], getPosATL _corpse distance _posATL=0.944247 z\ace\addons\dragging\functions\fnc_moveCorpse.sqf:86
TRACE: 63626 end: _frameCounter=51, isNull _corpse=false, isNull objectParent _corpse=true z\ace\addons\dragging\functions\fnc_moveCorpse.sqf:72

the body position looked fine the whole time, but distance was often high

We have to remember that this func runs on all machines
and setPosATL should have global effects?

So my gut reaction is that we might want to limit the number of retries or be more flexible on offset error
and then re-evaluate

[PabstMirror]

maybe be more accepting of some offset and only retry if it's really bad?
I'm not sure about this, just worried about doing setPosATL more than needed

Suggested change

	if (getPosATL _corpse distance _posATL < POSITION_THRESHOLD) then {
	if (getPosATL _corpse distance _posATL < (2 * POSITION_THRESHOLD)) then {

[johnb432]

Over the last few months, I've noticed that corpse dragging often fails to move a dead body to its new position in multiplayer on a dedicated server. I'm not sure when this started, maybe since some Arma update (2.20?).

Not convinced it's that. It wouldn't surprise me if I hadn't covered all cases, as I didn't want the code to be too performance intensive.

The following script can be used to reproduce the issue (create a player and a unit with health = 0):

A while ago, KK was addressing a bug where you couldn't open inventories of dead bodies. He fixed it in a profiling build and I tested it, but found that corpses that were generated by setting the unit's health to 0 in the editor were still broken. He told me he wouldn't touch that (see https://feedback.bistudio.com/T126030#2564403).
My point is: I believe unit's who have their health set to 0 in the editor are going to be buggy in some ways.

---

I'm really not a fan of trying to set a corpse's position numerous times (looks like in Pabst's example it's 10), especially since it runs setPosATL globally. It's already suboptimal as is, I'd prefer not adding more. I need to think on this.