Dedicated server moveInCargo, BIS_fnc_MP, locality

[Sniperwolf572 758]

I have a test mission with nothing but a truck named truck, and 3 units in a group named u1,u2,u3.

I launch this on my dedi and I connect as a client.

I've enabled the debug console for the MP and I execute the following via server exec. (I do this because I have a much more complicated system which actually executes the same code on the server, but I've isolated it for this test case)

{ 
   [[_x, truck], "moveInCargo", true] call BIS_fnc_MP;
} forEach [u1,u2,u3];

I execute it on every machine, purely to make sure it will also execute on the machine where _x is local. Replacing "true" with "_x" to execute it only where _x is local yields the same results.

Case 1 - Player is u1, the group leader, AI is u2 and u3:

Everything goes as expected, all three units are moved into the cargo space of the truck

Case 2 - Player is either u2 or u3, AI is the other two.

On first execution of this, both AI are moved into the cargo space. Player does not get affected.

On the second execution of the same script, player is also moved into the cargo space.

Time between the mission start and the first execution is irrelevant. Player never seems to move into the cargo on the first attempt unless he is the leader of the group.

Executing this without BIS_fnc_MP, everywhere and by manually checking locality yields the similar results.

What am I missing here?

I've seen similar threads where nothing happens on the first execute, and I've seen solutions mostly revolve around spamming the command until the unit is actually in the vehicle.

Surely this brute force way can't be the only solution to this.

Edited January 24, 2015 by Sniperwolf572

[das attorney 858]

Hi,

Have you tried assigning as cargo (assignAsCargo) for each unit before the moveInCargo?

Also, check the reference chart at the bottom of this page:

https://community.bistudio.com/wiki/orderGetIn

It seems there's issues with player controlled AI for some command but no notes about AI led players. (Also no ref to moveInCargo in the table). Maybe one of those commands in conjunction with moveInCargo might work.

[Sniperwolf572 758]

Hi,

Have you tried assigning as cargo (assignAsCargo) for each unit before the moveInCargo?

Also, check the reference chart at the bottom of this page:

https://community.bistudio.com/wiki/orderGetIn

It seems there's issues with player controlled AI for some command but no notes about AI led players. (Also no ref to moveInCargo in the table). Maybe one of those commands in conjunction with moveInCargo might work.

Tried it already earlier. The only difference it makes is that with it, when I do manage to be put in the vehicle, I'm not ordered out of it right away.

I'll try the other ones, but I'm confused what makes the first execution of moveInCargo to "fix" the ones following after it.

[Sniperwolf572 758]

Alright, figured it out.

Turns out that it's possible for moveInCargo to assign multiple units to the same cargo index in MP if executed one after another with varying localities, and that's where the command failed I suppose.

I believe the reason it worked for the leader but not subordinates I guess is simple, leader ended up being first in the array. There were no occupied spots in the vehicle at the start and additionally the AI subordinates where then local to the player leader.

I believe the reason it failed when the player is a subordinate is that the AI was local to the server, was moved there just before the remote player unit also tried to move in the same slot. Executing the command a second time, the AI units were already in the vehicle, and appropriate cargo index was used.

In the end, using "_x moveInCargo [_vehicle, _forEachIndex]" removed the chances of identical index and resolved the issue.

[das attorney 858]

Thanks for the follow up and solution :)

[killzone_kid 1331]

Alright, figured it out.

Turns out that it's possible for moveInCargo to assign multiple units to the same cargo index in MP if executed one after another with varying localities, and that's where the command failed I suppose.

I believe the reason it worked for the leader but not subordinates I guess is simple, leader ended up being first in the array. There were no occupied spots in the vehicle at the start and additionally the AI subordinates where then local to the player leader.

I believe the reason it failed when the player is a subordinate is that the AI was local to the server, was moved there just before the remote player unit also tried to move in the same slot. Executing the command a second time, the AI units were already in the vehicle, and appropriate cargo index was used.

In the end, using "_x moveInCargo [_vehicle, _forEachIndex]" removed the chances of identical index and resolved the issue.

When player is not a leader, even assigned vehicle role could be different from actual vehicle role once inside the vehicle. AI would assign position to the player but player can enter different position, but assignedVehicleRole will still report what position was assigned by AI leader, not actual position.