da12thMonkey

Well I'll punt out the fictional British "F-14K" retextures I did, in case people want to have some fun with them. .pbo contains three different paint schemes used by the Royal Navy (Fleet Air Arm), roughly in parallel to the Tomcat's lengthy career in the US Navy. However, only the last one really falls in line with the upgraded F-14D period: High-vis Extra Dark Sea Grey with White underside - scheme used by the RN on various aircraft from the 60s until the early 1980s. Tail markings for 893 Naval Air Squadron Low-vis Dark Sea Grey - scheme used by the RN's Sea Harrier FRS1 throughout the 1980s and early 90s. Tail markings of 899 Naval Air Squadron Low-vis Medium Sea Grey - scheme used by the RN's Sea Harrier FA2 from 1993 until they retired in 2006. Tail markings for 800 Naval Air Squadron DOWNLOAD Screens: 899 NAS and 800 NAS 893 NAS

It's actually what Vespa from BIS wrote about in the suggested guidelines for character modding since the game came out: https://community.bistudio.com/wiki/Arma_3_Modding_Characters and you can see Alwarren doing it to the model in the video I posted with the equivalent skin wrap function in Blender. But you will still likely have to adjust the weights in certain areas to improve the way it deforms in certain poses (again, shown in the video) and that requires some basic knowlege of how to paint the weights.

Probably the fact that that the whole 3d model of the 3GL is modelled as a single mesh (i.e. the barrel is welded to the trigger group), where the other GLs already had the barrel sections modelled as a separate mesh that can easily be animated without revealing any visual holes in the topology. If that's the case animating the 3GL could involve significantly remodelling the GL's geometry and creating a new UV layout to include newly modelled parts of the mesh such as the breech face that would be exposed by animating the model.

Alwarren made an example of his work to adjust CUP's modified Arma 2 models to fit the unit Arma 3 template in Blender (using his own plugin to export the model). Involves him transferring weights from the official .fbx sample model then adjusting them with the weight painting tools to improve the mesh deformation and fit inside the example tactical vest without so much clipping. Might be worth looking at for pointers.

Depends on the scenario you're trying to build doesn't it? i.e. what your OPFOR is like I'll assume you're building the battlegroup around an infantry battalion rather than a tank regiment or something like that, in which case infantry battlegroups are typically built with a battalion-sized main component, with smaller squadron/company-sized or troop/platoon-sized elements in support. 30 Challenger 2 tanks is about 2 squadron's worth, so I'd say it's too many for an infantry-focussed scenario. A battalion-sized formation will have 50-60 combat vehicles in operation plus all the supports. If you're building an armoured infantry battlegroup (i.e. the main element is using Warrior) then attaching a whole tank squadron with 18 CR2s to conduct armoured assaults against a mechanised, conventional opponent is legit (1st Battalion Royal Regiment of Fusiliers battlegroup in the invasion of Iraq was 14 Challenger 2s, 42 Warriors). However, a light infantry battlegroup (i.e. the main element is using Jackals and other highly mobile transport such as helicopters) against a less mechanised, unconventional enemy generally doesn't have a lot of armour support at all - you'd probably only need a troop's worth (4 tanks) that could be called in to support particular operations that required direct fire support. As an example of that when the war in Afghanistan was peaking for British forces ~2010, we didn't deploy any Challenger 2 MBTs and the entire 10,000-strong Multinational Brigade relied on only four Leopard 2A5 tanks from the Danish contingent. Also we had deployed a total of only 80 Warriors (of all kinds including engineering vehicles) since their major role was force protection and occasional infantry support (used like light tanks) rather than there being a real need for traditional armoured infantry. The most numerous tracked armoured vehicles at the time were CVR(t) reconnaissance vehicles of which there were a hundred or so and tracked ATCs like Warthog and Viking (about 150 each). I would think the environment where light infantry (inc air-assault and commando) and massed armour all operate together in combined arms would be a larger Brigade-size scenario with multiple battlegroups or the light infantry is a company-sized element attached to a armoured infantry battlegroup. So tank support available if you focussed on a light infantry scenario and their role in the conflict would probably be dependant on the particular stage of the conflict you were trying to portray. Or if you're doing a mixed infantry battlegroup - using different company-sized elements from different regiments. So basically it boils down to what role you see your main troop element having in the conflict. If they're light role give them loads of jackals, if they're mechanised role give them loads of Ridgbacks or Foxhounds or something, if they're armoured role give them loads of Warriors. It's not unusual to deploy just 2 companies from a battalion and make up the third and fourth rifle company from another regiment in a different role, or attach one or two extra rifle companies to a full battalion to provide permanent force protection to a supporting engineer or logistics squadron. once you've got your main infantry component worked out you can then look at adapting your additional support elements to squadron/company size (~14-18 vehicles) or troop/platoon size (4-8 vehicles) to get the right balance of tanks, reconnaissance vehicles (Jackals and Coyotes I guess since there are no CVR(t) or Ajax type vehicle addons yet) and air support. The mixed battlegroups that the UK sent on Exercise Black Eagle in Poland for the past couple of years have consisted of 20 Challenger 2 tanks (a single Squadron) and an infantry component made up of 30 Warriors (2 Companies worth) plus a protected mobility company and a light infantry company.

For a moment, don't bother trying to have the two simultaneous animation sources; just focus on trying to get the anim to work when you attach a side rail item. Delete or comment out the two hasbipod anims so you only have this: class plastichandguard_hide_side { type="hide"; hideValue=0.5; minValue=0; maxValue=1; minPhase=0; maxPhase=1; source="hasAccessory"; selection="handguard"; }; class railhandguard_unhide_side { type="hide"; hideValue=0; unhideValue=0.5; minValue=0; maxValue=1; minPhase=0; maxPhase=1; source="hasAccessory"; selection="handguardrail"; }; Then test to see whether the anim you want, works when adding and removing just a pointer slot attachment. If it works, then swap the two sources in the above from hasAccessory to hasBipod (no need to change the classnames of the anims really) and repeat the test, now seeing whether it works again when you attach/detach a bipod. If that also works, change the sources back to hasAccessory then make an additional hasBipod version of one of the above anims. e.g. add class railhandguard_unhide_underbarrel { type="hide"; hideValue=0; unhideValue=0.5; minValue=0; maxValue=1; minPhase=0; maxPhase=1; source="hasBipod"; selection="handguardrail"; }; And see whether the rail appears under the plastic handguard when you have a bipod attached but no pointer, then what happens when you add a pointer and bipod, then what happens when you take the bipod off and leave the pointer on. Then do the same with the opposite anim (i.e. railhandguard_hide_underbarrel). You kind of need to identify which part of the animation or mix of sources is causing the funny behaviour rather than trying to unfuck the whole thing written in one piece - that just makes troubleshooting too difficult.

Having a try with it, I'm beginning to think the animation will only work the way you intend it to when you have a bipod and an pointer slot item fitted to the weapon, since when you only have one of those slots filled, the other slot is still telling the weapon to stay in its original state. Don't think what you want to to with a slotA or slotB case will work.

class Animations { class railhandguard_unhide_side { type="hide"; hideValue=0.3; minValue=-1; maxValue=0; minPhase=-1; maxPhase=0; source="hasAccessory"; selection="rail"; }; class railhandguard_unhide_underbarrel { type="hide"; hideValue=0.3; minValue=-1; maxValue=0; minPhase=-1; maxPhase=0; source="hasBipod"; selection="rail"; }; }; Is the way we used to get something to be hidden at init in the past, before we had an unhide command. Think there's probably a way to do it with the new 'unhidevalue' parameter as well but haven't had need to try such a thing. Would probably be along the lines of this: Ed:- Jackal's confirmed this sort of method works. class Animations { class railhandguard_unhide_side { type="hide"; hideValue=0.3; unhideValue=0.7; minValue=0.5; maxValue=1; minPhase=0.5; maxPhase=1; source="hasAccessory"; selection="rail"; }; class railhandguard_unhide_underbarrel { type="hide"; hideValue=0.3; unhideValue=0.7; minValue=0.5; maxValue=1; minPhase=0.5; maxPhase=1; source="hasBipod"; selection="rail"; }; };

Just check the box that says 'Binarize' in AddonBuilder's main menu when you're compiling the .pbo. You don't need to do anything specific with the model itself. So long as *.p3d isn't in the 'List of files to copy directly' in your Addon Builder options, the program will binarize that filetype during the packing process; converting the model from the editable MLOD .p3d format on your P:\ drive to a binarized ODOL .p3d format inside the .pbo. If you're using another tool to compile the .pbo, consult their documentation.

One of the sample models has already been updated on the dev branch of Steam 'Arma 3 Samples': https://forums.bistudio.com/topic/169362-tools-development-branch-changelog/?p=2924270 AFAIK you just need to copy and paste the updated hit-points LOD from the character sample model (A3_Character_Example.p3d) and then do whatever config changes you need to do to your vests, headgear etc. that might use the new hitpoints The character template (A3_character_template.p3d) hasn't been updated yet for some reason so make sure you copy the LOD from the correct model. Easiest way to tell which is the right one is that the updated hit-points LOD contains a selection called Face_Hub.

You also need to define the attachment as being compatible with the weapon you are trying to add it to. The way to do this depends on the way the weapon's attachment slots are configured under class WeaponSlotsInfo

Another really nice addon from you Firewill And thanks again for including a retexture templates. I think I must spend as much time having fun with the .psd files as I do actually flying around in the Arma 3 with your work.

Pretty much everybody in NATO has realised that the C130-transportable requirements on armoured vehicles has been a hindrance. You just have to look at the size of the current generation of 8*8 armoured vehicles developed in Europe (VBCI, Boxer, Piranha V, AMV XP) to realise that. Strykers with upgraded protection levels mandated by recent conflicts such as those with L-Rod cages and later those with Double V Hull (Stryker DVH) are not C130-transportable anyway, so the deployability of the vehicle by air has been a two-tier system for a number of years already. 2nd Cavalry Regiment's Strykers (which are the ones getting the 30mm guns) are not currently DVH models, however the Royal Air Force assisted the US Army in carrying out load certification and coalition deployment trials with Stryker using the A400M Atlas almost simultaneously to the US announcing their intent to upgrade vehicles in the European theatre. Atlas has a much higher load capacity than C-130 and is capable of transporting the larger European 8*8s that are resident in Germany where 2nd Cavalry Regiment are deployed.

Basically it appears they looked at the whole encumbrance and fatigue system for Arma 3, which was pretty solid and unique and though: "Fuck it, lets just go back and copy Skyrim or something instead - everybody loves Skyrim right?"

Which versions of CBA and MRT are you running alonside SMA? MRT AccFns v.1.2 (latest) requires CBA RC6 (CBA v.1.1.2) or later. The CBA authors changed their keybinding system at that release back in April, so I had to update the MRT mod accordingly. Mixing in an older, outdated version of MRT with the latest version of CBA wont register the keybinds properly, and vice versa for pre-RC6 versions of CBA with the latest MRT.

Units as in grid units for scale? Object builder uses a 1 grid unit = 1 meter, scale. So set units to meters in Max and model according to that, or remember what units you have Max is set up in, export at 100% scale and then select the scale factor in Object Builder's import window that matches the relative size of your Max units to meters. e.g. if you're using a cm unit grid; set the master scale value to 0.01% in the importer, since 1cm = 0.01m and so on. 1mm = 0.001m, 1in = 0.0254m, 1ft = 0.3048m, 1yd = 0.9144m and so on and so on. You might be able to apply the scale factor in the exporter menu but personally I've always done it in the importer menu. Also, I recomend exporting as .fbx instead of .3ds. The .fbx importer in Object Builder has the best results of any of the available formats, so long as you export from your software properly by traingulating the mesh before export (otherwise OB decides which direction to divide your quads and can make a mess of the non-planar faces) and telling the exporter to include smoothing groups in the Geometry menu.

These are awesome additions! One thing with launchers in FFV though: Currently the 'Switch to Secondary Weapon' keybind doesn't work when in the FFV seats that allow launchers. You have to use the action menu "Weapon launcherName" or the older 'Switch gun / launcher' keybind to switch weapons to your PCML or whatever. 'Switch to Primary Weapon' and 'Switch to Handgun' binds work fine as always.

They seem squarely geared towards gamepad users (read: console players). I can fly the starships alright with the PS3 controller I have plugged in to my PC, but using the keyboard+mouse is beyond horrible. But yeah, my overall impression has been that terrain look gorgeous but the gameplay is a total mess; just throwing respawns and power-ups all over the place. There's no ebb and flow, or any kind of structure to the action at all.

It's British military parlance for Protected Patrol Vehicle. Used to be used to distinguish the basic variants of Mastiff, Ridgback etc. from the specialised variants, but later on they decided on calling them TCVs (Troop Carrier Vehicles). There are 4 variants of Ridgback in service; two of them are TCVs (difference between them is that one has a Protected Weapon Station and the other has a Remote Weapon Station) and the other two are the Command Vehicle and Battlefield Ambulance variants.

What format are your textures for the main body of the car? _CO.tga? or _CA.tga? Does the main body texture have any alpha channel parts.

Maybe... https://twitter.com/toadie2k/status/650933084775301120/photo/1

It's accurate to the uniform they're wearing: The old Osprey Mk.3 vest that the BAF DLC units wear was only produced in Desert DPM, plus a few sets in the "Hybrid DPM" that was developed for the PECOC program and Blue for civilian staff (a very small handful of Osprey Mk3 were produced in regular temperate DPM). The Mk.3 was being starting to be phased out by the "Osprey Assault" vest when MTP was introduced in March 2010, but this vest was still in plain desert sand or desert DPM, and a great number of troops were still issued the older Mk.3 vest along with their new MTP uniforms. The UK's body armour didn't come in MTP pattern until Osprey Mk.4 was introduced 8 months after the MTP uniforms were introduced; in October 2010 (1 month after the BAF DLC came out). Osprey Mk.4 was an improved version of Osprey Assault and visually very different in its construction to the Mk.3 vest.

IIRC in order for alphas render correctly on models with setobjecttexture you need a _ca alpha texture somewhere in your .p3d model to begin with. So you could just make a small cube somewhere in the model and apply #(argb,8,8,3)color(0,0,0,0,CA) to make that cube invisible and keep the opaque _CO procedurals that you have now. Or you can make the default textures applied to the the model #(argb,1,1,1)color(0.6,1,1,0,ca) and use hiddenselectionstexture in the config to apply the opaque _CO texture you currently want to appear when the object spawns, before you script them to change back to the _CA alpha textures again.

Ed: eagle2532 already explained his meaning, but pics are always helpful in illustrating the point He means why is Auto mode the first fire-mode setting on the FALs instead of Repetition/Semi On the real FAL the first setting after Safe is Repetion (semi-auto), then you have to turn the selector all the way around to Auto. The way it is now, kind of mirrors how the Kalashnikovs are (correctly) configured with automatic (ÐВТОМÐТИЧЕСКИЙ) first and single (ОДИÐОЧÐЫЙ) afterwards.

I think the way you're doing it with .hpp files like that will be fine (though personally I just write my configs all in the .cpp). I have cfgMods immediately after cfgPatches Your cfgMods.hpp may want to look like this though: class CfgMods { class Mod_Base; //External Class Reference class Falcons_Mod : Mod_Base { logo = "PAAAAAAATH!!!"; }; }; So that you get all the default parameters from BIS' Mod_Base base class and don't risk any "No entry config..." warnings popping up. I think the dlc parameter might go in your "Falcons_CombatUniform_DPM" class though, rather than the soldier class. However I've not done any uniform modding since the game was in Alpha so I can't remember how they're configured as inventory items like the one selected from Arsenal