da12thMonkey

Does the laser weapon just naturally follow the pilotCamera direction now then, instead of memoryPointGun= for the vehicle/turret? We don't need to add extra mem points or model.cfg animations for moving the laser direction? Looking at how the laser turret works on UAV I was curious how aiming the laser weapon through pilotCamera (not a turret) would be separated from the plane's gun axis when we only get one "gun" memory point per plane/turret. i.e. you don't want the Wipeout's cannon muzzle to slew around like the IRST/laser designator and act like an AC-130 :D nvm: I tried it out with simply adding this addmagazine "Laserbatteries"; this addweapon "Laserdesignator_mounted" on the Wipeout init line (or e.g. RHS A-10, or other aircraft with pilotCamera), and I can see that it works in following pilotCamera without anything doing to the model :D

The USMC don't use the M320 at all. Only the US Army bought them.

Should be there. The .pbo for it (mrt_fir_f16_il.pbo) is still in Foxhound's Armaholic mirror that you linked to: Each country has its own .pbo in case people don't want to use some of the countries, and so you can tell what is in the download. So as long as that file is there, you should have the Barak. In the editor the Barak is under BLUFOR (like the F-16s in the NATO pack, but has a different logo next to it) whereas the other Midde East F-16s are under GREENFOR. So check that you're looking for it in the correct place.

Weapon attachments and weapons classes themselves are not selectable from the Eden Editor; you need to make a weaponholder for your optic in cfgVehicles that holds the weapon. Weaponholders are effectively an ammo box for one item. E.g: here the _Item_optic_ cfgVehicle class inheriting from Item_Base_F contains the _optic_ cfgWeapons class that inherits from ItemCore under class TransportItems class CfgVehicles { class Item_Base_F; // External class reference class RKSL_Item_optic_PMII_525: Item_Base_F { scope = 2; scopeCurator = 2; displayName = "[RKSL] 5-25x56 PM II"; author = "da12thMonkey"; dlc = "RKSL_Attachments"; vehicleClass = "WeaponAccessories"; editorCategory = "EdCat_WeaponAttachments"; editorSubcategory = "EdSubcat_TopSlot_Optics"; class TransportItems { class RKSL_optic_PMII_525 { name = "RKSL_optic_PMII_525"; count = 1; }; }; }; };

I've done prepared a small update to the two F-16 packs containing NATO and Middle Eastern textures to bring them up to date with Firewill's 1.0/1.1 version of the F-16 Also added them to the Steam Workshop NATO F-16 Pack: (updated 16/08/2016) Changelog: Added interim Romanian Air Force texture. Will be updated in future to match real markings when they arrive (real ones being tested in Portugal don't have their markings yet, only camo) Eden Editor preview images Drogue chute tails activated for appropriate air forces (Belgium, Greece, Netherlands, Norway, Turkey) P&W engine nozzle models activated for appropriate air forces (Belgium, Denmark, Greece, Netherlands, Norway, Portugal, Romania) GE engine nozzle models activated for appropriate air forces (Turkey) Wide-Angle Raster HUD models activated for appropriate air forces (Turkey) Updated images for the AWS texture selector Download v1.3: Mirror 1 - @DropBox Mirror 2 - @Steam Workshop Gallery Falcons of the Middle-East Pack: (updated 16/08/2016) Changelog: Eden Editor preview images Drogue chute tails activated for appropriate air forces (Egypt, Israel, Iraq, Jordan, Oman) P&W engine nozzle models activated for appropriate air forces (Egypt, Iraq, Jordan) GE engine nozzle models activated for appropriate air forces (Bahrain, Israel, Oman) Updated images for the AWS texture selector Downloads v1.1: Mirror 1 - @DropBox Mirror 2 - @Steam Workshop Gallery F-15 packs will probably get updated in a few weeks when I have more time.

.fbx (2014 version IIRC) works fine from Maya for me if I triangulate the model before exporting But IIRC PuFu's said he's had problems with it from Max, on models where faces have multiple UV sets.

Have you checked you can even have a proxy on helmets first? Since the helmets themselves are loaded on to a proxy on the character model, you're sticking a proxy on a proxy - which IIRC doesn't inherently work apart from a few specific applications on weapons. But anyway, the proxy retexture thing works on this basis: https://community.bistudio.com/wiki/Arma_3_Setting_Textures_for_Wrecks So you'd have to add the selection name from the proxy to the main hiddenSelections[] array of the object that contains the proxy, and make sure it has a separate name otherwise "camo" on the object and "camo" on the proxy receive the same texture.

When viewing a texture in the UV editor, it will fill one square then repeat over again in the next square. So any parts of the model that use that one texture, need to be arranged in the UV space in such a way that their position is relative to the texture space, rather than the UV space. You can have parts that are moved over in to the next tile but they will be positioned relative to the texture, not relative to other objects in the UV space. This is the UVs for one of the models I've been working on (with a basic shading texture overlayed on the backgroun in the UV editor). You can see that it uses two tiles. But the positions of UVs in the lower tile relate to duplicate faces that require the same texture as those in the top square, or they correspond to gaps in the layout in the top square. They don't really need to be in the second UV tile but it helps me select the duplicated parts independently of the original ones in the main 0-1 UV space If I move everything up by 1 unit in the V axis you see that it all fits in place. (There are a few gaps remaining for parts that I have in another variant of the same model) Most models in the game have several texture files. Each one has its own UV map. You don't want to make too many separate textures though because the more files that the game has to load with a model, the bigger the impact on the game's performance. Two or three texture files for the external parts of the aircraft is the norm. Then a couple of extra ones for the interior in the Pilot LOD.

Your UVs are spread over two tiles. Your texture file exists between the 0 and 1 coordinates of the UV space, then repeats on the next tile. So if you've got the UVs spread over 2 tiles you're effectively just overlapping the two of them within the same texture space. Need to scale the UVs by 0.5 in the U axis so that they fit in to one square. In the UV transform window, set the "Center" to "other..." and set it to the [0,0] [u,V] coordinate (so that it uses the far left edge of the first UV tile as the centre of the U axis). Then enter 0.5 in the U-axis scale, and 1 in the V axis scale (so that it remains the same size vertically, but half the size horizontally) It'll look squashed in the plain square UV space. But when you apply your 2:1 ratio texture to it (either via the E key on the model, or Filter\Browse New Texture in the UV editor), the UV space will stretch to a rectangle to match the texture's aspect ratio and everything will line up.

There are separate tabs in the Arsenal for magazines for currently equipped weapons, and magazines for all weapons. In the same manner as the extra tabs for grenades, explosives and misc items.

Memory LOD of the model. The comments in the config example tell you that they're memory LOD points: Should just be a matter of having single points in that LOD with those selection names.

Tools will convert .png to .paa AFAIK, but .tga is the standard. I'm unsure whether the automated process that Opteryx mentioned with buldozer and binarisation, works as smoothly with .png as it does with .tga since I only ever use .tga. But ImagetoPAA is certainly capable of manual conversion of .png to .paa, so you could always just batch convert them with that tool (don't use TexView to convert stuff - takes to long doing each one manually). I figure it's .tga because with .tga you can choose whether to save as 24-bit (RGB+1-bit Alpha) or 32-bit (RGB+8-bit Alpha) along the same lines as the output _co.paa and _ca.paa

Diffuse/Albedo map, tangent space normal map, ambient occlusion (ambient shadow) map, specular map and gloss map are the ones that are generally used. Opacity is handled by an alpha channel in the Diffuse, but you should isolate faces of the model that need an alpha texture (such as windows), on to a separate set of maps rather than including it with the main body of the model https://community.bistudio.com/wiki/ArmA:_Texture_Naming_Rules - it's absolutely critical that textures use these naming suffixes for the type of map you're using, before they are converted to the game's .paa format i.e. from the above you will want a _co, _nohq, _as, _smdi and maybe a _ca if you have glass or something. The other maps types listed tend to have more specialised applications. Normal map (_nohq) from other software usually requires the Green channel to be inverted for use in Arma. Arma 3's specular map _smdi is kind of a combination formed from placing Specular map in the Green channel and Gloss map in the Blue. Usually the specular map requires a lot of tweaking to get the right greyscale values in G and B rather than direct output from other software e.g. Substance Painter or dDo. All maps must have dimensions that are 2^n pixels (64, 128, 256, 512, 1024, 2048) rather than random sizes. Can have 1:1, 1:2, 2:1 etc. aspect ratios so long as the dimensions are correct. (e.g. 64*64, 512*1024, 4096*2048 etc.)

That's a separate config addon by Robalo that uses MRT to switch between different versions of the vanilla sights. There's a link on the first page but I don't really know if it still works.

There was a version of Mk13 with a green AICS quite a while before the Mod.5. Doesn't have the highly tapered tip on the barrel and notch for suppressors http://sofrep.com/wp-content/uploads/2013/03/MurphandBurkhart.jpg Mod.5 with suppressor (centre) next to some with threaded muzzles and brakes (Mod.4?) and some green ones like the above, with regular straight tapered barrels http://img.photobucket.com/albums/v177/imsoscene/IMG_0451.jpg~original I think this one is the same, but in more recent use: http://img.photobucket.com/albums/v37/ermey/Guns/Clone/ranger-sniper-photo-hr_zpsb58e8774.jpg~original

Yes. Has been fixed for 0.4.2

Unfortunately there's a lot more to making a M1151 or M1114 that sticking the GPK turret on the roof of the existing M998 model that is in RHS.

It's not a problem with our config (addon wouldn't build correctly if it was). It's a problem with whatever you're using to convert the config.bin to config.cpp Your tool probably isn't capable of parsing the += operator we use to add muzzles to the game's default Put and Throw weapons. If I use Kegety's old unRAP tool I get the same result as you did above. But with BIS' CfgConvert from the official Arma 3 tools it yields: Which is how those classes are written in our raw development files. In short: your tools are out of date

So is the grey opaque texture used for the bottom part of the object a completely separate _co texture to the transparent _ca texture used on the top, or is the whole thing one texture?

Was true until the latest version (RHS:USAF 0.4.1.1). Now RHS has an entirely new and improved set of Daniel Defense rail models made by Soul_Assassin.

You have to write your own config.cpp in notepad or some other text editor to patch it, and then compile that in a .pbo addon file using one of the many available packing tools. Opening the game data, modifying things and then repacking it is an awful, awful idea.

They're found in the cfgweapons class, under fire modes For example, under class LMG_LMG_Minigun_heli>>class manual it says the gun has dispersion = 0.0087; (values are in radians) and reloadTime = 0.033; (time between shots in seconds)

1. TiTan suppressor is only for the M2010 - it shows up for the M24 due to some weird inheritance behaviour in Arsenal, but isn't designed to go on the M24 (doesn't have a threaded barrel or muzzle adapter for suppressors) 4. PEQ-15s should automatically replace with one that fits the HK416 when you initialise a mission in Eden or "Try" in Virtual Arsenal. If not, go in your inventory and remove it and put it back on the weapon manually - it should trigger the script again and replace it with the 416 version. In this respect it works like the grip-switching script we have for the TD grip, AFG etc.

Difference between the various AK-103 variants is that they have different fire-modes (semi+full-auto, semi+burst or semi-only) The fact that certain special/hidden states of weapons and attachments disappear when opening the arsenal is unfortunately a bit of a game limitation. We try not to clutter up Arsenal too much with multiple variants of the same item that are necessary for the scripted features we have, which means we need to hide them from Arsenal. But unfortunately this means Arsenal doesn't play ball when you're already holding one of those special hidden classes that it doesn't recognise, and occasionally requires you to reselect the base class from the lists again.

Unfortunately, even using the new indexed "zeroing.N" animation sources, a weapon seems to stop animating with the zeroing source when an optics attachment is fitted. Though it will still cycle between view memory points It did still work when BIS first changed the animation sources for 1.60 (had your SMAW in RHS set up to use zeroing.-1 and it worked back then), but seems there were subsequent changes between then and 1.62 Apex release