da12thMonkey

I took MRT off Workshop (RIP my subscriber-driven ego ). So for some users at least that should clear up the launcher to only call for CBA when running SMA (seems to have removed the dependency from the page, and AFAIK it should remove the mod for workshop subscribers). Still waiting to hear from the chap I asked at Six about whether it was safe to do likewise, or just general advise on transitioning people to CBA alone. Obviously some people will need to manage themselves if they have the mod from non-automated sources or their modset is manually managed to include MRT rather than by initialised through dependency of some other mod.

We'd still need to model said launchers as well. Ultimately that's the main reason it's not been done so far and the reason it may not be added any time soon. The fact Jets DLC will add dynamic loadouts to aircraft and helicopters doesn't inherently mean we'll prioritise expanding the inventory of aircraft weaponry. First priority goes to adapting what is already there.

Please note, that as off today (25/02/17) MRT Accessory Functions has been fully integrated in to Community Base Addon (CBA A3) by Robalo. It is no longer necessary to install and run this separate addon in addition to CBA It is in a manner that was achieved previously by Robablo's integration of ASDG Joint Rails in to CBA. So the existing MRT AccFnc cfgPatches class and config parameters are included in the CBA v3.2.0 setup, and compatibility should be maintained with addons that used MRT AccFnc previously in a way that allows you to un-install MRT from your collections and modsets and run with the minimal dependencies of CBA alone. I'll try to find time in the coming weeks to communicate to authors that have integrated past versions of the mod, that they can remove any automated MRT dependency from mods hosted/launched by Steam Workshop and PWS and will only need the CBA 3.2.0 dependency. Or assess the impact of removing MRT from those hosts where it's no longer necessary.

by da12thMonkey Robalo and Tupolov MRT Accessory Functions (AccFncs for short) is a small script addon that switches a player's current weapon accessories between a set of predefined classnames at the press of a button. The aim of this function is to simulate various interactive features in real-life weapon accessories that are otherwise absent in Arma 3. Demonstration video by sorophx (uses the example attachments linked further down this post) The system is designed to be easy to implement for community addon makers and avoids hardcoded classnames within the scripts themselves. Making an addon compatible with MRT Accessory Functions does not make the addon dependant on MRT Accessory Functions or CBA, and its installation remains at the discretion of the player. As of 25/02/2017 MRT Accessory Functions has been fully integrated in to Community Base Addon (CBA_A3). It is no longer necessary to run this addon separately with CBA versions later than 3.2.0, and MRT AccFncs can be removed as a dependency from your collections and modsets More information: https://forums.bistudio.com/topic/168277-cba-community-base-addons-arma-3/?page=37#comment-3157088 https://forums.bistudio.com/topic/171270-mrt-accessory-functions/?do=findComment&comment=3157248 Configuration → Controls → Configure Addon MRT Accessory Functions should be available from the drop-down menu there, allowing you to change the keybinds to your liking. In rare circumstances it is possible to corrupt your CBA keybinding registry, which may cause problems such as control options disappearing from the keybind menu. In order to reset the keybinding register please attempt the following instructions: When performing these key-presses with a compatible attachment assigned to your weapon, a small 'click' sound will be heard as your accessory changes mode, and a small hint box will appear, telling you which mode your weapon accessory has changed to. In order for you to see the effects of the script, an addon with compatible attachments must be running in conjunction with MRT_AccFncs.pbo. We have provided config addons to add compatibility for: FHQ Accesories Pack v1.4 - using MRT_FHQ_LLMAccFnc.pbo - No longer required with FHQ Accessories Pack 1.5, which provides native support for MRT AccFncs R3F French Weapons Pack v3.2 - using MRT_R3F_SURBAccFnc.pbo Appropriate attachments (R3F's mini laser/lamp) will be able to switch between laser and light modes, when running in conjunction with MRT AccFncs and CBA. This config addon is available in the 'optional' subfolder inside the @MRT_AccFncs modfolder. Compatible Community Addons: ASDG Attachments - Using v.20150305 config ASDG ACO - Allows switching between all of the (now) 4 reticle variants for the ACO sights and the 2 reticles for the Holo sights, that came with the Marksmen DLC. It requires JR because it's adding 6 new hidden optic classes to allow this to work. FHQ Accessories Pack - Version 1.5 utilises MRTAccFns to provide a switchable LLM-01 Laser/Light as well as module and flip-up magnifiers for Aimpoint and EOTech sights R3F ASDG JR config - An ASDG JR config for the R3F French Weapons Pack Version 3.3 that also enables MRT functionality on the SURB laser/light module attachment when MRT AccFncs is installed. A standalone config that enables this MRT feature without the additional ASDG JR compatibility, is distributed with MRT AccFncs itself. RHS ASDG JR config - Robalo's custom config for the RHS: Escalation provides MRT support for the Kobra sight and Surefire/IR combo Specialist Military Arms - SMA Version 1.9 contains several attachments that utilise MRT AccFncs, including an EOTech with a flip-over magnifier Making a MRT_AccFncs compatible addon: Implementing our system into your own attachments addon is incredibly simple; it just requires three additional config parameters in your attachment's class: MRT_SwitchItemNextClass = "*CLASSNAME1*"; MRT_SwitchItemPrevClass = "*CLASSNAME2*"; MRT_switchItemHintText = "*DESCRIPTION*"; Replace *CLASSNAME1* with the atachment class you want the script to switch to when pressing the 'Next' keybind (default [ctrl + L] for rail items, [ctrl + NumPad /] for optic items). Replace *CLASSNAME2* with the atachment class you want the script to switch to when pressing the 'Previous' keybind (default [shift + L] for rail items, [shift + NumPad /] for optic items). Replace *DESCRIPTION* with a short text string that describes the mode of operation that the class has (e.g. "Laser", "Light", "Red", "Blue" etc.). This is the text that will appear in the ingame hint box when the player switches to this attachment class using the keybind. Can be left empty if you don't want or need a hint box to appear. These config parameters will only be recognised by the game when MRT_AccFncs.pbo is installed by the player, otherwise they will have absolutely zero effect on the operation of your addon. As such, addons can be made compatible with the Accessory Functions system without being dependant on it, and the choice to download and use the system remains completely at the discretion of the player. So worry not, you can continue to make your attachments without the anxiety of bloating the user requirements with a bunch of mandatory addon dependencies. :) The MRT_SwitchItemNextClass and MRT_SwitchItemPrevClass parameters can be arranged in such a way to provide different control schemes depending on the number of modes that you want your interactive attachment to have. The following graphics show the recommended setup for an attachment with simple binary states (like a laser/light module or flip-over magnifier), cyclable attachment states, or linearly scaling attachment states, but more complicated control schemes can probably be mapped out if you want them. Colours indicate the MRT_SwitchItemNextClass and MRT_SwitchItemPrevClass relationship between classes: Fig.1: Binary Fig.2: Cycle Fig.3: Linear Examples: To provide some idea of the capabilities of this system, I have provided a small set of additional attachments that are set up to utilise the above control schemes. We have: MRT_LLMTest.pbo - A simple Laser/light module using the BIS IR laser and Flashlight models to visualise the binary switch MRT_COMPM4.pbo - An Aimpoint CompM4 with a 3x magnifier that flips up and down (also binary, but applied to the optics slot for a change) MRT_FlashlightAdj.pbo - An adjustable flashlight that allows you to scale the intensity of the light source using the linear control scheme MRT_Holosight.pbo - An EOTech holographic sight with selectable reticle patterns that can be cycled through MRT_COMPM4.pbo, MRT_FlashlightAdj.pbo, MRT_Holosight.pbo and MRT_LLMTest.pbo are all unbinarised to provide examples that other addon makers may wish to copy. However because they are unbinarised and unoptimised, the game may hang slightly when loading the unbinarised models for the first time ingame (i.e. when switching the aimpoint magnifier up and down). Bear in mind that these are just some quick testbed attachments to show off ideas for the sort of functions that can be simulated with the MRT Accessory Functions system, and some of the limitations (There appears to be an engine limitation where you have to turn the light on and off again to refresh the light source with the adjustable flashlight!). The models are just quick 'placeholders' using available assets; not nice, polished addons. Download: MRT AccFnc Examples ASDG Joint Rails CBA Joint Rails is needed for the example attachments to actually clip on to the weapons ingame. MRT Accessory Functions system itself does not require attachments to be JR compatible. However, we strongly recommend utilising JR in your projects as a means of improving compatibility with other community-made weapons and attachments :) A few words on development of this addon: The concept for this addon came about after I completed work on RKSL Attachments Pack 1. I began assessing options for new attachments that I should make for the next pack, and the UK's latest LLM Mk.3 seemed a likely candidate, but I figured why make something like that when it wouldn't be able to switch between laser and light modes? I know I and several other community addon makers had long held hope that BIS might make attachments a bit more dynamic, but so far nothing seemed to be materialising on this front within the community or from BIS. Eventually I got around to trying to write a basic script to switch between the standard Arma 3 flashlight and IR laser attachments and investigating how to pair the two classes together via the config. Right from the beginning it was my desire to avoid using hardcoded classnames in the script to ensure that if I wished to make more attachments using this system in future, I wouldn't have to manually add classnames to the script every time I wished to update my addon, or introduce hard dependencies between addons. I had also hoped that the system would be able to be used by other addon makers in the community who did not possess the time or inclination to generate their own switching scripts. Unfortunately, in twelve years of playing these games I'd never even attempted to code sqf before, so I very soon got stuck and asked Tupolov to help me out, knowing that he was developing some interesting functions for Arma 3 small arms himself. Tup, marvel that he is, understood my concept and put together a fully functioning script, for which I will forever be in his debt. Even more so for allowing me to abuse the coding work further and create the first version of this addon, that was received with some enthusiasm by the community members I got to test the system. Recently Robalo released ASDG LightSwitch which functions in a very similar manner to what me and Tup wanted to achieve. I sent him the work that had been done so far, knowing from past collaboration with him that we could exchange some ideas about implementation that would mutually benefit overall development of this concept within the community. Rob identified that the way I'd set up Tup's script was pretty inefficient and being the great bloke that he is, streamlined the whole system into one very impressive function. We hope that this system provides some utility to people who wish to experience a little more interaction with their weapon's attachments... at least until the day BIS provide some native way of creating such multi-mode attachments that doesn't rely on scripts and creating a glut of additional classnames. We genuinely hope that one day BIS will make this addon obsolete! :)

None. It's a separate build that contains some things that have been on Dev Branch during 1.67 development builds (such as the 64-bit .exe), but not all of them. 1.67 (and the current 1.69) dev builds have introduced stuff that will eventually be in the patch that coincides with the release of the Jets DLC, but not the 1.68 stable patch.

It's because you're on top of a ship. The game thinks the helicopter is in the air because of the height of the ship's roadway above the ground/water (same reason the landing gear are extended). Helicopter is treating the 'get out' action as an ejection and triggers the ejection script (ordnance "wings" and doors fall away, inflatable safety barrier extends from the cockpit) rather than a simple get out. Might be fixable changing the way the script checks for height, but might not be because of the weird way Arma treats altitude and roadway LODs - so it's all a matter of finding the right workarounds. Most carrier-based aircraft addons have their suspension adjusted for the height of carriers for similar reasons that the game treats roadway surfaces different to the actual ground. But anyway, you shouldn't have the issue on land.

Our A-10 is based on the Arma 2 A-10 model. AFAIK the UV-mapping is unchanged So the .p3d file is available in the sample data packages https://community.bistudio.com/wiki/Arma_2_Sample_Models

No. Wget hasn't been used at all since 0.4.1.1, so it wont update to the last version (0.4.2) never mind the latest hotfix version. Play with Six and Armaholic have both updated to 0.4.2.1 now by the looks, if people are seeking mirrors other than Workshop

No, if users had the option to change how quickly their vehicles started up on an individual basis, it would present problems in multiplayer. If you read the changelog, you'd see that mission designers have the option to set RHS_ENGINE_STARTUP_OFF = true;

Found some time to do this and stick the F-15s on Workshop: NATO F-16 Pack: (updated 17/02/2017) Changelog: Updated Romanian Air Force texture with full markings. Weapons and magazines update with new proxy order. F-16AM fitted with F100-PW-220 engine nozzle. Download v1.4: Mirror 1 - @DropBox Mirror 2 - @Steam Workshop Gallery Falcons of the Middle-East Pack: (updated 17/02/2017) Changelog: Weapons and magazines update with new proxy order. F-16AM fitted with F100-PW-220 engine nozzle. Downloads v1.2: Mirror 1 - @DropBox Mirror 2 - @Steam Workshop Gallery Eagles of the Middle-East Pack: (updated 17/02/2017) Changelog: Editor preview images Appropriate antenna fittings Downloads v1.1: Mirror 1 - @DropBox Mirror 2 - @Steam Workshop Gallery F-15SG Republic of Singapore Air Force: (updated 23/02/2017) Changelog: Editor preview images mod.cpp icon Appropriate antenna fittings F110-GE-129 engine nozzles Tiger Eye IRST 23/02/2017 Update: 142 Squadron (Gryphon) texture variant Downloads v1.2: Mirror 1 - @DropBox Mirror 2 - @Steam Workshop Gallery

The Plamen gunpods, Scalpel, DAGR and AMRAAMs were made accessible in the loadout menu in todays's dev Branch update, even if it's not mentioned on the changelog. The Plamens are described as a "Test" in the UI, so it might only be interim that these are available for the Wipeout. Using the Wipeout's PilotCamera TGP laser and the DAGRs is super fun though!

This is a bug with Arma 3's kind of crappy depth of field blur post-processing effect. It affects BIS' 3D scopes like the ARCO as well (or at least it used to) ARCO with DOF blur Nothing that any addonmaker can do to fix it AFAIK. Turn off DOF blur in your graphics options and it wont do that weird spreading reticle thing

A new cfgNonAIVehicles proxy class with pylonpod simulation for any custom armament proxies you're displaying in the model. Proxy class must be called Proxyp3dFilename Armament proxies have always worked by virtue of the proxy index number and their simulation (formerly MaverickWeapon and now pylonpod) as stated by the biki article: I assume this Refers to something like the maverickWeaponIndexOffset value? Which I guess needs to be 0 now for all cfgAmmo classes using the dynamic loadout system? Am wondering though, do we need a tools update for the new Animation Sources stuff on the Dynamic Loadouts biki page to work or to create .p3d versions where the above pylonpod proxy stuff is read?

https://community.bistudio.com/wiki/Arma_3_Dynamic_Loadouts reveals some information about the intended features of the system when it is fully integrated, including that there will hopefully be options to manage loadouts at mission start and in-play, in addition to the current Eden attributes. There's a lot of great info for addon makers on there, like the extension of some model.cfg animations sources (reload, ammo, revolving) to apply to the "magazine" proxy models loaded on to the aircraft's hardpoints

It works in that the Ammo truck will rearm whatever loadout you picked from the Attributes menu, but if you're asking whether you can change loadouts on the fly ingame using resupply trucks; then no that doesn't seem to be an option at the moment. Probably a good idea that it's not default behaviour for the trucks really, since it should be up to the mission designer whether players can change their loadouts from some kind of supply point (as it is with including Arsenal in a mission), or to restrict them to specific mission-oriented loadouts.

I thought BIS removed all those "switch weapon" actions from the menu ages ago? The game has had keybinds for switching to specific weapon slots for over a year AFAIK, with the intention of removing numerous excess actions like those from the list. Are you saying the keybinds are not working?

Limitations of what munitions can go on which hardpoints seem to be by maxweight at the moment - each 'pylonRack' magazine class has a corresponding mass value that I guess stops it fitting the hardpoint if it exceeds maxweight. The pylonRack magazine classes have a number of interesting new parameters You'll notice that things like the Falchion and 3x Macer have a unique pylon that loads visually on to the aircaft hardpoints, with the missiles attached to the pylon. And that the missiles deplete from these pylons when fired (Shrieker rocket pods have visible warheads for separate AT and HE types too). Will be interesting to learn how this is done now, since it required separate magazines for the pylons/pods and corresponding missiles/bombs/rockets, plus tons of extra proxies in the aircraft model before. But now it's clearly done via a single magazine and associated 'PylonPod' model I suspect also that the hardpoints[] array that appears in both the pylons config above in @flax_ post, and the magazines config, will be used at some point to categorise which munitions can be loaded on to specific hardpoints through the attributes UI. At a minimum for defining sides (e.g. OPFOR munitions defined for O_BOMB_PYLON wont be available for BLUFOR aircraft). But currently all the available munitions for the Wipeout belong to the B_BOMB_PYLON set

No need to ask. It's fully documented: http://www.rhsmods.org/page/developers#bolt-action-system

It really isn't. Certainly not in terms of triangles. There are plenty of weapon addons for this game that have face counts >7k in mixed quads and tris in their top LOD for the view Pilot, which is what would roughly equate to 12-14k when fully converted to tris. So this is definitely in the ballpark. Make good LODs and it'll be fine

As I added to the end of the post: I think isEmptyNoReload returns the bone to its original position when the reloadMagazine sequence starts, however. So it would act like the slide was released before inserting the new mag I think with BIS' weapons they all use isEmptyNoReload but start the reloadMagazine animation with the slide/bolt moved back as it would be from the isEmpty/isEmptyNoReload source Depends what style of reload you want. But you can't really have the reload anim conditional of whether the magazine is full or empty

Most semi-auto pistols you don't need to rack the slide when changing the magazine. It's only done to load/make ready the weapon for the first time from the original magazine, or if you release the slide after emptying the magazine, before inserting a new magazine. From an emptied magazine you just release the slide from being locked back and it will pick up the round from the new magazine. The game does this automatically when isEmpty source returns to 0. From a half empty mag you'd nominally have a round in the chamber, which would cycle the first round from the new magazine after firing the one in the chamber. I know Arma doesn't do +1 reloads but in general, reload anims are treated as such where reloading is by releasing the bolt/slide alone IIRC though isEmptyNoReload does return the weapon to the isEmpty = 0 state when a reloadMagazine animation starts.

Handanim doesn't work like that. It's based on Inverse Kinematics. This means the game looks at the position of the hand and its orientation, then tries to automatically solve the posing of the arms from the base rifle raised/lowered etc. animations within certain constraints for how far e.g. the elbow can rotate, until the forearm joins up with the hand at the wrist. If it can solve the IK just by rotating at the elbow it will. if it cannot, and needs to rotate the arm at the shoulder in order to move the elbow position, then it will do that. Though it seems to be to a lesser degree. Your best bet would be to rotate the entire hand back around so that the wrist uses a different orientation, facing down towards the elbow as much as possible. And reposition the grip angle with the the -rightHandRing bone (I think that's what it is called - whichever one contains the lower half of the palm, and the Ring and Pinky fingers). Rather than having the whole hand rotated around to that high angle.

Certainly, given the age of the Mi-24V and Mi-24P variants available in the mod, compared to the a modern system like AH-1Z. Unless we go balls-out and make a proper Mi-35M some day, where the gun (GSh-23V 23mm now) and missiles are both slaved to a GOES-342 electro-optical turret in a similar manner to the Ka-52 or Mi-28, and TADS on the AH-64 or TSS on the AH-1. But don't expect that any time soon.

As he mentioned before https://forums.bistudio.com/topic/186835-community-upgrade-project-cup-terrains/?do=findComment&comment=3147473 The PWS download of CUP Terrains is showing CWA dependency errors seemingly because the download contains versions of e.g. cup_terrains_maps_cain.pbo that are possibly from an older (2016 dated) version of Terrains. But the Terrains and Terrains Core from their servers does not contain some of the other CWA .pbos that were split from in to the separate download and are available in the new CWA Terrains addon on PWS (no cup_terrains_cwa_buildings.pbo, cup_terrains_cwa.pbo etc.) Running Terrains, Terrains Core and CWA Terrains all together probably shows no errors. But just having Terrains and Terrains Core installed from PWS does, because those CWA islands that are somehow still in the Terrains folder are looking for CWA buildings etc. that are only in the CWA modfolder Removing the 2016-dated cain, abel, noe etc. .pbo files from the Terrains folder downloaded from PWS, starts the game without errors when running Terrains and Terrains Core alone. And running Terrains Core with the PWS version of CWA Terrains also works without error.

At a guess, since the previous post was more than a year ago: https://forums.bistudio.com/guidelines/