The Attachments rant

[da12thMonkey 1943]

If you want a different rail type tree can't you set up another slotsInfo type to use the TOP proxy for your weapon, with a name other than the default COWSslot (which is effectively our 'picatinny standard' sight rail), then bung in your own class compatibleitems into this new class?

Admittedly as a community we'd probably have to create some sort of base addon to add this slotsInfo class for all authors to add their different attachments to in a way that they could be shared and inherited by all weapons that use that rail type.

Edited October 8, 2013 by da12thMonkey

[Sniperwolf572 758]

If you want a different rail type can't you set up another slotsInfo type to use the TOP proxy for your weapon, with a name other than the default COWSslot (which is effectively our 'picatinny standard' sight rail), then bung in your own class compatibleitems into this new class?

Admittedly as a community we'd probably have to create some sort of base addon to add this slotsInfo class for all authors to add their different attachments to in a way that they could be shared and inherited by all weapons that use that rail type.

Depends on if the engine is only reliant on the proxy definition to decide what to do with the attachment in regards to the inventory and what type of an attachment can override what base values of a weapon.

Haven't experimented, can all the attachments modify all the values of the base weapon? For example, can an optic attachment modify the muzzle velocity, spread, sound and such like the muzzle attachments seem to be able to?

[Alwarren 2765]

Depends on if the engine is only reliant on the proxy definition to decide what to do with the attachment in regards to the inventory and what type of an attachment can override what base values of a weapon.

Haven't experimented, can all the attachments modify all the values of the base weapon? For example, can an optic attachment modify the muzzle velocity, spread, sound and such like the muzzle attachments seem to be able to?

The compatibility with attachments is defined externally to the rifle itself, and I don't think that an optic has any influence on firing parameters.

What I am concerned about is that the naming of the slots might be tied to the specific inventory slots, which would make the base class per rail idea non-functional. Need to experiment with that, now that the new dev build is out.

[Sniperwolf572 758]

The compatibility with attachments is defined externally to the rifle itself, and I don't think that an optic has any influence on firing parameters.

What I am concerned about is that the naming of the slots might be tied to the specific inventory slots, which would make the base class per rail idea non-functional. Need to experiment with that, now that the new dev build is out.

I understand the compatibility, your second paragraph is exactly what I've tried to say. :) Going by the wiki, I'm afraid that's the case since they explicitly state that you can name the proxy to whatever you'd like and just alter it in the config.

[da12thMonkey 1943]

Depends on if the engine is only reliant on the proxy definition to decide what to do with the attachment in regards to the inventory and what type of an attachment can override what base values of a weapon.

Haven't experimented, can all the attachments modify all the values of the base weapon? For example, can an optic attachment modify the muzzle velocity, spread, sound and such like the muzzle attachments seem to be able to?

Well on the weapons config guidelines it says:

all these proxies could be redefined in cfgWeapons >> Weapon >> WeaponSlotsInfo >> XXX >> linkProxy parameter where XXX is the slot name

after explaining that the proxies should always use conventional names of SIDE, TOP and MUZZLE. This reads to me as though "XXX" can be anything, and we can make new slots using the standard three proxies, with different display names etc (why have a displayname parameter if we can't make new custom slots?).

It goes on to say:

external classes CowsSlot and PointerSlot are used for standard optics and side accessory. That means these classes are outside cfgWeapons and changeable for all weapons at once.

Which suggests CowsSlot etc. is just what is used for the default attachment set for weapons, rather than being the mandatory class associated with those proxies.

Edited October 8, 2013 by da12thMonkey

[goldenfiver 11]

From today's dev branch patch changelog:

•Added: Proposal for change in attachment configuration design for weapons. http://feedback.arma3.com/view.php?id=2766 + http://forums.bistudio.com/showthrea...=1#post2529306

Does this mean they are working on it?

[Sniperwolf572 758]

Well on the weapons config guidelines it says:

after explaining that the proxies should always use conventional names of SIDE, TOP and MUZZLE. This reads to me as though "XXX" can be anything, and we can make new slots using the standard three proxies, with different display names etc (why have a displayname parameter if we can't make new custom slots?).

It goes on to say:

Which suggests CowsSlot etc. is just what is used for the default attachment set for weapons, rather than being the mandatory class associated with those proxies.

Hmm, I read it differently. To me it sounds like the "XXX" there is a placeholder for either of the three slots (CowsSlot, PointerSlot, MuzzleSlot) and basically saying:

"We use MUZZLE, TOP and SIDE for proxy names in the model, but if you want to you can use whatever and change it with the linkProxy"

Which leaves the question of if you create

class VeryLongRailSlot : SlotInfo
{
	// targetProxy - can be changed to whatever as long that is the namedselection of the proxy
	linkProxy = "\A3\data_f\proxies\weapon_slots\TOP_LONG";
};

The engine has no idea what inventory slot to use (is it a muzzle slot info? optics? pointer?), which leads me to believe those three XXXSlot's are something we have to use, but MIGHT extend further if they're checking for the parent class instead of the exact class match.

Edited October 8, 2013 by Sniperwolf572

[Alwarren 2765]

Which suggests CowsSlot etc. is just what is used for the default attachment set for weapons, rather than being the mandatory class associated with those proxies.

What I don't quite get yet is how an acessories pack would override those. The only thing I can see is that the pack redefines the CowsSlot base class, because AFAIK it cannot just subclass it, but if that is required, then we're back at Square 1, since we need separate configs to enable combinations of packs.

What am I overlooking here?

[pettka 694]

Well on the weapons config guidelines it says:

after explaining that the proxies should always use conventional names of SIDE, TOP and MUZZLE. This reads to me as though "XXX" can be anything, and we can make new slots using the standard three proxies, with different display names etc (why have a displayname parameter if we can't make new custom slots?).

It goes on to say:

Which suggests CowsSlot etc. is just what is used for the default attachment set for weapons, rather than being the mandatory class associated with those proxies.

You are right :icon_twisted: I have just tested this:

		class WeaponSlotsInfo: WeaponSlotsInfo
	{
		mass = 20;		
		class OpticSlot
		{
		  linkProxy = "\A3\data_f\proxies\weapon_slots\TOP";
		  displayName = $STR_A3_CowsSlot0;
		  compatibleItems[] = {"optic_ACO"};
		}; 
	};

And it works fine - the weapon had the optic and it was working. Thanks a lot for reading the guidelines the way they were written :icon_twisted:

[Sniperwolf572 758]

You are right :icon_twisted: I have just tested this:

		class WeaponSlotsInfo: WeaponSlotsInfo
	{
		mass = 20;		
		class OpticSlot
		{
		  linkProxy = "\A3\data_f\proxies\weapon_slots\TOP";
		  displayName = $STR_A3_CowsSlot0;
		  compatibleItems[] = {"optic_ACO"};
		}; 
	};

And it works fine - the weapon had the optic and it was working. Thanks a lot for reading the guidelines the way they were written :icon_twisted:

I'm glad I was wrong, that's awesome. :D

So, the link for everything is the "linkProxy", which should mean that we can use the SlotInfo class as an "CfgRails".

Who wants to compile a list of possible rails so we can make it into an addon? :icon_twisted:

[pettka 694]

I'm glad I was wrong, that's awesome. :D

So, the link for everything is the "linkProxy", which should mean that we can use the SlotInfo class as an "CfgRails".

Who wants to compile a list of possible rails so we can make it into an addon? :icon_twisted:

Just beware, Alwarren had some good point in this post and I have tried to explain it in the answer - linkProxy shows where the attachment appears on the weapon, type inside the config of the attachment determines what inventory slot does it fit in :icon_twisted:

[Sniperwolf572 758]

Just beware, Alwarren had some good point in this post and I have tried to explain it in the answer - linkProxy shows where the attachment appears on the weapon, type inside the config of the attachment determines what inventory slot does it fit in :icon_twisted:

That answers my questions then, thank you. :)

[Alwarren 2765]

Just beware, Alwarren had some good point in this post and I have tried to explain it in the answer - linkProxy shows where the attachment appears on the weapon, type inside the config of the attachment determines what inventory slot does it fit in :icon_twisted:

I suppose extending that is only possible through code changes in the engine? I am talking about e.g. clip-on night vision sights here like this one.

Also, would it be very hard to implement "alternate" models for different optics modes? What I mean is something like this:

class FHQ_optic_HWS_G33: ItemCore
   {
       scope = 2;
       displayName = "Eotech G33 (Black)";
       picture = "\FHQ_Accessories\HOLO\UI\gear_acco_g33_black_ca.paa";
       model[] = {1, "\FHQ_Accessories\HOLO\G33.p3d",
                       2, "\FHQ_Accessories\HOLO\G33_up.p3d"};  //<-- ***
       descriptionShort = "Eotech Holo Sight with G33 scope";
       weaponInfoType = "RscWeaponZeroing";
       class ItemInfo: InventoryOpticsItem_Base_F
       {
           opticType = 1;
           mass = 4;
           RMBhint = "Advanced Rifle Combat Optics";
           optics = 1;
           modelOptics = "";
           class OpticsModes
           {
               class G33
               {
                   opticsID = 2;
                   useModelOptics = 1;
                   opticsPPEffects[] = {
                       "OpticsCHAbera1",
                       "OpticsBlur1"
                   };
                   opticsZoomMin = 0.0863;
                   opticsZoomMax = 0.0863;
                   opticsZoomInit = 0.0863;
                   memoryPointCamera = "opticView";
                   visionMode[] = {
                       "Normal"
                   };
                   opticsFlare = 1;
                   opticsDisablePeripherialVision = 1;
                   distanceZoomMin = 300;
                   distanceZoomMax = 300;
                   cameraDir = "";
               };
               class Kolimator : G33
               {
                   opticsID = 1;
                   useModelOptics = 0;
                   opticsFlare = 0;
                   opticsDisablePeripherialVision = 0;
                   opticsZoomMin = 0.375;
                   opticsZoomMax = 1.1;
                   opticsZoomInit = 0.75;
                   memoryPointCamera = "eye";
                   visionMode[] = {
                   };
               };
           };
       };
   };

The line marked *** makes the model an array with one model for each optic mode. That would allow e.g. the shown G33 to have a real 3D scope that flips up when the magnifier is in use (like this).