da12thMonkey

That's because the "conventional landing craft" they're talking about are boats (LCVP, LCU etc.) so have a draft depth, or they are amphibious armoured vehicles (AAV-7, BvS 10, MT-LB etc.) so get bogged down in extremely soft coastal mud/sand I said all hovercraft are amphibious. Whether it's LCAC, Zubr, Griffon, BH7 or another type, all civil and military hovercraft are designed to travel over water of any depth, accross coastal mud and sand or pack ice, and arrive at a solid landing ground.

:huh: But all hovercraft are amphibious... it's kind of the whole point of them

IRL the above aircraft is not black exactly. It's one of the F-16s that use the same 'Have Glass V' paint used on the F-35, which is a colour called "FS 36170" Camouflage Grey http://farm4.staticflickr.com/3712/11713872694_0c755ab287_b.jpg https://c1.staticflickr.com/9/8298/7765048888_42ed1a4a35_b.jpg http://www.fox-two.com/schemes/101-F-16C-412sd-TW.html black looks cool though

You don't have to remake the whole config at all, just inherit the classes from the existing addon's configs (declaring their parent class first) and only write the parameters that you want to change within the classes that you want to modify. It's fundamentally the same as writing a replacement config like in this tutorial: https://community.bistudio.com/wiki/ArmA_3_Replacement_Config_Tutorial

The model.cfg shouldn't stay in the .pbo anyway - the data from it gets encoded in to the .p3d model file when the model is binarised. But honestly If you're just changing config.cpp/config.bin values you don't really need to modify the original .pbo at all. You can create a separate .pbo containing a config that patches the values in the original addon, and sign that file with your key.

Needs a class cfgMods to set up the logo and the dlc= config parameter to attach it to the item in Arsenal. https://forums.bistudio.com/topic/185275-how-to-have-custom-icons-for-items-in-the-arsenal/

No unfortunately, setobjecttexture/material only works on uniforms and backpacks so far as unit loudouts go. I raised it in the scripting discussion thread once before: https://forums.bistudio.com/topic/151099-scripting-discussion-dev-branch/page-35 Like bad benson said there, it seems there is something fundamentally different in the simulation of backpacks compared to other wearable items, where bags are more of an "entity" rather than just some proxy object.

It's this stuff: https://www.bistudio.com/community/licenses/licensed-data-packages They're going to be removed from Steam eventually though: https://forums.bistudio.com/topic/184311-arma-3-samples-and-licensed-data-packages-important-update/ torrent and direct downloads hosted by BIS will stay availabe.

"Time" animation source does the job if it's truly constant and you don't want to stop/start it. e.g. class radar_rot { type="rotation"; source = "time"; sourceAddress = "loop"; selection="RadarDish"; axis="radar_axis"; minValue = 0; maxValue = 4; angle0=0; angle1="rad 360"; }; The maxValue effectively works as your time period for the animation in seconds.

Strange because it definitely seems to be that parameter for me. I made these two test objects and placed them in the dev branch 3D editor under the same settings (surface snapping and terrain-following turned on): Blue, Red and Black one is class Land_MY_BuildBlob and Orange, Green and White one is Land_MY_BuildBlob2. The only difference between the two (besides colour) is that I added keepHorizontalPlacement = 0; to Land_MY_BuildBlob2 where Land_MY_BuildBlob inherits keepHorizontalPlacement = 1; from class House_F. My config is literally only this: class CfgPatches { class MY_BuildBlob { requiredAddons[] = {"A3_Structures_F"}; requiredVersion = 0.1; units[] = { "Land_MY_BuildBlob", "Land_MY_BuildBlob2" }; weapons[] = {}; }; }; class CfgVehicles { // Parent class declarations class House; class House_F: House { class DestructionEffects; }; // Class of the my structure class Land_MY_BuildBlob: House_F { scope = 2; displayName = "My BuildBlob"; model = \MY_BuildBlob\MY_BuildBlob.p3d; vehicleClass = Structures_Military; mapSize = 20.27; cost = 40000; }; class Land_MY_BuildBlob2: Land_MY_BuildBlob { displayName = "My BuildBlob 2"; model = \MY_BuildBlob\MY_BuildBlob2.p3d; keepHorizontalPlacement = 0; }; }; The two models (MY_BuildBlob.p3d and MY_BuildBlob2.p3d) have only the following Named Properties in the Geometry LOD, plus ran Structure\Topology\Find Components and applied some (large) mass to it as one would expect of the Geometry LOD for a structure. Other basic LODs added were these ones:

Last thing I can think of that is a standard for buildings is that the classnames are supposed to follow a convention of being named class Land_NameOfP3D. So if one had a building model called TAG_MyHouse.p3d you'd have to make its classname Land_TAG_myHouse. No idea what the reasoning for it is - I always figured it was a necessity for Visitor rather than having something to do with the ingame simulation. Though again, maybe that's something you've already done.

The sample house model Test_House_01_F only has class = house, map = house, damage = building, Prefershadowvolume = 0 and sbsource = Shadowvolume properties, but as you say you probably have those right already. I've noticed there's a parameter in the config for Land_BagBunker_Tower_F where it has keepHorizontalPlacement = 1; this structure stays vertical where the other bunkers (that are conformal to terrain) don't have the parameter. Seems most other buildings inherit it from the House_F base class.

Only if you use PiP or something to achieve the half/half split, something like this (by Franze): but PiP has so many limitations like its lower frame rate, view distance, resolution (limited to 512*512) and I'm not sure you can do things like make the PiP scene tilt when you lean.

IIRC there's is a named property (or a couple of them) that you're supposed to use in the Geometry LOD of building models to make them stand upright on the terrain. Can't remember which ones they are exactly from these pages here: https://community.bistudio.com/wiki/Named_Properties https://community.bistudio.com/wiki/Oxygen_2_-_Manual#Properties and I don't have any of the sample models to hand at the moment, but if you look at some of the Arma 3 and/or Arma 2 sample models that might give you a hint. From reading those pages I guess it'll be something like the placement = vertical one, possibly also requiring class = housesimulated or just class = house as well. Oh and dude, I haven't seen you around these forums in years! It's striking up some OFP nostaligia :D

Should works exactly the same way, you just have to make sure you're not using modelspecial for the launcher since that makes it behave like a proxy object (which don't support any model.cfg animations or hiddenselections) Use things like the isSelected and hasMagazine animation sources to do things like telescoping launch tubes and show/hide the missile in the tube, instead of configging the ammunition swap to an alternate modelspecial geometry.

I'm guessing this fix was intended as the fix for this. However, ingame both hands positions now appear to be rotated 90-degrees to where the animator intended to hold the weapon - causing wrist clipping through the optics mesh among other things

The vanilla method of 3D scopes looks pretty bad if you use realistic FOV/magnification values, which is why BIS' higher magnification scopes still use the 2D method as well. The RCO, ARCO etc. are low magnification optics - they're only 2x magnification now (used to be 3.4x but BIS changed the baseline for 1x magnification). Giving them proper 4x magnification like an ACOG, based on current values, fills the screen and looks like ass so you have to move the opticview memory point further back to compensate and that causes the view to start clipping through the body.

Is SOCOM_PVS15_F_OFF in the model.cfg and does it have (or inherit) the PVS15 and L4_G24 named selections in that class' the sections[]= array

It's used similar to the map display in the game's UAS terminal: http://archive.defensenews.com/article/20130212/C4ISR01/302120027/Army-Arms-Every-Division-Gray-Eagle Video from the UAS is fed to the MFD screen in either the pilot or CPG's cockpit.

But you can already control UAVs from inside helicopters... or any other vehicle in the game for that matter :huh: Just put a UAV terminal in your inventory and jump in an Apache

Tom (Julien), if you have time, could the LODs in the A3_character_template sample model be updated to the current standard used by A3_character_example? i.e. with the new hitpoints LOD with different selection names I just figure it would avoid any confusion/disparity that might arise from addon-makers copying those LODs from the two different source files and finding that they're different. I know people already tend to source the flesh parts like hands, legs and the proxies from the template model rather than detaching the topology from the full character model.

More fictional bullshit fun! I did some French Navy "F-14F" retextures this time. The Vought F-8 Crusader occupied the fleet defence interceptor role in Marine Nationale prior to the Dassault Rafale entering service, so I reckon that's the niche my "F-14F" would slot in nicely. All three schemes are based upon the paint schemes of Aéronavale F-8E(FN) (1964-1994) and later F-8P "Prolongé" airframes (1992-1999): Gull Grey and White underside. Crusaders were delivered with the same basic paint scheme as those in US Navy service, so this is reminiscent of the USN Tomcat scheme too. Carries the arms of Flottille 12F All-over Gull Grey. Generally similar to the original paint scheme. Aéronavale's whole F-8E(FN) fleet was repainted without the white underside and control surfaces by mid-1979. Carries the arms of Flottille 14F All-over blue-grey. Worn from 1986 onwards, until the upgraded F-8P variant was replaced by Rafale in 1999. Carries the arms of Flottille 12F again DOWNLOAD http://imgur.com/a/RYr2v

Oh, you're doing a static animation? I misread the op due to the last part and thought you were doing an handanim Not exactly sure how one would set that up on static move since I normally only do them for vehicle crews (i.e no weapons). But I think it's done setting rightHandIKCurve[] = {1}; in the config. Might also need to set weaponIK = 1;

Might be at their end. If I try to select a version of the mod through the "Change Version" menu in PWS, nothing shows up at all in the drop-down window. Usually it gives you the option to select "Latest (any)" or "Latest (prefer stable)" even if the current versions is the first release version. So the fact it shows nothing at all is a bit odd. Seems things got fixed now and PWS is capable of updating from V.0 to V.1.0 (weapon and unit pack updates are available now too)

No, that's just telling the game which .rtm file to load the animation from. To make hand animations fit a weapon you have to physically move the "weapon" bone in the animation rig to somewhere near the shoulder position (doesn't have to be exact) then pose the hands around the weapon. The handanim type animations only use the relative position of the "RightHand"/"LeftHand" skeleton to the "Weapon" bone - everything else is done with inverse kinematics. So if you have a custom weapon model you need to fit the unit's hands around, import the model to the position where the "weapon" bone is in the rig and then animate everything around it. To correctly orientate your model to the default "weapon" position, you generally have to import your gun model to the animation rig then rotate it 90 degrees in the Y-axis around the [0,0,0] grid position (origin of the grid) making the muzzle point forwards, then move it 1 grid unit along the X-axis so sit on the anim rig's right hand side. You can then link your model to the "Weapon" bone and it'll move whenever you move that bone (probably want to delete your weapon model from the rig before you export the animation).