da12thMonkey

I'd be very surprised if BIS were willing to add 3rd party dependencies and stuff like that, to something that is meant to demonstrate the one-click nature of the Workshop and Launcher. Very easy to add with a small config addon though: Download: ADR-97 Joint Rails compatibility @ Steam Workshop ADR-97 Joint Rails compatibility @ DropBox Will probably stick the config on workshop in a bit, if Publisher plays ball for once.

I also get an error with certain scopes saying: Seems like the smdi stage in colimglass.rvmat was changed at some point (maybe not recent) from: class Stage5 { texture = "a3\weapons_f\acc\data\colimglass_round_smdi.paa"; uvSource = "tex"; class uvTransform { aside[] = {1.0, 0.0, 0.0}; up[] = {0.0, 1.0, 0.0}; dir[] = {0.0, 0.0, 0.0}; pos[] = {0.0, 0.0, 0.0}; }; }; to class Stage5 { texture = "#(rgb,8,8,3)color(1,0.4,1.0,1,SMDI)"; uvSource = "tex"; class uvTransform { aside[] = {1.0, 0.0, 0.0}; up[] = {0.0, 1.0, 0.0}; dir[] = {0.0, 0.0, 0.0}; pos[] = {0.0, 0.0, 0.0}; }; }; And the _smdi.paa removed from the .pbo a few days ago. However, this creates a problem for addon data that was binarised with colimglass.rvmat before the change occurred (or if an author doesn't update devP to unpack the newer .rvmat for future use), because .rvmat texture paths get compiled in to the .p3d when it's binarised. Now they're looking for a texture that no longer exist. So please can we have the .paa file back even if the actual updated .rvmat no longer uses it? :)

Reading the logistics section of yesterday's SITREP #152 regarding the improved weapon animations sources. Therein it says: But testing recently, I noticed the old Zeroing2 source doesn't seem to have carried over - the GL red-dot on the MX, Katiba, TRG etc. has stopped rotating (OP_eyeN memory points cycle through the various angles when zeroed, it's just the animating parts on the weapon). Obviously that could be fixed by updating models to use Zeroing.1, but it would be nice if the old anim source continued to work like reloadMagazine2 apparently does without replacing with reloadMagazine.1. I'm assuming there should be no conflict, having sources called Zeroing2 for legacy second muzzles and the new Zeroing.2 for a 3rd muzzle since the reloadMagazine equivalents work. btw, I miss the feedback tracker for this sort of thing :D

If it's rotating around some axis that seems distant from where you placed your axis in the memory LOD, it's almost certainly because you don't have the named property autoCenter = 0 in your weapon's Geometry LOD. You need to right-click the named properties window while the Geo LOD is active ([Ctrl+1] toggles the window if you don't know which one it is), then in the "Name:" field type autoCenter, followed by 0 in the "Value:" field

That's because vehicles, units etc. use CPU stencil shadows where everything else in the game uses GPU shadowbuffer. https://dev.arma3.com/post/sitrep-00143 i.e. the shadowbuffer isn't precise enough to generate shadows for small detailed objects like you would see in the first person view when carrying weapons, or the cockpit of a vehicle.

No, since in 1.56 they use the GPU shadowbuffer similar to higher shadow settings https://dev.arma3.com/post/spotrep-00052 Some objects such as weapons and vehicles still have stencil shadows https://dev.arma3.com/post/sitrep-00143

_smdi uses greyscale information from the Green channel in the image to map per-pixel specular intensity to the model (white is more intensity, black is less intensity). Specular intensity is scaled relative to the specular[]={R,G,B,A}; array in the .rvmat. So specular[]={0.5,0.5,0.5,1}; is a sort of reasonably nice, mid-intensity specular highlight, specular[]={1,1,1,1}; would be bright white specular highlights for something that's quite shiny, and something like specular[]={10,10,10,1}; would be an absolutely fucking blindingly intense white. You can make the highlights different colours with different RGB values too if you need. The greyscale from Blue channel is used to map glossiness - which acts as a 0-1 scalar to the SpecularPower value in the .rvmat (white is full power, black is 0 power). The Red channel is left blank white. https://community.bistudio.com/wiki/RVMAT_basics#Basic_surface_setting The combination of the R and G channels is what gives the pink (magenta), yellow, red etc colours. Using 0-1 colour scales for RGB values instead of 0-255 colour space: Red = RGB [1,0,0] so that's black in both the specular and gloss, so that material would be very matte. Magenta is RGB [1,0,1] so low specular intensity and the highlights are as wide as programmed as the SpecularPower value. Yellow is RGB [1,1,0] So at maximum intensity with a very wide specular reflection. _AS is magenta and white because it only uses the green channel, whereby the black parts will be the intense Ambient Occlusion shadows. If you save a greyscale ambient occlusion map as _AS.tga, the tools will convert it automatically to the magenta one by discarding the shading info from the R and B channels that it doesn't use.

AFAIK it doesn't do anything physically to the model. Zeroing just applies an angle to the simulated bullet when it spawns at the chamber memory point. The angle applied to the bullet is calculated by the engine so that the round's ballistic curve will cross the plane of the eye memory point at X meters away from the player, where X is the selected zero range.

Rifles with GLs have two muzzles - one for the rifle part and a separate muzzle for the GL. They're indexed in the form of an array[] = {0, 1, 2, 3...} etc. Adding extra muzzles to weapons in the config you have the parameter e.g muzzles[] = {"this", "EGLM"}; where each extra muzzle beyond "this" is effectively a separate cfgweapons class with its own set of compatible magazines, firemodes etc. So "EGLM" in the example is the classname of the EGLM cfgWeapons class. But anyway, weapons only really had a limited number of animation sources, and most of these animation would play regardless of which muzzle the weapon was using. For example there was reloadMagazine which played on the whole weapon whether you were reloading the rifle (first muzzle - index 0 in the array) or the GL (second muzzle - index 1 in the array). So when you'd reload the GL the rifle mag would disappear. And when you fired the GL, the reload animation source would cause the rifle bolt to slide back like you had fired a shot with that muzzle as well. There are a couple of animations that were separated by selecting the second muzzle like the zeroing feature for the GL's red-dots using the zeroing2 source. And you know how in a recent patch, BIS added animations for the grenade launcher tubes opening when you reload them? That was because they added a new animation source called reloadMagazine2 to provide that function for the second muzzle. It fixed the issue with mags dropping out when reloading the GL since there was now separation of the two sources. It was great that BIS added those, but they'd only apply to a secondary muzzle; i.e. a muzzle that was index 1 in the Muzzles[]= array. If you wanted to make a weapon with 3 or 4 muzzles you still didn't have extra animation sources for those. It was kind of frustrating to wait for BIS to add these kind of specific, named animation sources to add these extras for the 2nd muzzle because there were lots of actions that could benefit from this kind of separation of the muzzle animation sources in addition to reloadmagazine and zeroing. However, after this change, most of the weapon animation sources can be configured in such a way that you can make as many weapon muzzles as you like, and have unique anims for each of them without the need for BIS to have programmed a specific named animation sources for each one. They cover far more actions than were previously available to alternate muzzles. So now you can have bolts, triggers, selector switches etc. etc. that only move when the player is using a certain muzzle on that weapon. Or if you want them to apply when any muzzle is selected, you can. One just has to put .N after the name of the animation source (e.g. reload.N), where "N" is the index of that muzzle in the Muzzles[]= array

Manly tears were shed when I read the biki page earlier this morning. Honestly, fantastic news.

Believe me, it's not necessary on 90% of content. Most stuff looks far better without making any changes at all. I was asking about a very specific texture/material setup I had on a model, where virtually all diffuse colour information was in the lower 5% of the brightness scale and 0% of saturation, and reflections were fairly low. So it was all out of range of the new colour grading curves. Other models I have that are black, don't look so "off" because there aren't other similar materials on the model, and they have more fresnel reflection in the .rvmat than my EOTech did anyway (don't want lots of fresnel on that because it's mostly plastic).

Is there any general advise that the art team has on necessary changes to textures to fit the new lighting and colour grading? Or is it something you tackled on a case-by-case basis looking at each texture/model? I had noticed on one of my models that used a bunch of near-black tones (all < [12,12,12] RGB) that the tone mapping caused all of them to crush down to a very homogenous black colour. Whereas the grey variations were more apparent on the model in the old lighting system. As a result I've had to lift the brightness of those greys by about 10% (closer to [30,30,30] RGB) to make it appear less flat black. So the opposite of what you've done with the ground textures really :D Same model in the old lighting system: http://da12thmonkey.rkslstudios.info/A3/IMG/EOT_ingame.jpg

Yes, that's HDR in action. The effect is nowhere near as bad as it was in Arma 1 and 2 though.

The Army's Wildcats are not supposed to be a troop-carrying helicopter as much as the older AH.7 was. It's tasked in more of a reconnaissance/surveillance role akin to what the Gazelle used to be for. Similarly, the RN's Wildcats wont be fitted with dipping sonar because it's not their role. Wildcat's cabin seats are the modern crash-worthy type that you get in Merlin etc. There are "rails" along the floor panels where folding mid-cabin seats can be repositioned to meet various seating configurations. 2-3 seats can also be fitted along the rear bulkhead. Side-facing seats would require some other layout for the floor fittings Source of photos: http://www.britmodeller.com/forums/index.php?/topic/234950821-lynx-to-wildcat-conversion/page-4 Pretty much everything the MoD buys these days has to have safety seats even if it means reducing the number of pax carried. They're on everything from the SV trucks to the upgraded Warriors (will only carry 6 dismounts in future). H&S would probably have a fit if they tried to install bog-standard bench seats like it was the 1980s/90s.

Are there config changes that need to be made in association with this? I'm noticing that DLC icons for mine and other community addons, as attached to that item/entity class with dlc = "some_cfgMods_classname"; and pathed to that "dlc" by class CfgMods { class Mod_Base; //External Class Reference class some_cfgMods_classname : Mod_Base { logo = "path\To\Logo_ca.paa"; }; }; are no longer showing in Arsenal/Edit Loadout.

Yeah, seeing the new target lead indicator in action with the Cheetah SPAAG and Wipeout's cannon immediately made me think how great it would be if there was a CCIP indicator that worked on a similar basis. The using the TLI on the Cheetah and watching rounds actually hit what I was aiming at, is immensely satisfying compared to trying to walk tracers ahead of an aircraft and hoping the "locked on" diamond appears at some point so that a few rounds maybe manage to intercept the target.

Turning water reflections on eats a number of frames for me. But my rig is ancient.

If it's indicating that pilotCamera for the Wipeout and other fixed-wing aircraft, now has all the features of the targeting turret on UAVs (ground locking, maybe laser designating etc) then its pretty bloody splendid IMO. Oukej has stated before that he wanted to add proper targeting pod features to fixed-wing. http://steamcommunity.com/workshop/filedetails/?id=334622056

1 grid unit in Object Builder = 1 meter ingame. If you're building on object in other software with grid units set to cm scale or inch scale or whatever, you can pick the appropriate scale factor from the import menu. Otherwise you can create a reference cube in Object Builder (\Create\Box\ from the toolbar or press the [F7] key) and enter the dimensions you want the object to have. e.g. you know your handgun should be 17cm long so enter 0.17 (17cm = 0.17m) in the "Size" fields in the Create Box menu, then scale your handgun to fit inside the bounds of the box. Then delete the box when you want to save the .p3d

The GL sight modes still work for me Are you trying to use the GL while the weapon is deployed on a surface? You cant use the GL firemode when deployed. Nah, he's right - they don't work. I hadn't received today's dev-Branch update when I tried first time around (thought I had). So sorry for claiming it worked when it doesn't

Compositing all the details one makes to fill a view LOD, with all the external detail for the res LOD, would quite naturally make the model pretty high poly compared to how it would be composed ingame. There are sensible optimisations that can be made for the ingame asset that still utilises all the required detail of the original model one way or another. e.g. a viewXYZ LOD quality interior like is shown in the portfolio piece possibly wont be present in the resolution LODs. And it's quite likely that the view LOD will have certain parts removed that are not visible from the perspective of the player's position inside the vehicle. But still, one builds an open-cockpit model such as this to incorporate all the necessary details so that they can be baked to the material, then optimises the mesh for how it actually shows in the game engine. It's obvious from the use of proxies on the Mora, Gorgon etc. (the parts we can't setobjecttexture are proxies) that BIS were already running in to the vertex limit when making a bunch of Arma 3 assets. However, the fact can now binarise models with 32-bit vertex indices, indicates that BIS have made effort to extend the poly limit to accommodate so-called "next gen" meshes meshes and modelling workflows for Apex (when does it become current gen? :D). Probably for the reason that cutting out the need to make complex work-arounds to beat the animation and retexturing limitations that using proxy models leads to, will make development so much more streamlined. The proxy arrangements on the speedboats and Ghosthawks with their multiple weapon stations are pretty insane and were no doubt time-consuming to plan and work around. IMO none of it really suggests that there's going to be an outright increase in polygon counts for Apex assets compared to A3 stuff, since we already had models ingame that were exceeding the 32k vertex (15-bit index?) limit in certain circumstances. And I don't think it would be sensible for people to look at the 32-bit index extension as an excuse to go completely batshit with polycounts. But it'll certainly make it easier to make nice models. But I dunno. Maybe it's a discussion for this thread since no Apex content is on dev yet?

But it's scaled. All BIS weapon scopes and vehicle optics (as well as many community mods) have their magnifications values based on multiples of the right-click zoom, not the default (init) zoom level. If you disable the right-click zoom it means weapons with scopes are 3x more powerful than they should be.

Okay: Download

initspeed in the magazine class is the one you want typicalspeed in ammo is a value that controls hit/damage reduction when the ammo's speed drops from initspeed at the muzzle to below the typicalspeed value (it's there to simulate loss of kinetic energy in imparting damage on the target). It's not really relevant to grenades since they do all their damage by explosion, but it's there because like I said; they're basically configured the same as bullets and shells

Yup, it's the initspeed in the grenade magazine class class MiniGrenade (RGN) has initSpeed = 26; and class HandGrenade (RGO) has initSpeed = 18; Grenades aren't really any different to bullets and cannon shells in terms of simulation - they have a speed and airfriction that affects their ballistic arc.