Jump to content

da12thMonkey

Member
  • Content Count

    3991
  • Joined

  • Last visited

  • Medals

  • Medals

Community Reputation

1777 Excellent

About da12thMonkey

  • Rank
    Chief Warrant Officer

core_pfieldgroups_3

  • Occupation
    civil serpent

Profile Information

  • Gender
    Male
  • Location
    United Kingdom

Contact Methods

  • Steam url id
    da12thMonkey

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. da12thMonkey

    Adding squad logos to beret

    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
  2. da12thMonkey

    Lets talk about the F-35

    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.
  3. Classnames also need to be in the cfgpatches units[] = {...}; array
  4. da12thMonkey

    Community Texture Templates.

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

    RHS Escalation (AFRF and USAF)

    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:
  6. da12thMonkey

    Color problem with texture viewer 2

    .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
  7. da12thMonkey

    RHS Escalation (AFRF and USAF)

    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.
  8. da12thMonkey

    RHS Escalation (AFRF and USAF)

    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
  9. da12thMonkey

    RHS Escalation (AFRF and USAF)

    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
  10. da12thMonkey

    Adding requiredAddons to a mod

    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
  11. 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.
  12. 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)
  13. da12thMonkey

    Adding requiredAddons to a mod

    Yeah. Most simply you can use requiredAddons[] = {"A3_Data_F_Enoch_Loadorder"}; Which is the latest cfgPatches class for Arma 3, to ensure your data loads after all the BI data that you are referencing or modifying
  14. da12thMonkey

    RHS Escalation (AFRF and USAF)

    Combat Range != Combat Radius AH-64A's mission radius is quoted as 150km by most sources - that is to fly there with ordnance, perform the mission (unknown duration) and return. Total range for the mission duration was 400km. AH-64D has a marginal increase in total range with similar ordnance ~470km without external fuel tanks. But yes vehicles in the mod generally have a shorter maximum range, partially for gameplay reasons to encourage logistical support, but also because Arma doesn't simulate a number of factors that affect fuel consumption (like tankbuster mentions), and most players don't operate the vehicles at anything less than max speed (which would be bad for fuel efficiency IRL).
  15. They could be carried by many aircraft in British service but the RAF and RN almost exclusively used the UK's own 1000lb and 540lb general purpose bombs made by Portsmouth Aviation etc. There were a couple of different tail kits and fuses used for both types (diagram showing the general shape of the airframe, here with the Hunting designed retarding tail cone. Dimensions of the 1000lb bomb) UK versions of the Paveway II and Enhanced Paveway II (CPU-123/B?) were guidance kits for the domestic 1000lb bomb rather than for the the Mk80 series used by just about every other NATO member. (Enhanced) Paveway III carried by Tornado was with a BLU-109 type warhead. I don't know that the RAF have ever employed the Mk84 version of Paveway III. The other major freefall bomb employed by the UK was the BL755/IBL755/RBL755 cluster munition. American CBU-87 cluster munitions were used during the 1991 Gulf War by RAF Jaguars and possibly Tornado too. Rockets were largely SNEB 68mm with Matra Type 155 (18 round reusable) and Type 116M (19 round disposable) pods in that 1980s/1990s period. Type 155 seemed to be the predominant pod because it was reusable. Though I understand the CRV-7 was first used in the Gulf War on Jaguar, and eventually came to supersede the SNEB on Harrier by the late 1990s or early 2000s, with LAU-5002 (6 round) and LAU-5003 (19 round) pods. LAU-5003 being the predominant one. The Royal Navy were still using the 1960s-era 36 round No.7 rocket pod for 2-inch (50mm) "Microcell" rockets, as late as the 1980s and apparently these are what RAF Harriers also used for the duration of the Falklands War. Dumb bombs and rocket pods could be carried on triple racks only on the Phantom and Buccaneer (a UK copy of the US TER-9 more or less). Harrier, Jaguar and Tornado used dual racks, though it was somewhat rare. Neither are still in use. AIM-120 was also being introduced by the mid-1990s, on Sea Harrier FA.2
×