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.

[markooff]

Perhaps ... I usually like simple (hard typing and consequent languages like C,C++ Java and so on ...) and sqf can still amaze me ...in so many ways :) Anyway, as usuall, - thank You for Your valuable help @BaerMitUmlaut

[commy2]

Locality has nothing to do with SQF. You have these issues in all server-client games or programs for that matter.

[markooff]

Yes, but I have no problems with locality (i.e. variable scopes ) in such language than C++ or php or few others in my normal job , I also uderstand rules of data types coersion (for instance in jscript) , but here, in SQF there are so many inconsequencies and - to be frank - stupid and "quick&dirty" solutions , that year by year I cannot stop of being surprized ...

But, fortunately , I have (limited) knowledge of sqf - which let's me nothing more and less than doing my job (i.e. writing/maintaining some useful mods for some sort of arma3 users ), and, of course, sometimes I cannot do this without Your valuable help (in handling eventhandlers and such things) And this let me be also grateful :)

[BaerMitUmlaut]

You're mixing up network locality and variable scopes. But this is getting off topic.

[markooff]

I think that variable scopes (i.e public, private , protected in several object oriented languages) is somehow close enough to the types of variables in SQF ( _this vs this and so on) and more - even a simle var declared in fucntion (and it's limited scope) in ANY (ok almost any) language ... That was what I want to say...

Network locality and client-server architexture is something different , but I'm not an expert like You) in this part of sqf-knowledge . so i cannot comment this,. but only asking a question .

Moreover, the feeling of incosequency in sqf isn't only my opinion, if You for instance have read KK blog carefully - there are severall such examples there...

[markooff]

But, @BaerMitUmlaut, @commy2 - I have another question - what do You think about https://github.com/acemod/ACE3/issues/3594#issuecomment-815389035 ?? In Your opinion - is it possibile to solve this issue/feature request ??

Best Regards

[BaerMitUmlaut]

Please stay on topic, thanks.

[markooff]

OK, sure thing.. So let me know, please, WHERE I can ask about the https://github.com/acemod/ACE3/issues/3594#issuecomment-815389035 and the possibility (even hipotetical and even in the far, far future) of doing such things ? As far as I know, You haven't pin the issue like "Questions about new feature request (Everything, you want to ask about, but are affraid of doing so...)" , yet ... :) :D

[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.