da12thMonkey

The last part is determined by the cfgammo class of the currently selected weapon's magazine's ammunition, using the weaponType parameter, or from simulation type of the ammunition in the absence of weaponType, so it's a list you would have to compile from checking those parameters for all the ammo available to that vehicle. Then you need to reference weaponsGroup1, weaponsGroup2 etc. etc. for the vehicle to find what weapon types are grouped together As for checking what key is mapped to each action, IIRC you'd use inputAction to query the key associated with the weapongroup actions such as SwitchWeaponGrp1, SwitchWeaponGrp2 etc. etc.

Richards said before somewhere here on the forums or during one of our streams that the M1165A1 GMV will be the protected version with the B3 armour kit So it'll be generally similar to the M1165s currently in the mod in terms of protection but with armament and "Standard Threat" armoured doors instead of the FRAG-5 ones. Naturally it will have some of the Spec-Ops-Peculiar M1165 equipment like the SAG turret instead of GPK, O-GPK or MCTAGS, MilSysGroup lightweight bumper instead of the IbisTek one, and likely the protected cargo deck similar to the M1245 M-ATVs

I'm pretty sure it's just cfgSkeletons bones for animating the .p3d model, and class MFD bones are a completely separate thing

How many selections are you adding? There is a hardcoded limit for the number of bones you can have in a model. It's ~256 IIRC

Yes. Though laser-guided munitions like AGM-114 and DAGR can still use their internal sensors to lock on laser targets designated by units outside the helicopter (or a unit sitting in the cargo compartment FFV seats with a laser designator) The US Army doesn't use UH-60s as gunships so the ones in the mod only have the most rudimentary support for employing the weapons that can fit on ESSS. It's a transport heli with wings mostly to carry additional fuel, that can mount weapons in extreme circumstances outside its normal role. The various real-world Blackhawk variants that are routinely armed (Navy SH-60/MH-60, SOAR MH-60 DAP, and various models made for export customers such as the UAE, Colombia, Israel) have much more equipment that you simply would not find on a US Army UH-60

There's a fix for this (along with a new showHandgunMagProxy = 1; config parameter added to vests) on the Arma 3 dev Branch (rev 146887) Handgun behaviour has been to hide all attachment proxy objects to avoid suppressors, lights etc. clipping out of holsters. And until now, the magazine was treated likewise

All those models and textures are LODU's work, as were the new VKPO uniforms and Ratnik equipment. We're unbelievably lucky to have received so much amazing gear from him, covering past and present Soviet/Russian equipment with such a broad scope

The colours correspond to whether the config parameter is a string, number or array So presumably you use getNumber to retrieve the green ones

Mk48s do accept the side-mounting M240 50rnd cloth nutsacks and the old M60 100rnd cardboard box holder, using a side-mounting bracket https://imgur.com/a/9vitZ4e Same setup the M240 has but with a different mounting bracket AFAIK. It's just that since the Mk48 has the benefit of being side-ejecting rather then bottom-ejecting (like the M240 is), they were also able to make Minimi-style pouches that hang on the underside of the gun.

You can use setPylonLoadout to force any dynamic loadouts magazine on to any dynamic loadouts vehicle. You just have to include "true" as the 3rd parameter in the array to tell the game to force the magazine on to the pylon e.g. vehicle player setPylonLoadout [1, "rhs_mag_AGM114K_2", true]; As for finding classnames, they're almost all in rhs(usf)_c_airweapons.pbo config.bin file. But equally you will be able to find them in the ingame config viewer under the cfgMagazines section. They should more or less all be of a format rhs_mag_#NAME# But also with the config viewer if you are playing with a vehicle in the editor with the particular magazine you want is equipped on a RHS aircraft and that weapon is currently selected, the config viewer will give you a shortcut to finding the current magazine in the bookmarks section at the bottom-left corner of the window

It's the same as the vanilla Arma stance adjustment keys you use as a dismounted soldier. IIRC Ctrl+W/Ctrl+S are the default keys for that

They're running lights the same as you see on our HEMTTs and some other wheeled vehicles in the mod. There's already a "Service Drive" menu action to turn them on

When you press Esc ingame, there's a little menu at the top that says "RHS - Game Options" The setting to change sights between 3D and 2D variants is in there

Squad xml wont work on a beret/headgear item or other wearable gear items such as vests. In fact it's not possible to dynamically change the textures of cfgWeapons type objects during the game at all. Alternate textures on such items only work through making pre-configured classes with hiddenSelectionsTextures[] set for each variant

I would say that's the wrong way of apportioning "blame" regarding the F-35 becoming what it has become. Rather the F-35B/JSF has had to make changes out of its scope in order to become a larger tri-service project. The project began on the basis of a USMC+UK requirement for a STOVL jet, and the USAF was persuaded that a version without the lift system would be suitable enough for their light fighter requirements. All the earliest concept drawings from the 1990s are with USMC and RAF/RN STOVL aircraft. Over the years, the US cancelled other projects that would have been more suitable for the USAF and USN's specific needs MRF, A/F-X etc. etc. and through necessity those have fed in to a set of increasing requirements for the whole JSF program. All things being square, you would have had: USMC with F-35 (probably more rudimentary than it is) USAF with F-22, MRF USN with A/F-X The problem is that they tried to morph a project initially dictated by the USMC's requirement into the kind of USAF/USN project you mentioned. The US could have merged MRF with A/F-X in parallel to, or at the expense of F-35 development. But the USAF decided to work with the Marines requirements before the Navy's (I imagine the USAF saw an opportunity to maybe take control of the Marines project, where it would be more difficult against the political clout of the Navy), and before long you had all three services trying to force three different aircraft projects in to one. It's not the case that the USMC requirements were "tacked on", so it cannot really be said that sacrifices were made from the project's initial conception in order to accommodate STOVL.

Classnames also need to be in the cfgpatches units[] = {...}; array

BI released official .psds for these DLC vehicles: https://store.steampowered.com/app/390500/Arma_3_Samples/

Use slot = "GripodSlot"; instead of slot="UnderBarrelSlot"; The grip system has its own proxy/slot for positioning the attachments separate to the bipod slot even though, due to weapon simulation and inventory limitations it's functionally the same as the bipod slot and uses LinkedItemsUnder e.g. from our config:

.paa must always be in 2^n resolution. i.e. 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096 etc. are the only valid pixel dimensions for converting images to .paa. So you will either have to crop or rescale the image to e.g. 2048*2048, 2048*1024, 1024*1024 etc. etc. etc. before converting to .paa

Our rounds are not the same as the vanilla BI (tanks DLC) ones, in terms of damage, penetration or ballistics. If you happen to run CBA with RHS, you will be able to load RHS Carl-G magazines into the vanilla launcher and vice versa because we have configured it to use CBA/JAM common magazineWells. So then you don't have an issue of inconsistent damage/penetration when using the vanilla launcher against RHS vehicles. However, the various range stadia lines in the optics wont match ballistics for ammunition that the sight was not calibrated for.

From the images you picked, do you mean pauldrons (deltoid protectors) not "pouches"? In which case, they're probably not going to be added to the current IOTV. From what we understand, the deltoid protectors were hugely disliked by troops and rarely worn in the field in spite of being issued with the vest. It gives us little incentive to add them to our units. If there's a complete remodel/overhaul of the IOTVs in future and the modeller wants to do those accessories, they'll be included. But for the current IOTV model: No, there's no real intention to add them

AFAIK new production LAU-131 pods have been grey for a while but a lot of them in use are older, so are still green. The AKPWS pod is an extended version called LAU-131A/A, so naturally they all come in grey because they are new The green pod is available but fires FFAR rockets instead of Hydra (only difference is the rocket models). So the different colours of the pods now indicates to some degree what kind of HE rocket is carried. GBU-12 has the Navy style thermal coating because the model we were provided was that way; having originally been developed for a US Naval aircraft addon. I did ask for someone with access to the source substance painter file to alter it to the regular Mk82 casing, but honestly there are better things to do whether Arma related or not. Off the top of my head: USAF: Mk17 and M249 Para AFRF: PP-2000 and just about every AK that hasn't got a wooden stock, the Zenitco PT-3 stock, or a GP-25 SAF: SCAR 17, M70AB2, M92, M21A/M21S and Minimi Para GREF: Vz61 and Vz58V

Indeed. I just read it as "I can use requiredaddons..." The {}; brackets implying an empty array, didn't register in my mind, sorry You should have something in the array if you are inheriting properties from existing BI classes, just to ensure your addon is definitely loaded after all the BI stuff has been parsed

Because class EX3B_O_APC_Wheeled_02_rcws_v2_base_F isn't an existing class from the game, so writing class MainTurret; in there isn't referencing the location of an existing class MainTurret. It's just creating a new one with no parameters. When you do MainTurret: MainTurret in EX3B_O_APC_Wheeled_02_rcws_v2_F it is now inheriting from a completely empty MainTurret. Turrets are one of a number of special class types that behave differently from others in the game, whereby they will completely overwrite classes with the same name rather than merging with them. Which is why you are always needing to do Turrets: Turrets, MainTurret: MainTurret type inheritances to preserve parameters where you want to keep the same name. Just writing class MainTurret; in a new class is effectively the same as writing class MainTurret {}; to empty it.

If you do actually want a EX3B_O_APC_Wheeled_02_rcws_v2_base_F central base class for your variants: class Wheeled_APC_F; class APC_Wheeled_02_base_F: Wheeled_APC_F { class Turrets; }; class APC_Wheeled_02_base_v2_F: APC_Wheeled_02_base_F { class Turrets: Turrets { class MainTurret; }; }; class EX3B_O_APC_Wheeled_02_rcws_v2_base_F: APC_Wheeled_02_base_v2_F { class Turrets: Turrets { class MainTurret: MainTurret { //Your stuff here }; }; }; class EX3B_O_APC_Wheeled_02_rcws_v2_F: EX3B_O_APC_Wheeled_02_rcws_v2_base_F { scope = 2; //placeable in editor }; Otherwise you can move the EX3B_O_APC_Wheeled_02_rcws_v2_F class up to where EX3B_O_APC_Wheeled_02_rcws_v2_base_F is (see below) Alternative inheritance would be class APC_Wheeled_02_base_F; class APC_Wheeled_02_base_v2_F: APC_Wheeled_02_base_F { class Turrets; }; class O_APC_Wheeled_02_rcws_v2_F: APC_Wheeled_02_base_v2_F { class Turrets: Turrets { class MainTurret; }; }; class EX3B_O_APC_Wheeled_02_rcws_v2_F: O_APC_Wheeled_02_rcws_v2_F { class Turrets: Turrets { class MainTurret: MainTurret { //Your stuff here }; }; }; But this is specifically using the ingame CSAT vehicle O_APC_Wheeled_02_rcws_v2_F rather than the Marid base class. So may have some extra desert CSAT-specific properties you don't want to automatically inherit when it comes to making your own branch of the classes (type of crew, edPrev image, texture set etc. etc.) Fundamental idea is that you go backwards along the inheritance tree each time you inset by a subclass to inherit that subclass' properties from a parent. Not start at some class and try to build a whole set of extra classes to fill those inset gaps, which is what you appeared to be doing with the EX3B_O_APC_Wheeled_02_rcws_v2_base_F and O_APC_Wheeled_02_rcws_v2_F_Clone classes. You can see the difference between the first and second examples whereby the class we are adding stuff to ("//Your stuff here"), branches off one step further down the inheritance tree in the second example (O_APC_Wheeled_02_rcws_v2_F rather than APC_Wheeled_02_base_v2_F) so the starting point is one class down in turn (APC_Wheeled_02_base_v2_F rather than Wheeled_APC_F)