I was able to reproduce this issue reliably if and only if the USS Freedom and the Turret Centurion/Praetorian were outside the map area. Inside the map area, it seems to work fine (tested around the south map border of Tanoa).

@dedmen That's awesome!! Now let's hope BI gets around to this at some point :)

While it's probably difficult to get right it would be so worth it.

Duplicate of T116697

This is caused by two things:

I currently can't test this (no Arma-capable PC around) but I think this isn't Arsenal specific but instead happens with any sorted listbox. https://community.bistudio.com/wiki/lbSort just says it's "alphabetical" but doesn't specify the exact sort order so it might well do numbers before '<'

Duplicate of T116697

Duplicate of T116697

John and R3vo are on the right track here, imho: Eden GUI scale should be its own setting :)

I would like to see this functionality in game, too :)

Reproduced :(
Also, still present in 1.36 :(

I've come across this while attempting (and failing) to do the same work-around.
A command like this would greatly benefit not just "persistent" game styles but it'd also allow @Moricky to fix the Arsenal bug that weapons in backpacks loose their attachments when loading/importing a loadout.

@commy2

Thanks for the explanation. Could you give an example usage (with Throw)?
I'm still trying to get my head around this operator (out of mere interest as it seems a fairly niche thing).

Slightly off-topic: Is there already a feature-request to turn += into a more general tool that *could* handle things like adding a custom silencer to the MX's compatibleItems[]?

When you say "not meant to work with inherited classes" does that also include inheritance inside a single config file?
I.e. what will the following produce (single config file only):
config1:
class A {
property[] = [a,b];
};
class B: A {
property[] += [c];
};

I've run across this while working on a loadout saving script.
This is a really weird limitation. Maybe the current updates to attachments that are being done on DEV branch will introduce something for this as well?

EDIT: Would http://feedback.arma3.com/view.php?id=22000 work for your requirements?

You're half-right, Drakeziel.
It is true that 'pre-made composite' weapons are, by definition, weapons with classnames different from their base weapon. E.g. arifle_MX_pointer_F

However no weapon ever changes classname when you attach /detach something to it. Arma3 can happily have an arifle_MX_pointer_F gun and attach a flashlight/silencer/nothing/etc to it.
Also, taking a base weapon (arifle_MX_F) and adding a laserpointer does not turn it into an arifle_MX_pointer_F.

All this issue comes down to is that bis_fnc_arsenal calls bis_fnc_baseWeapon at a time where it shouldn't.

If you had read the comments above you, you'd know that composite weapons aren't some magic that inherently break Arma3, since I've posted that this bug can be resolved with a one-line change in bis_fnc_arsenal.
(Check out @Fixed_Arsenal for a mod that implements, among many other things, this fix)

This is down to the fact that in fn_arsenal.sqf, #define GETVIRTUALCARGO uses baseWeapon on each item. When changing the line in question (fn_arsenal.sqf:117) to "_weapon = _x;\" (note the lack of calling baseWeapon on _x) the arsenal performs as expected.

Since I didn't really look to deeply into the rest of the system this might break something subtle...but I haven't noticed anything yet.
The displayed list is still "clean" from multiples since that is checked differently.

I've "fixed" this for myself by overwriting fn_arsenal.sqf with a version that has that line changed via a small addon, which I've attached ["fixedArsenal.7z"] (folder name and config.cpp are inconsistent, so if you want to use it, update config.cpp and pbo it).

Hopefully this (or a more 'thoughtful' fix) makes it into the game soon :)

I encountered this same issue, specifically I wasn't able to load loadouts that contained a "composite" weapon, even if I added that composite weapon to the whitelist.

@Drakeziel: This issue stands as reported, I think you just misunderstood the issue.

This isn't about the 'Zeus Module' that a zeus player can drag onto a unit in order to open the arsenal UI on that unit.

This *is* about the ammo-box UI that Zeus can use to modify ammo-boxes.
In this UI, setting an items count to "infinity" should add it to the ammo-box's virtual inventory as well as add a "Virtual Arsenal" addAction.

"side" or "faction" of items/units does not play a role for this or any other interaction with bis_fnc_arsenal.

I think this has made it onto stable by now - I'm currently experiencing it in 1.30.127372

For anybody else who's stumbling across this:
You'll only see the exec field if 1.) it's not disabled via the "set Attributes" modules and 2.) enableDebugConsole is set to 1 or 2 in your description.ext

This isn't an actual inventory issue. This is about the ability to script-add weapons with (custom) attachments into containers.
These people were probably all playing mods that save player inventories.

Killzone_Kid: Could you please go into detail why you/SaMatra consider this expected behaviour? I'm guessing you might have a use-case for the double execution in mind, so I'm wondering what it is.

I've just encountered the freeze while trying to "PutWeapon" something into a unit's backpack :(
Alternatively, my issue would be solved if we could add[..]WeaponItem to weapons in containers..