sorry I forget say it.
it's only effect client user. host(server) is not effect (can pick up)...
iow plz pick by client player.

In T126030#1629876, @razazel wrote:

Hello,

thank you for the feedback.

Unfortunately I am unable to reproduce the issue. Would you mind uploading the repro mission you have used?

Thank you

ty try repro. I update the mission. it's need 2 players to repro.

it's inventry bug.
so, "take" and "rearm" action command is usable.
but can't pickup/take from vest/uniform/bag on inventry view.

3den Arsenal I mean loadout editor. sorry cuz Im playing at japanese laungage. but friends are using english laungage for repro.

I'm having the same exact issue with all of my players on a dedicated server. Did anyone ever figure this one out? This is the only thread I've found about it.

There doesn't even be any need to change the target's inventory; merely opening the loadout editor on them and pressing "ok" to exit without making any changes will render anything inside his uniform/vest/backpack unlootable.

Able to replicate this 100% of the time using a dedicated server and one client.

If an AI unit had its loadout accessed, and clicked 'ok' via the 'Edit Loadout...' option in 3den editor, then:

1. If a player gets the 'hand' icon when near the dead AI's body, they can pick up any of those items, regardless as to where it is in the AI inventory (i.e. gun, grenades).

2. When accessing the Inventory menu on the dead AI, the player can take items such as weapons and inventory items on the AI such as map and compass.

3. A player cannot take ANY item located in a dead AI's inventory container (uniform, vest, backpack) such as first aid kits, ammunition. This has been tested with right clicking and trying to drag the inventory item to player containers.

4. However, a player can swap items from his inventory containers to the dead AI's back and forth with no issue.

5. A player can swap a dead AI's inventory container (uniform, vest, backpack) with no issue, and access any items inside once it is on the player.

6. If a player swaps his inventory container (such as uniform) with a dead AI's container, the items that were in the player's original container are accessible.

7. If a player swaps the container back to the dead AI body, the items in the dead AI's container are still inaccessible.

8. If a player takes the dead AI's container, transfers an item from it to his 'original' container on the dead AI body, then swaps containers again: if he transfers the item that was originally on the dead AI's container back to that AI container, it will be inaccessible again.

9. The only way to access this inventory is to swap the container with the dead AI, move away from the dead AI body, and then drop the AI's inventory container on the ground.

Finally, if a mission maker right clicks and chooses 'reset loadout' on the AI in 3den editor, it will allow players to access that dead AI's inventory container items as normal- instead of having to delete and replace the AI.

Because of this, mission makers must rely on gear scripts for AI instead of using 3den loadout for MPmissions.

I don't know this works in dedicated though, place

_nil = this spawn {_this setUnitLoadout getUnitLoadout _this}

in Init field, you can now loot items from these dead bodies.
However this sometimes failed to fix it(make him naked). Use sleep or waitUntil or something to more accurate execution? Need confirmation.

More useful usage example:

waitUntil {time != 0} ;
{_x setUnitLoadout getUnitLoadout _x} forEach allUnits ;

in init.sqf.

The bug still stands on my group dedicated server, if an IA has an custom loadout, we cannot take what's is in his uniform/vest/backpack.

In T126030#1672863, @POLPOX wrote:

I don't know this works in dedicated though, place

_nil = this spawn {_this setUnitLoadout getUnitLoadout _this}

in Init field, you can now loot items from these dead bodies.
However this sometimes failed to fix it(make him naked). Use sleep or waitUntil or something to more accurate execution? Need confirmation.

More useful usage example:

waitUntil {time != 0} ;
{_x setUnitLoadout getUnitLoadout _x} forEach allUnits ;

in init.sqf.

Kudos to you ! The second one works perfectly.

This happened to me as a host with 10 other players yesterday on the Stable branch.

The bug is more prevalent for non host players but it can happen for the host too.

Basically I killed a guy and looted his body via the "Inventory" action on the body, was able to pick his main gun but then I couldn't pick up any other item on the body.

Closing and reopening the inventory screen via the "Inventory" action that appears on the body then started glitching, appearing and disappearing intermittently and then finally when I was able to open the inventory UI it closed a second later (And that kept happening so I wasn't even able to try again.

Guys this bug has been reported several times over several years and it was never addressed even when the Arma 3 dev team was very numerous so don't get your hopes up this time.

Yet this is such a prevailing and recurrent issue/bug that it would be a shame not to have it fixed before we see the last patch arrive for Arma 3.

In T126030#1672863, @POLPOX wrote:

I don't know this works in dedicated though, place

_nil = this spawn {_this setUnitLoadout getUnitLoadout _this}

in Init field, you can now loot items from these dead bodies.
However this sometimes failed to fix it(make him naked). Use sleep or waitUntil or something to more accurate execution? Need confirmation.

More useful usage example:

waitUntil {time != 0} ;
{_x setUnitLoadout getUnitLoadout _x} forEach allUnits ;

in init.sqf.

I found something rather interesting while trying to get the second workaround to work for me:
The second script was run on postInit, works for the host (in self-hosted multiplayer, meaning a player is the server) but no other clients in my setup (for some unknown reason).
When the host takes items out of a container of a unit affected by the bug (even when they are unconscious when using ACE), it does NOT update the inventory, meaning that anyone else except the host will see the full inventory as it was spawned, yet the host will see the correct inventory.

Testing some more today (with one self-hosted server (host), other client) revealed that if the locality of the AI is changed, it fixes this bug - but only for the PC it was set local to.
So in my case it made it possible to pick up items from a dead body local to my connected client, but from my host I couldn't pick anything up from that body anymore.
When I made the body local to the host again, I could pick stuff up on the host again, but not from the connected client.

With the previous discoveries, I'm guessing it's some sort of locality issue not being correctly synced across all connected PCs.

In T126030#2288662, @johnb43 wrote:

Testing some more today (with one self-hosted server (host), other client) revealed that if the locality of the AI is changed, it fixes this bug - but only for the PC it was set local to.
So in my case it made it possible to pick up items from a dead body local to my connected client, but from my host I couldn't pick anything up from that body anymore.
When I made the body local to the host again, I could pick stuff up on the host again, but not from the connected client.

With the previous discoveries, I'm guessing it's some sort of locality issue not being correctly synced across all connected PCs.

Good find!

Perhaps if the player opening the inventory makes the body/container local to himself while the GUI is open it could be a work around that the devs could implement relatively fast.

Such work around shouldn't be hard to implement with the default addaction but for players nearby just pressing the "I" button then I don't know how it could be made to work.

Perhaps when a nearby player presses the "I" button the client creates a virtual "container" with duplicate items that are local to himself but also update the original body once the UI is closed.

That could lead to item duplication thou, if more than one player is checking the same container at the same time and moving items around.

Another potential way to deal with the issue is to have only one player being able to interact with any container at the same time. So only the player who pressed "I" first gets the items on the container/body while the second one gets nothing or gets a "unable to interact with Container X, it is being used by player X" message or something.

This issue still happens extensively as of August 2022! Here is a video to clearly illustrate how and when it is happening so there is absolutely no doubt about it: >

https://youtu.be/a7FLyLSqhN8?t=99

In the video you can see the issue happening when trying to pick items from weapon holders and crates while I have previously experienced it when trying to pick weapons from enemy Ai bodies.

Another player on the same server was having item duplication each time he tried to pick up the weapons from a dead Ai body too. He would drag the weapon to his inventory only to have the weapon duplicated on the floor but not adding it to his inventory.

The inventory system is a core system to the game and a staple to the whole arma experience so allowing it to remain broken sends a terrible message about how even core features are handled

rev 150292

I have a workaround for crates. I use a trigger to assign ownership of the crate to a nearby player. I'm not sure if this reproduces johnb43's workaround, by changing locality. Here's the snippet of code in the trigger: {crate setOwner owner _x} forEach thislist;

Unfortunately still broken in rev 150832.

I able to reproduce this on Arma 3 Stable https://youtu.be/ERRmsWPZE24, but on today's Arma 3 Dev rev. 150832 - no https://youtu.be/H7DOBWyRKus, I have it fixed
Dedicated server, 1 player

In T126030#2481963, @johnb43 wrote:

Unfortunately still broken in rev 150832.

I should have added: There is one instance where it's still broken.

If you set the health of a unit to 0 in the editor and start the mission, it's broken in the same it was before this fix.
Generally speaking though, units that have their health set to 0 in the editor behave in odd ways.

However, for units that die in the mission the fix works.

This would be a different issue. I will look at it for 2.16

I'm surprised it event works anyhow on dead unit. I wont touch it in fear it might break something else, so just kill unit after mission start rather than starting with health 0. Gonna close this as fixed