Units becomes naked & driver jumps out on ownership change

[Kingsley1997 39]

Naked Bug

When a units' ownership changes their loadout is forgotten. This is odd behavior because it happens randomly and sometimes not at all.

 

Repro:

1. Connect to a dedicated server - your client machine must not be the server.
2. Enter Zeus
3. Place some groups of units (CSAT assault squad for example)
   1. You can also Ctrl+Place them to have them join the same group
4. Wait until the ownership of the group/units change to the server/headless client
5. Inspect each unit and see if some of them are naked (no uniform, vest etc.)

Driver Bug

Similar to the bug above, however this one causes the driver of a vehicle to disembark. This also happens when the ownership of the unit changes to the server/headless client. This is also random and doesn't always happen.

 

Repro:

1. Connect to a dedicated server - your client machine must not be the server.
2. Enter Zeus
3. Place a bunch of vehicles such as IFVs or tanks
4. Wait until the ownership of the group/units change to the server/headless client
5. See if the driver jumps out

[alexcroox 29]

I'm glad it wasn't just me! I too am seeing naked soldiers often when using Zeus + HC + automated transfer script.

[Freghar 73]

I can definitely confirm the dismount thing, although it seems to happen only after some mission runtime, it's not 100% reproducible. :(

Also, there seem to be multiple "levels" of /break-ness/ here - at the first level, moving (dragging) the unit back to the vehicle works, but after some time, the unit keeps getting out. Around that time, the Curator is unable to Directly Control units - it can see "through" the eyes of the soldier, just the movement/actions are AI-controlled. Also, dragging any air units via alt-drag doesn't make their engines start immediately, causing them to fall and crash.

Again, these cannot be immediately reproduced, but if you hook the CuratorPlaced EH and transfer any newly placed units (setGroupOwner) to ie. ID 2 (server) and give it enough playtime (30-60min), these issues pop up.

That is, in addition to the usual easy-to-reproduce limitations like the Curator not being able to change formation or group properties if the group isn't local to it.

Reproduced on Stable (1.56).

[PhillyJoker 15]

I've been experiencing this as well.

In addition it seems (though ad others mentioned there is randomness to this so I'm not 100 percent sure) it only occurs with player(zeus) to hc transfer. Not server to hc transfer.

The setGroupOwner command that all hc scripts use seems to be the issue, as it generally produces a 3-7 second desync spike as well.

[Dwarden 1124]

thanks phillyjoker, may I ask what build it was tested on ?

1.58.135656 (main branch stable binary)

or

1.58.135689 (profiling branch performance binary)

[PhillyJoker 15]

Main branch stable. I've even gone so far as to test it by just using the debug console and zeus. Spawning a group that I run setGroupOwner on changing multiple owners. Zeus player to server, player to hc, hc to player etc. The only one that causes desync is the very first instance generally. And mostly on player to hc.

Just so I'm clear, this has been an issue since setGroupOwner was implemented in 1.4. However the frequency seems to increase and decrease between updates.

[Freghar 73]

I can confirm the desync on setGroupOwner as well, although it seems to produce only a very slight lag for a second. It's the "red chains" that remain for up to 30 seconds. Again, stable branch since at least 1.50, when moving curator-spawned units from player to server. Doesn't seem to happen on player disconnect though, so it may be tied to the command itself.

[HKFlash 9]

Can confirm OP bug.

[pydrex 16]

This is still happening on latest APEX branch

[genesis92x 810]

Wanted to confirm that this error is still happening with the current stable build of ArmA 3. Has anyone found a fix since setowner is not supposed to be used for AI?

 

 

Edit: Issues seems inconsistent. Sometimes I get naked dudes running around and sometimes not...Trying to find the cause.

[Freghar 73]

I work around it by putting a big sleep between setGroupOwner calls - the "naked" bug seems to be caused by the server (?) racing with whatever transfer logic is in play.

If you call setGroupOwner on 10 groups (rifle squads) on a dedicated server, at least half of them become naked. If you do sleep 10 between the calls, no naked issues happen.

Running the command in scheduled/unscheduled doesn't seem to make a difference.

Note that this can happen even without using the command on mission start if the mission is more script-heavy, the server has a weak CPU/RAM or you have a lot of people to start the mission with. This AFAIK happens because the player units are created on the server and transferred to clients after that.

[arcanum 16]

Still there,stable 1.64.138762.

Pls fix BIS ? PLS.

[PhillyJoker 15]

Those saying still broken. How are you connecting HC to the server? You must be using the local loop (127.0.0.1) not the public IP.

We finally figured out that the -connect=127.0.0.1:2302 NEEDS the port of the server. At least in windows 2012 RC2 it does, and our naked AI issues vanished unless we drop like 300+ AI in less then a minute.

[oOKexOo 237]

It's not solely related to HC. It also happends when you transfer ownership from client to server as the OP stated. The "naked" AI issue is not that well reproducible for me, however the driver issue is (Tested in Zeus with Achilles on dedicated server, 1.66.stable).

[diehardfc 41]

This is still an issue in the current build when placing units as Zeus. I was sure it was related to the handoff to headless client, but now I wonder if it's happening during the pass from player to dedicated. Only semi-related, but another strange thing that I'm seeing is units placed in the editor appearing without uniforms at mission start. I first saw it some months ago when using Project OPFOR, but it recently happened with AAF units on Bornholm. Has anyone else ever experienced this?

[Meiestrix 25]

Has someone meanwhile found a fix for this?

This is still a problem when you transfer units from Zeus to the server, or a Headless Client.

[nomisum 129]

I believe this is still an issue. Phenomenon wise at least.