Arma 3 weapons config guidelines

[kuIoodporny 45]

While the new system is way better than the old one, I still think that it isn't the right solution. The problem is that this means any attachment can be put on any weapon, or the weapon itself needs to (again) cope with individual attachment. While the guns in the game currently have all Picatinny rails, this is not going to be true for e.g. Russian guns with Dovetail mounts.This isn't how attachments work in reality. I would really have liked to see something like this since it models how attachments are used in reality (i.e. the rail on the weapon determines whether I can mount it or not).

I still forseee trouble with this method. Some attachments will work on weapons that they shouldn't work on because they are not specifically excluded, and some won't work although they should. With a rail system, that issue would not exist.

In any case, though, I am happy that we don't need extra configs anymore.

Oh come on, if you have completely different attachment system, you don't use BIS CowsSlot but create new class with compatible attachments class and array.

class CowsSlot;
class my_sweet_RussianOpticsSlot: CowsSlot {
class compatibleItems {
my_sweet_PSO1 = 1;
my_sweet_PGO7 = 1;
my_sweet_Kobra = 1;
};
};

Then in CfgWeapons >> weapon >> WeaponSlotsInfo you just inherit the my_sweet_russianoptics:

class CfgWeapons {
class Rifle;
class Rifle_Base_F: Rifle {
class WeaponSlotsInfo;
};
class my_sweet_rifle_base: Rifle_Base_F {
class WeaponSlotsInfo: WeaponSlotsInfo {
class CowsSlot: my_sweet_RussianOpticsSlot {};
};
};

Note I may have made error in classnames, you need to check yourself.

[Alwarren 2767]

Oh come on, if you have completely different attachment system, you don't use BIS CowsSlot but create new class with compatible attachments class and array.

The question has already been raised, does that actually work? How is the slot attached to the slot in the inventory? Does the name matter?

[pettka 694]

The question has already been raised, does that actually work? How is the slot attached to the slot in the inventory? Does the name matter?

	class InventoryOpticsItem_Base_F: InventoryItem_Base_F
{
	type = 201;
};

I hope that does explain the questions enough :icon_twisted:

[roberthammer 582]

Got some questions:

Is this good?

class SlotInfo;
class CowsSlot;
class CowsSlot: CowsSlot 
{
 class compatibleItems
 {
   optic_Nightstalker = 1;
   optic_tws = 1;
   optic_tws_mg = 1;
   optic_NVS = 1;
   optic_DMS = 1;
   optic_SOS = 1;
   optic_MRCO = 1;
   optic_Arco = 1;
   optic_aco = 1;
   optic_ACO_grn = 1;
   optic_aco_smg = 1;
   optic_ACO_grn_smg = 1;
   optic_hamr = 1;
   optic_Holosight = 1;
   optic_Holosight_smg = 1;
   custom_optic = 1;
   custom_optic2 = 1;
   custom_optic3 = 1;
 };
};

or i did something wrong? also is this enough to make it compatible with other packs?

[Alwarren 2767]

    class InventoryOpticsItem_Base_F: InventoryItem_Base_F
   {
       type = 201;
   };

I hope that does explain the questions enough :icon_twisted:

Very interesting. Yes, indeed, that does explain it. Thanks for the info!

[kuIoodporny 45]

or i did something wrong? also is this enough to make it compatible with other packs?

Please try

class SlotInfo;
class CowsSlot: SlotInfo {
class compatibleItems {
   custom_optic = 1;
   custom_optic2 = 1;
   custom_optic3 = 1;
};
};

[Alwarren 2767]

or i did something wrong? also is this enough to make it compatible with other packs?

I was wondering the same. Wouldn't

class CowsSlot;

class CowsSlot: CowsSlot

be a duplicate class?

EDIT:

class SlotInfo; class CowsSlot: SlotInfo { class compatibleItems {     custom_optic = 1;     custom_optic2 = 1;     custom_optic3 = 1; };

Will that leave the default optics intact?

Edited October 8, 2013 by Alwarren

[roberthammer 582]

Please try

Hmm interesting , thx for info

---------- Post added at 17:20 ---------- Previous post was at 17:03 ----------

Tried it with that config and i cant attach the custom optics on BIS weapons

[da12thMonkey 1943]

Are you putting the code that zGuba posted inside class cfgweapons or outside of it?

The base class CowsSlot is outside of cfgweapons so I think the above code needs to be outside of it also.

Also, do you have requiredAddons[] = {"A3_Weapons_F"}; in class cfgPatches

[roberthammer 582]

Are you putting the code that zGuba posted inside class cfgweapons or outside of it?

The base class CowsSlot is outside of cfgweapons so I think the above code needs to be outside of it also.

Also, do you have requiredAddons[] = {"A3_Weapons_F"}; in class cfgPatches

Yes , i got it outside + requiredAddons[] = {"A3_Weapons_F","A3_Weapons_F_Acc"};

[Sniperwolf572 758]

Ok, here's my experiments, so far this works great.

I added a new rail type, called it "Bulls" for fun. "Bulls" rail only takes my test optic and the BI ACO optic, nothing else.

Cloned the ACO optic as a new "optic_Test".

Made a new weapon, a clone of MX, overwrote it's "Cows" slot so it doesn't inherit that, and added the "Bulls" slot.

class CfgPatches {

class railsTest {
	units[] = {};
	weapons[] = {};
	requiredAddons[] = {"A3_Weapons_F","A3_Weapons_F_Acc"};
	version = "0.0.1";
};

};

// Make a new "Rail" type that uses the TOP proxy
class SlotInfo;
class BullsSlot : SlotInfo {
linkProxy = "\A3\data_f\proxies\weapon_slots\TOP";

displayName = "Bulls Slot";

class compatibleItems {
	optic_ACO = 1;
	optic_Test = 1;
 };
};

class CfgWeapons {

class ItemCore;
class InventoryOpticsItem_Base_F;

       // Make a new optic, clone the ACO config stuff
class optic_Test: ItemCore {
	scope = 2;
	displayName = "Optic Test (Bulls)";
	picture = "\A3\weapons_F\Data\UI\gear_acco_aco_CA.paa";
	model = "\A3\weapons_f\acc\acco_Aco_F";
	descriptionShort = "Advanced Collimator Optics<br />Color: Bulls";
	weaponInfoType = "RscWeaponZeroing";

	class ItemInfo: InventoryOpticsItem_Base_F {
		mass = 2;
		modelOptics = "\A3\Weapons_F\empty";
		optics = 1;

		class OpticsModes {

			class ACO {
				opticsID = 1;
				useModelOptics = 0;
				opticsZoomMin = 0.375;
				opticsZoomMax = 1.1;
				opticsZoomInit = 0.75;
				memoryPointCamera = "eye";
				opticsFlare = 0;
				opticsDisablePeripherialVision = 0;
				distanceZoomMin = 200;
				distanceZoomMax = 200;
				cameraDir = "";
				visionMode[] = {};
				opticsPPEffects[] = {""};
			};

		};

	};
};

       // Make a new rifle, inherit from MX
class arifle_MX_F;
class WeaponSlotsInfo;
class PointerSlot;
class arifle_Test_F : arifle_MX_F {

	displayName = "Weapon Test (Bulls)";

	class WeaponSlotsInfo: WeaponSlotsInfo
	{
		class MuzzleSlot: SlotInfo
		{
			linkProxy = "\A3\data_f\proxies\weapon_slots\MUZZLE";
			compatibleItems[] = {"muzzle_snds_h"};
		};
                       // Deny the Cows Slot for this weapon
		class CowsSlot {

		};
                       // Attach the new Slot
		class BullsSlot: BullsSlot
		{
		};
		class PointerSlot: PointerSlot
		{
		};
	};

};

};

Edited October 8, 2013 by Sniperwolf572

[frederf 0]

Looking at the attachment topic from a distance I don't believe that the proposed change fully satisfies the desired behavior of the attachment system.

Attachments should perform under the following scenarios:

1. Default weapons with default attachments

2. Addon weapons with default attachments

3. Default weapons with addon attachments

4. Addon weapons with addon attachments

Unless I'm missing something none of the proposed or implemented solutions deal with these 4 cases simultaneously. For blind interoperability we cannot use bespoke code. A weapon addon developer and an attachment addon developer must be able to release in complete ignorance of each other and still have the result make sense. In times of complicated problems simulating reality I always ask myself "How did reality conquer the problem?" Ultimately it is overly difficult and counter productive to have an imaginative solution that is separate from reality.

Of course in reality items are often produced in a strict before-after pattern where bespoke "this is for that" thinking works. However there exists independent development of items which adhere to a common standard. The previous case is a special example of the latter where the first item unwittingly created a standard for the second. The MIL-STD-1913 (Picatinny) rail is a prime example of this. I can see no practical alternative other than establishing intermediate standards with which both weapons and attachments communicate compatibility.

Despite the need for standard attachment point types, there's no reason to explicitly state those standards in a new separate construct. Instead let us utilize the hierarchical class structure to create an assumed standard by example of attachment class. This should lower the variable overhead and leverage the powerful nature of class structures. The attachment point standard is defined by the parent attachment class and referenced by same.

For example

CfgWeapons{

Rifle {

{

attachment_point_type = p_rail_item

};

};

};

CfgAttachments {

NewItem : p_rail_item{

new code

};

};

RCO_optic isTypeOf p_rail_optic isTypeOf p_rail_item

Thus a new weapon addon can specify that its attachment point accepts p_rail_item and all child classes are already permitted by class structure. New weapon addons and attachment addons can now be made separately and be instantly compatible.

I have anticipated a number of questions and issues so I'll pre-respond to as many as possible here:

Q1. Doesn't this allow non-nonsensical item-point combinations?

A1. Depends but yes. Unless the item classes are branched early into bipod, optic, flashlight, etc. then there's nothing preventing someone putting a bipod on top of their rifle where an optic would normally be. Before you panic and start devising restrictions... relax. Humans (and scripts) are the only ones messing with which item goes in what slot. No one will find an optic not in the sight axis useful so while it's physically possible it's of no real concern and isn't worth creating needless inflexibility to restrict.

Q2. What about different size attachment points of the same standard?

A2. Then they aren't the same standard. One would use subclasses of the standard to allow small items on a big point but not big items on a small point. p_rail_long isTypeOf p_rail for example.

Q3. How does scripting know where to put attachments if they are blindly added to a multi-point weapon?

A3. I don't know. There are ways it could do best guess or in a certain order.

Q4. How can such permissiveness be balanced?

A4. As per reality: applying dexterity penalties within the item to make SMG+sniper scope physically impractical

Q5. How are exclusions possible?

A5. With a separate definition of excluded attachment(s) type(s)

Q6. What if several separate class branches should be permitted but not its single parent?

A6. Permitted types would be a list of classes

Additionally I think GL subweapons should be an attachment, perhaps with a player lock (or tool requirement?). We need more interactivity with our attachments like zeroing, removing magazines, etc. Items should have a value for attachment time (not instant). Interacting with attachments should be done in a pop up dialog and not the rigid inventory screen as current as this restricts feature growth. Paint should be an attachment. Barrels for MGs (overheating) could be exchanged thus. Jamming could require interaction at the GUI level.

Edited October 8, 2013 by Frederf

[2fast 11]

Looking at the attachment topic from a distance I don't believe that the proposed change fully satisfies the desired behavior of the attachment system.

Attachments should perform under the following scenarios:

1. Default weapons with default attachments

2. Addon weapons with default attachments

3. Default weapons with addon attachments

4. Addon weapons with addon attachments

Unless I'm missing something none of the proposed or implemented solutions deal with these 4 cases simultaneously. For blind interoperability we cannot use bespoke code. A weapon addon developer and an attachment addon developer must be able to release in complete ignorance of each other and still have the result make sense. In times of complicated problems simulating reality I always ask myself "How did reality conquer the problem?" Ultimately it is overly difficult and counter productive to have an imaginative solution that is separate from reality.

Of course in reality items are often produced in a strict before-after pattern where bespoke "this is for that" thinking works. However there exists independent development of items which adhere to a common standard. The previous case is a special example of the latter where the first item unwittingly created a standard for the second. The MIL-STD-1913 (Picatinny) rail is a prime example of this. I can see no practical alternative other than establishing intermediate standards with which both weapons and attachments communicate compatibility.

Despite the need for standard attachment point types, there's no reason to explicitly state those standards in a new separate construct. Instead let us utilize the hierarchical class structure to create an assumed standard by example of attachment class. This should lower the variable overhead and leverage the powerful nature of class structures. The attachment point standard is defined by the parent attachment class and referenced by same.

For example

CfgWeapons{

Rifle {

{

attachment_point_type = p_rail_item

};

};

};

CfgAttachments {

NewItem : p_rail_item{

new code

};

};

RCO_optic isTypeOf p_rail_optic isTypeOf p_rail_item

Thus a new weapon addon can specify that its attachment point accepts p_rail_item and all child classes are already permitted by class structure. New weapon addons and attachment addons can now be made separately and be instantly compatible.

I have anticipated a number of questions and issues so I'll pre-respond to as many as possible here:

Q1. Doesn't this allow non-nonsensical item-point combinations?

A1. Depends but yes. Unless the item classes are branched early into bipod, optic, flashlight, etc. then there's nothing preventing someone putting a bipod on top of their rifle where an optic would normally be. Before you panic and start devising restrictions... relax. Humans (and scripts) are the only ones messing with which item goes in what slot. No one will find an optic not in the sight axis useful so while it's physically possible it's of no real concern and isn't worth creating needless inflexibility to restrict.

Q2. What about different size attachment points of the same standard?

A2. Then they aren't the same standard. One would use subclasses of the standard to allow small items on a big point but not big items on a small point. p_rail_long isTypeOf p_rail for example.

Q3. How does scripting know where to put attachments if they are blindly added to a multi-point weapon?

A3. I don't know. There are ways it could do best guess or in a certain order.

Q4. How can such permissiveness be balanced?

A4. As per reality: applying dexterity penalties within the item to make SMG+sniper scope physically impractical

Q5. How are exclusions possible?

A5. With a separate definition of excluded attachment(s) type(s)

Q6. What if several separate class branches should be permitted but not its single parent?

A6. Permitted types would be a list of classes

Additionally I think GL subweapons should be an attachment, perhaps with a player lock (or tool requirement?). We need more interactivity with our attachments like zeroing, removing magazines, etc. Items should have a value for attachment time (not instant). Interacting with attachments should be done in a pop up dialog and not the rigid inventory screen as current as this restricts feature growth. Paint should be an attachment. Barrels for MGs (overheating) could be exchanged thus. Jamming could require interaction at the GUI level.

I fully agree with you idea. Esp

A weapon addon developer and an attachment addon developer must be able to release in complete ignorance of each other and still have the result make sense.

This is why we have common standard/protocols to follow in literally anything. Because I do not want to modify the config of a default weapon or addon weapon to get additional attachment working on them. We need a interface to determine the compatibility of a weapon to an attachment, and that is the rail as suggested.

Hope BIS can further look into it :)

[Sniperwolf572 758]

Please try

class SlotInfo;
class CowsSlot: SlotInfo {
class compatibleItems {
   custom_optic = 1;
   custom_optic2 = 1;
   custom_optic3 = 1;
};
};

Tried it with that config and i cant attach the custom optics on BIS weapons

I managed to make this work for custom SlotInfo's that start out with the new syntax, but not the BI ones that use the old syntax. We're probably going to have to wait for BI to update their SlotInfo's before we can extend them like this.

The new syntax seems really nice, and slotInfo basically acts as "CfgRails" that's been proposed.

[.kju 3244]

You can remove defintions with delete parameter; or delete className; (as long they have no childs).

[Alwarren 2767]

I managed to make this work for custom SlotInfo's that start out with the new syntax, but not the BI ones that use the old syntax. We're probably going to have to wait for BI to update their SlotInfo's before we can extend them like this.

It seems to work if you do both the CowsSlot and the PointerSlot.

However, if I do this:

class SlotInfo;
class CowsSlot: SlotInfo {
   linkProxy = "\A3\data_f\proxies\weapon_slots\TOP";
   displayName = "$STR_A3_CowsSlot0";
   class compatibleItems {
       FHQ_optic_ACOG = 1;
       FHQ_optic_ACOG_tan = 1;
       FHQ_optic_AIM = 1;
       FHQ_optic_AIM_tan = 1;
       FHQ_optic_TWS3050 = 1;

       FHQ_optic_HWS = 1;
       FHQ_optic_HWS_tan = 1;
       FHQ_optic_HWS_G33 = 1;
       FHQ_optic_HWS_G33_tan = 1;
       FHQ_optic_MicroCCO = 1;
       FHQ_optic_MicroCCO_tan = 1;
       FHQ_optic_MicroCCO_low = 1;
       FHQ_optic_MicroCCO_low_tan = 1;
       FHQ_optic_LeupoldERT = 1;
       FHQ_optic_LeupoldERT_tan = 1;
   };
};

class PointerSlot: SlotInfo
{
   linkProxy = "\A3\data_f\proxies\weapon_slots\SIDE";
   displayName = "$STR_A3_PointerSlot0";
   class compatibleItems {
       FHQ_acc_ANPEQ15 = 1;
       FHQ_acc_LLM01L = 1;
       FHQ_acc_LLM01F = 1;
   };
};

I can use my attachments on BIS weapons but not the original BIS attachments. Of course I could add them, but then another addon pack will mess things up again. Unless I am overlooking something, we're still stuck with the same problem as before.

Any ideas?

[.kju 3244]

You seem to have a wrong idea how configs work.

In general each config adds or updates the complete config tree.

The load order defines what entry is to be active in the end.

[Sniperwolf572 758]

Any ideas?

Well, I did it a bit differently. I figured a "Joint Rails Project" might end up being useful so we avoid everyone having to support everything, but instead weaponmakers could use JRP rails and attachment makers could add their attachments to JRP rails.

Linked below is a zip that contains my little experiment, one of the pbo's is "JRP" itself and other two are "configuration plugins" for IanSky's optics and FHQ optics. Using both "config plugins" with the JRP results in interchangeable optics on BI weapons and any weapon that would in the future, in addition to BI rails, use the JRP rails.

Here are the pbo's and here is the source so you don't have to unpack it.

If anyone has any interest on expanding this with me to make it something that community could actually use, let me know, as I'm probably committing some config genocide without knowing it, as cross-config inheritance is still a bit blurry to me, but I'm learning. :)

Edited October 9, 2013 by Sniperwolf572

[.kju 3244]

A few comments:

class WeaponSlotsInfo {

You have to make sure to use the same definition BI added for their classes:

class arifle_Katiba_Base_F: Rifle_Base_F

class WeaponSlotsInfo: WeaponSlotsInfo

Otherwise you are breaking the inheritance.

class compatibleItems;

Is just parent definition for inheritance - for the initial definition you need to remove it or define:

class compatibleItems: compatibleItems {};

[Alwarren 2767]

;2530470']You seem to have a wrong idea how configs work.

In general each config adds or updates the complete config tree.

The load order defines what entry is to be active in the end.

Please elaborate? That is what I was saying. My config overrides the one in the game files, meaning that my definition of CowsSlot and PointerSlot overwrites not extends or augments the original one. Any addon that comes after me does the same.

What I am looking for is a solution to the problem that to combine accessories packs you gotta have X amount of configs that "activate" Y different combinations of packs.

So again, to reiterate, how would I get said effect, namely that if there is addon pack #1 and addon pack #2, I can load both and get the accessories from both packs? Because, as I see it, that was the major concern with the old system, and this is what the new system should fix. Only that so far I don't see how it does.

Note, I say "I don't see how". I am not saying it doesn't (just to ward against some rabid comments from the usual suspects).

[.kju 3244]

One overwrites value's of parameters, classes can only be expanded (by additional parameters) (or reduced via delete parameterX; ).

Overwrite: parameterA = valueX; vs parameterA = valueY;

however

Expand: parameterA = ...; and parameterB = ...; and parameterC = ...;

In other words you can adjust BI configs to whatever you like, I can do too, someone else too.

It is just a matter who's config gets loaded last decides which value for a given parameter is active.

However additional parameter are always added, no matter what.

In the old system there were conflicts as the array with compatible optics could be just set by one config in the end,

whereas now you have each optic as a separate parameter.

Edited October 10, 2013 by .kju [PvPscene]

[frederf 0]

I see why this is helpful because types = {item1, item2, item3,...} can't be updated because the array is a single value. If they are separate variables then you can update the class tree without having to completely replace the single array in the single variable location.

[roberthammer 582]

Is there a way to reduce the light from the suppressors? i know from arma 1/2 - it was the fireLightDuration = 0.000000; fireLightIntensity = 0.000000;

but am not sure if this works in arma 3 (muzzleitem class) , can you somebody help with this?

Edited October 30, 2013 by RobertHammer

[da12thMonkey 1943]

Don't think there is Rob. It's been mentioned a couple of times on the feedback tracker.

[abs 2]

Is there a way to reduce the light from the suppressors? i know from arma 1/2 - it was the fireLightDuration = 0.000000; fireLightIntensity = 0.000000;

but am not sure if this works in arma 3 (muzzleitem class) , can you somebody help with this?

Those values still exist, but the thing is now that you can remove a suppressor, those values will most likely mean that your muzzle light is just gone from the weapon, period.

Abs