If I recall correctly, this is all intended behavior of arrays. Arrays being passed by reference is one of their most valuable characteristics, and trying to change that would break a LOT of existing scripts, to no noteworthy benefit.

The biggest quirk that is probably throwing causing problems for you is how ARMA handles array addition and subtraction. When you do _array1 = _array1 - _array2;, you are actually creating a completely new array in the process, that just happens to contain the contents of _array1 minus the contents of _array2, then assigning _array1 to reference the new array. That's why the variable within the object didn't get changed by the subtraction, but did by the set. Set, select, and resize are the 3 commands that I can think of that for directly manipulating arrays, while addition and subtraction return copies.

And as you mentioned, using _newArray = +_oldArray; creates a copy of _oldArray and stores it's reference in _newArray, and gives you all the functionality you are asking for.

Edit: Relevant wiki article: http://community.bistudio.com/wiki/Array#Changing_an_array

To be honest Japapatramtara, if you can't come up with an easy alterative, I don't see too huge of an issue with the problem you presented, and would file it under "predictably unpredictable" behavior.

By that I mean that manipulating one container with both local and global commands will by nature cause some interesting behavior with locality, and trying to accomodate it may be more of a headache than it's worth.

For example, SaMatra presented the case of creating local crates on each client so every player can access a unique pool of gear. The crate would be created locally, then the items would be added locally. This is all done on the local client, so global commands' behavior would be a nonissue.

Ultimately, I agree with SaMatra's last point that the command may be working as intended now. If you offer both a local and a global version of the command, I would say it's the mission-maker's responsibility to ensure they use the correct commands. Unless I'm mistaken, the contents of a container shouldn't fall out of sync across clients unless explicitly caused by calling a non-global command. If I am forgetting some specific bugs or use scenarios where they do become desynced, then there may be an issue, but I imagine a container that is only manipulated by players and global commands will be identical on all clients, so a mission-maker being consistent would be golden.

I see, bit of reading/interpreting error on my part. Regardless, I'm not 100% comfortable with the deleteItemCargoGlobal means of removing items as, while it may work, it doesn't really seem to lend itself to a nice opposite/means of adding attached items. That's why I was proposing the pair of functions handle it.

In the same vein, the deleteMagazineCargoGlobal method may work for removing the magazine loaded into a gun, but it doesn't seem to have a viable opposite to load a magazine. The closest I could think of is something to the effect of:

<source_vehicle> assignMagazineCargoGlobal [<magazine_id>, <weapon_id>, <muzzle_id>];

Which would try to load a magazine from the container into a weapon. So a fixed version of my suggestion would probably, look something like (Not sure if removing a magazine requires the muzzle or not):

<source_vehicle> addWeaponCargoMagazine [<weapon_id>, <muzzle_id>, [<magazine_name>, <ammo>]];
<source_vehicle> removeWeaponCargoMagazine [<weapon_id>, <magazine_name>];

The other minor deviation on my suggestion is how getMagazineCargoDetails works. In your suggestion, you're having it return all magazines stored in the inventory of the container, then magazines inside the weapons stored in the container. But the ids of loaded magazines are also returned in getWeaponCargoDetails, so I would recommend removing them from one of the commands. Intuitively, I like having getMagazineCargoDetails return only magazines in the cargo space itself, and loaded magazines included in getWeaponCargoDetails.

And on a new note, as japapatramtara is saying here, http://feedback.arma3.com/view.php?id=14576#c57339, he intends to make all commands usable on items also usable on magazines and weapons, so deleteMagazineCargoGlobal may not even be necessary. Same applies to the moveItemCargoGlobal commands as well.

Other than that, all of the commands you've suggested are great ideas that would be a godsend for many of my little projects.

One other action that I don't think we can perform yet, but would be really nice to have, is directly manipulating the attachments and loaded magazines of weapons in containers. Through a bit of manipulation of the weaponsItems results we can get all important information about these weapons, but we can't set them as far as I'm aware. Following SaMatra's last few examples, something to the effect of:

<source_vehicle> addWeaponCargoItem [<weapon_id>, <attachment_name>];
<source_vehicle> removeWeaponCargoItem [<weapon_id>, <attachment_name>];
<source_vehicle> addWeaponCargoMagazine [<weapon_id>, [<magazine_name>, <ammo>]];
<source_vehicle> removeWeaponCargoMagazine [<weapon_id>, <magazine_name>];

Would be very handy. Fairly related to: http://feedback.arma3.com/view.php?id=4903