ParadropItem inconsistency between SP and MP

[LupusTheCanine]

Mods (complete and add to the following information):

• Arma 3: 2.02.147359
• CBA: 3.15.3
• ACE3: 3.13.6

Description:
Crates airdropped in SP are properly (as scripted) ejected from vehicle while in MP airdropping cargo results in crate spawning at correct position but with no velocity. Also parachute deploys before the crate can descend at all. It causes significantly different aiming requirements between SP and MP to hit the same spot.

Steps to reproduce:

1. For ease of testing set paradropTimeCoefficient to something low like 0.1 or 0.0.
2. Create a mission with GhostHawk and a crate that can be loaded into its cargo preferably in VR.
3. Run the mission in SP.
4. Load the crate into the helicopter.
5. Takeoff and hover 50m+
6. Airdrop the crate
7. Observe the crate go on a ballistic trajectory behind the helicopter until it starts drifting when parachute deploys.
8. Repeat steps 4.-6. in MP on dedicated server
9. Observe crate falling straight down before parachute opens

Expected behavior:
I would expect the crate to fall the same way in SP and MP.
Where did the issue occur?
-Dedicated vs Single Player
Log Files:
Not relevant

Additional context:
I observed this when working on airdropping tables.
Screenshots:
Video test on our (PGM) server with additional mods, identical results were obtained on a locally hosted dedicated server with ACE and CBA only.

[LupusTheCanine]

Further testing indicates that the issue might be at least partially caused by server load as I was unable to reproduce it on empty mission but the issue reliably happens on our server where a lot of objects are placed.
Another possible culprit might be adding items by classname vs adding objects.

[LupusTheCanine]

Another test indicates that the issue is related to differences between handling items added using classname and manually loaded, as manually added crates behave as shown in the video while ones added by classname behave correctly.

[BaerMitUmlaut]

This might be a locality issue with setVelocity.

[markooff]

Hmm...,
but we all (a few guys on the server) have seen them landing obviously in the same place, Baer .
And also when we went close to them - where they have landed - they were all at the same place ...
So I think , it rather cannot be the simple problem of locality because we were all on the same dedicated server , and it had to (and after a long while - it obviously managed to) propagate correctly the movement and place when the boxes landed ...

Or, am I wrong, maybe ?

[BaerMitUmlaut]

setVelocity is AL, so if the paradropped box is not local, it won't do anything. Position of non-local items is always synched.

[markooff]

Hmm, but we have tested it on our dedicated server - using things (crates, boxes, palettes) which obviously weren't local - because they all came from mod PGMLS (PGM Logistic System)
https://steamcommunity.com/sharedfiles/filedetails/?id=2120189955
and they all were placed globally and managed by server .

That was the base of our MP tests ...
So assuming what You have written , they should be positioned correctly - because they weren't local objects

[BaerMitUmlaut]

Locality can change during the lifetime of an object.

[markooff]

so You suggest that the change (global/local) should be made, at the end, inside some ACE functions because I always use createVehicle command for equipment spawning which is always GLOBAL and we only use ACE3 function for loading them (boxes, crates and so on) into the chopper ... And after the all crates were loaded the paradrop function was used ...

===============================================

//an example of spawning objects from / Logistic Container /
_crate addAction ["PGM Fireteam Ammo Crate", { _emptyPosAGL = [(_this select 0),"CAManBase",player,10,true] call ace_common_fnc_findUnloadPosition; if (count _emptyPosAGL == 0 ) then { hint "brak pozycji do spawnu"; } else { _box = createVehicle ["PGM_Fireteam_Ammo_Crate", _emptyPosAGL, [], 0, "NONE"]; _box setPosASL (AGLtoASL _emptyPosAGL); }; },nil, 1.5, true, true,"", "true", 12, false, "", ""];

[BaerMitUmlaut]

I don't think you quite understand locality and that's alright. It is definitely an issue on our side and we'll fix it.

[BaerMitUmlaut]

Please stay on topic, thanks.

[BaerMitUmlaut]

You can talk about it on our Slack.

[LupusTheCanine]

I did a test, all crates that were added using [classname, vehicle, count] addCargoItem deployed correctly ejecting backwards, but all manually loaded crates dropped straight down.
My script that reports dropped object and its owner showed that manually loaded crates are called <> REMOTE while those added using classname are not.

[commy2]

Double check with another person. It may look right for you, but still be broken for them.

[LupusTheCanine]

Video another test, this time two clients on a locally hosted server shown side by side.
If crate is REMOTE on a dropping client its velocity is not set at all.

I have an idea for a fix, will commit and WIP-PR shortly.

[commy2]

It is appreciated that you're thinking about a solution, but before we split any functions or use RE (lmfao) I'd just replace L53 and L70 with an QEGVAR(common,setVelocity) targetEvent.

[LupusTheCanine]

At

It is appreciated that you're thinking about a solution, but before we split any functions or use RE (lmfao) I'd just replace L53 and L70 with an QEGVAR(common,setVelocity) targetEvent.

At L70 parachute is local because it was just created, setting velocity doesn't have to be executed by target event.
Will try target event approach after merging #8203 as it affects the same code at few points.