Array Addition Operator

[Defunkt 431]

use magazines[] += {""};

In my experience (with the current Stable branch) that operator is bugged, it works fine for the first addition but subsequent additions start with only the entries added by the previous usage. Robalo posted the same finding quite a while back; http://forums.bistudio.com/showthread.php?167522-ASDG-Joint-Rails&p=2543630&viewfull=1#post2543630. It may not matter much in this particular case but I think there are grounds for avoiding it in general. I rather suspect this operator might be behind RHS's erratic support for attachment interoperability (probably subject to mod load order) and why we still need ASDG JointRails (EDIT: So I went and had a look and there don't appear to be any instances of the += operator in the RHS configs - though nor are there any asdg entries either).

Edited December 2, 2014 by Defunkt

[da12thMonkey 1943]

In my experience (with the current Stable branch) that operator is bugged, it works fine for the first addition but subsequent additions start with only the entries added by the previous usage. Robalo posted the same finding quite a while back; http://forums.bistudio.com/showthread.php?167522-ASDG-Joint-Rails&p=2543630&viewfull=1#post2543630. It may not matter much in this particular case but I think there are grounds for avoiding it in general. I rather suspect this operator might be behind RHS's erratic support for attachment interoperability (probably subject to mod load order) and why we still need ASDG JointRails (EDIT: So I went and had a look and there don't appear to be any instances of the += operator in the RHS configs - though nor are there any asdg entries either).

Have you tried it recently with the latest tools? I've been using the += operator to add several optics from separate .pbos and configs to the 4-Five pistol's TOP slot (a weapon that isn't ASDG JR compatible, and still uses the old compatibleitems[] array) without any conflicts. I've also seen the operator used in a couple of mods to add new throwable weapons to the vanilla Arma 3 units without overwriting their standard weapons[] array (AGM among others).

As far as I can tell it works properly now.

RHS's JointRail support is erratic because the weapons that appear to be JR-compatible are only inheriting JR rail slot definitions from the MX and other BIS weapons that Robalo added them to. The RHS attachments aren't JR compatible (so don't attach to 3rd party JR compatible weapons) and the RHS weapons themselves don't have explicit support for JR either.

[Defunkt 431]

As far as I can tell it works properly now.

Still happening for me though it's always possible it's related to my particular application (but which should be legal AFAIK). Described in the spoiler;

For me this (replace the entire array to make the first addition and then inherit and make a further addition) works;

class RscUnitInfoTank: RscUnitInfo {Controls[] = {"WeaponInfoControlsGroupRight", "CA_Zeroing", "CA_BackgroundVehicle", "CA_BackgroundVehicleTitle", "CA_BackgroundVehicleTitleDark", "CA_BackgroundFuel", "CA_Vehicle", "CA_VehicleRole", "CA_HitZones", "CA_VehicleTogglesBackground", "CA_VehicleToggles", "CA_SpeedBackground", "CA_SpeedUnits", "CA_Speed", "CA_ValueFuel", "CA_Radar", "FUNK_RadarOverlay"};};

class RscUnitInfoTankEast: RscUnitInfoTank {Controls[] += {"FUNK_RadarOverlayEast"};};

Both HUDs display with all elements. However the following (use += to make the first addition then inherit with a further addition) doesn't;

class RscUnitInfoTank: RscUnitInfo {Controls[] += {"FUNK_RadarOverlay"};};

class RscUnitInfoTankEast: RscUnitInfoTank {Controls[] += {"FUNK_RadarOverlayEast"};};

In this case the first HUD displays with all elements but the second only has the two additions (and a dump of the whole config tree confirms this). After finding this I went hunting and turned up Robalo's post which appears to describe the same thing.

[.kju 3240]

@ Defunkt

Your example is confusing.

You can only apply += on existing parameters definitions. Otherwise it will turn += into a = and thus break inheritance.

BI is aware of this issue.

[Defunkt 431]

;2832185']@ Defunkt

Your example is confusing.

You can only apply += on existing parameters definitions. Otherwise it will turn += into a = and thus break inheritance.

BI is aware of this issue.

Not sure what you mean by existing parameters definitions. In my example controls[] is an existing member of the RscUnitInfoTank class. I had hoped to add an item to this array (in the original class) and also derive a new class based on that and make a further addition. It's not clear to me why either change will work individually (i.e. the syntax is legal and functional both in the case of an initial addition and also in the case of a derivation with addition) but not stacked.

Edited December 4, 2014 by Defunkt

[.kju 3240]

Sample:

config 1
class A
array[] = {"stuff"}
class B:A
//array[] not defined 

config 2
class B:A
array[] += {"anotherStuff"}

= 
class B:A
array[] = {"anotherStuff"} //bad - current situation

desired would be that it makes a look-up what array[] is for class B from inheritance and adds to it => array[] = {"stuff","anotherStuff"}

[Defunkt 431]

Well that's a bit disappointing, and slightly confusing given that your example will work if it's all in the one config, presumably because binarize will find the definition in the parent class and write the amended array out in full (a pity that the game itself can't do the same).

Edited December 4, 2014 by Defunkt

[.kju 3240]

Unless you can show otherwise, having it in one config doesn't make any difference:

config 1
class A
array[] = {"stuff"}
class B:A // first definition of class B
array[] += {"anotherStuff"}

= 
class B:A
array[] = {"anotherStuff"} //bad - current situation

desired would be that it makes a look-up what array[] is for class B from inheritance and adds to it => array[] = {"stuff","anotherStuff"}

[Defunkt 431]

Well this does;

class RscUnitInfoTank: RscUnitInfo {Controls[] = {"WeaponInfoControlsGroupRight", "CA_Zeroing", "CA_BackgroundVehicle", "CA_BackgroundVehicleTitle", "CA_BackgroundVehicleTitleDark", "CA_BackgroundFuel", "CA_Vehicle", "CA_VehicleRole", "CA_HitZones", "CA_VehicleTogglesBackground", "CA_VehicleToggles", "CA_SpeedBackground", "CA_SpeedUnits", "CA_Speed", "CA_ValueFuel", "CA_Radar", "FUNK_RadarOverlay"};};

class RscUnitInfoTankEast: RscUnitInfoTank {Controls[] += {"FUNK_RadarOverlayEast"};};

Isn't that the same as the case you describe?

[.kju 3240]

please make a config dump of RscUnitInfoTankEast

PS: Would be nice to ask a forum mod to extract our discussion to a new thread in config forums. :)

[Defunkt 431]

It's binarize. If I de-pbo the addon the config then looks like;

class RscUnitInfoTankEast: RscUnitInfoTank

{

Controls[] = {"WeaponInfoControlsGroupRight","CA_Zeroing","CA_BackgroundVehicle","CA_BackgroundVehicleTitle","CA_BackgroundVehicleTitleDark","CA_BackgroundFuel","CA_Vehicle","CA_VehicleRole","CA_HitZones","CA_VehicleTogglesBackground","CA_VehicleToggles","CA_SpeedBackground","CA_SpeedUnits","CA_Speed","CA_ValueFuel","CA_Radar", "FUNK_RadarOverlay", "FUNK_RadarOverlayEast"};

};

Not terribly useful, just saves on a bit of typing.

Have requested a split of our discussion.

[da12thMonkey 1943]

Still happening for me though it's always possible it's related to my particular application (but which should be legal AFAIK). Described in the spoiler;

For me this (replace the entire array to make the first addition and then inherit and make a further addition) works;

class RscUnitInfoTank: RscUnitInfo {Controls[] = {"WeaponInfoControlsGroupRight", "CA_Zeroing", "CA_BackgroundVehicle", "CA_BackgroundVehicleTitle", "CA_BackgroundVehicleTitleDark", "CA_BackgroundFuel", "CA_Vehicle", "CA_VehicleRole", "CA_HitZones", "CA_VehicleTogglesBackground", "CA_VehicleToggles", "CA_SpeedBackground", "CA_SpeedUnits", "CA_Speed", "CA_ValueFuel", "CA_Radar", "FUNK_RadarOverlay"};};

class RscUnitInfoTankEast: RscUnitInfoTank {Controls[] += {"FUNK_RadarOverlayEast"};};

Both HUDs display with all elements. However the following (use += to make the first addition then inherit with a further addition) doesn't;

class RscUnitInfoTank: RscUnitInfo {Controls[] += {"FUNK_RadarOverlay"};};

class RscUnitInfoTankEast: RscUnitInfoTank {Controls[] += {"FUNK_RadarOverlayEast"};};

In this case the first HUD displays with all elements but the second only has the two additions (and a dump of the whole config tree confirms this). After finding this I went hunting and turned up Robalo's post which appears to describe the same thing.

Oh I get you. There's obviously a problem with inheriting += additions to a parent class, in their child classes. As yet, I've not tried making any child classes for the weapon I've appended the arrays for, to see how the additional indexes carry over.

Possibly += operator cannot process the inheritance properly when both the parent and child classes are in the same config.cpp.

I'd suggest perhaps putting the child class RscUnitInfoTankEast in a separate config.cpp (in a subfolder of the your .pbo) that references the other/parent config in cfgPatches/requiredaddons[] and see if binarisation will then processes the full inheritance.

Edited December 4, 2014 by da12thMonkey

[.kju 3240]

Well that behavior is even worse. :O

This way the array gets hardcoded again and conflicts with other mods.

To me this is a bug or design error. (on-top of the other mentioned above).

[mikero 79]

perhaps this will help, and end the confusion:

last time i tested += it ONLY OPERATES AS FOLLOWS:

the inherited class MUST HAVE THE array[]= {...};

this operator does NOT do any further recursion than that. AND, this parent class MUST be as above. (ie another += in it will not help you)

in short

class A:who_cares

{

array[]={any,thing};

};

class b:A // in this or ANY other config.cpp

{

array[]+={more,stuff};

};

no other combination will work. Period

You can spend a lot of time agonizing over this, saying either that's crazy, or i must be stupid. Or, accept it.

Note that there's a huge caveat here, that this was the last time I looked (and tried to implement it). Like most, I considered it useless and haven't checked in later engine revisions.

There's also a side comment here of no real relevance that in implementing += in binary rap code they bazongled the format. It is contrary to every other token construct (which happen to be consistent and uniform). That may or may not cause trouble in the multiple code fragments in their engine that try and read rap code in a uniform manner.

Edited December 4, 2014 by Mikero

[legman 10]

interesting!