I believe it is related to the fact that the player is touching the ground at the time

This is still an issue in 2.16.151618.

I cannot see which script file it was, but the "modParams" command was at line number 374.

https://feedback.bistudio.com/T79689#2562787

ammo_box addWeaponCargo ["MineDetector", 1]
-> MineDetector has no weight and can be equipped as secondary weapon.

Thanks for clarifying.
Is there any chance that it could be updated to return false when it's not capable, despite not being part of the original intent/design?

As far as I have been able to test in 2.17.152062, this now works as advertised.

As far as I have been able to test in 2.17.152062, this now works as advertised.

As far as I have been able to test in 2.17.152062, this now works as advertised.

AISFinishHeal doesn't work in this case at all. I have found that resetting their animation finishes the action and heals them:

This is still an issue in 2.16.

As far as I can tell, this is no longer an issue, the actions don't reset the fire mode.

Would the new one have the same hash?

Tested with the latest profiling branch - has indeed been fixed. Tyvm!

Tested with the latest profiling branch - has indeed been fixed. Tyvm!

As actionKeysEx was added, imo this is resolved (it does the job well for me).

Still an issue in 2.17.151825.

I tested addMagazineCargo, addItemCargo and addMagazineAmmoCargo, all are fixed. Tyvm!

Any chance to see removeMagazineTurret get the same treatment as addMagazineTurret did (i.e. getting a third optional parameter specifying the ammo count)?

Can you close https://feedback.bistudio.com/T122981 and https://feedback.bistudio.com/T80537, as they are related to the fix?
It's not really related to this, but https://feedback.bistudio.com/T79683 can be closed too.

I'm looking forward to the next profiling branch!

Bug 1 seems to have been fixed, as I can't reproduce it.
However, bug 2 still persists unfortunately. It happens only if the player doesn't have the throwable class that's added with the command.

I have tested on the latest profiling branch using both BI and ACE arsenal - seems to have been resolved. Thank you very much!

In T179631#2577768, @BIS_fnc_KK wrote:

There is no designed support for nils or other missing params, the fact that it worked is a coïncidence. I will have a look if this could be turned into feature.

It would be very nice to see the following be implemented:

I can confirm this has been fixed in profiling branch 2.14.151142.

I understand it's how the game works, however when disassembled a drone should be hidden from the zeus interface, to prevent issues.

This issue is still present it seems. However, I can't' provide proper steps to replicate, as the server where it occurred is modded. All I know is that upon exiting the ACE Arsenal, some code (written by me, not ACE) which boils down to player setUnitLoadout getUnitLoadout player is run, which I believe causes the desync issue.

In T126030#2481963, @johnb43 wrote:

Unfortunately still broken in rev 150832.

Unfortunately still broken in rev 150832.

I can confirm that this issue has been addressed, can be closed.

This can be closed, it's been addressed.

player addWeapon "vn_m79_p";
player addWeaponItem ["vn_m79_p", ["vn_40mm_m576_buck_mag", 1, "vn_m79_p_shot_muzzle"], true];
getUnitLoadout player select 2 // Returns ["vn_m79_p","","","",[],["vn_40mm_m576_buck_mag",1],""]

That's fixed.

In T173880#2475399, @BIS_fnc_KK wrote:

getArray (configFile >> "CfgWeapons" >> "vn_m79_p" >> "muzzles")

what does this return?

Thank you very much.

In T173880#2475226, @BIS_fnc_KK wrote:

So one more question, does weaponsItems show both magazines for the handgun if both loaded and in the correct order?

Is this a secondary muzzle mag showing as primary muzzle but not being loaded at all? or is it added to secondary muzzle but shows in primary muzzle array? Is it the only mag in the weapon? What happens if you have both mags

In T173880#2474725, @BIS_fnc_KK wrote:

player addWeapon "vn_m79_p";

nothing is added, cannot repro

After a small message exchange with Dedmen, he told me to include all the following information in the ticket:

In T167534#2363144, @NeilZar wrote:

Do you have an example for cases where it returns duplicates?

This ticket can be closed, as it has been addressed.

In T128594#2361731, @BIS_fnc_KK wrote:

I have edited it to the correct description already, don’t think you need a note

In T128594#2361373, @BIS_fnc_KK wrote:

Well, not sure why it even worked in the first place. The syntax of the action was wrong, and it doesnt take any additional arguments apart from the unit which player controls. https://community.bistudio.com/wiki/Arma_3:_Actions#BackFromUAV I corrected the syntax on wiki, please let me know if it works in all cases

In T128594#2361078, @BIS_fnc_KK wrote:

This is still broken for 2.10, would be nice if this could be addressed.

Repro please @johnb43

This is still broken for 2.10, would be nice if this could be addressed.

getUnitFreefallInfo takes a local argument, not a remote one, even though setUnitFreeFallInfo has a global effect.
If there is a bug, you have to check by switching locality on a unit (which can be only done with an AI) - like this:

I can confirm that this issue has been addressed, I think this ticket can be closed.

As far as I can tell, this issue has been addressed, I haven't had any crashes since.
For me, this ticket can be closed.

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.

I like the new syntax of actionKeys. It makes some things previous impossible possible. However I have a request:

In T161512#2256705, @Tenshi wrote:

Thanks for the response. Which weapon did you choose to crash yourself with, in your test without mods?
I want to see if I'm able to reproduce it on my device.
Edit: https://youtu.be/Q5FTMVSJJN0 this is my repro attempt on Profiling. Am I doing the same as what causes your crash?

In T161512#2256550, @Tenshi wrote:

Tested on Profiling build 2.06.148478
Tested the script with only CBA and CUP weapons loaded, had no crashes or freezing while preforming the repro.
Can you test if the issue persists on profiling for you?

In T161512#2248989, @BIS_fnc_KK wrote:

I forgot to mention that I managed to reproduce this bug on a different computer with the 2.04 legacy branch and the 2.06 stable branch.

Could you please provide a repro with no mods loaded. The mods might have lb event handlers set which could conflict with lbClear and thus cause crash. Not much we can do about that. However if the crash happens in vanilla content, we can investigate the cause more thoroughly. Thanks

In T161512#2248956, @BIS_fnc_KK wrote:

have you reported this issue to CUP and RHS?

In T161512#2248183, @dedmen wrote:

cma_x64AVX2!cma_x64AVX2 [fail:0]

crash is in your custom cma_x64AVX2 memory allocator, try not using that, that will probably fix it.
Also get rid of your -maxvram=6000 start parameter, thats nonsense.

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.