da12thMonkey

Was simply a statement made in the recognition that 1.66 was close. When we comment on upcoming BIS patches, the inferences are twofold: We feel releasing anything as big as an RHS update, just a few weeks before a main branch patch would be stupid. Since third party content could (and often does) get broken when BIS make major updates to the game. i.e. "We cannot release right now." The proximity of BIS' update means we can begin to integrate some of the features introduced in 1.66 that have been observed, recorded and investigated on the devBranch changelog and discussion thread, but have not yet been integrated because it'd mess up testing builds for members who don't run devBranch. i.e. "The next release will have even more nice features." Any assumption from the former that "RHS must also be close to finished if it's being pushed back" (probability of being a false assumption), is immediately offset by the need to spend enough time to test and integrate new things in the latter (a fixed truth of addon-making). So there's no net commentary on whether the mod will be near to the patch or not. Work goes on. BIS patches are either a positive or negative influence on individual morale and work-rate. Late nights spent with modding tools, abound.

First-person "view Pilot" LOD should not contain the \A3\characters_f\Heads\bysta proxy for attaching the head model Recommend you remove all proxies from that LOD and only copy those from the Pilot LOD of the A3 sample models (i.e. don't just paste the ones you used for other LODs)

Uniforms in Arma 3 are configured as a class cfgWeapons inventory item and a class cfgVehicles character model. The two are linked together with the uniformClass config parameter. https://community.bistudio.com/wiki/Arma_3_Characters_And_Gear_Encoding_Guide#Uniform_configuration class rhs_uniform_g3_mc is just the cfgWeapons item, so you are inheriting the associated character model uniformClass = "rhsusf_socom_mc_uniform"; from that item without creating your own custom retexture class for the actual character model to switch to.

It's the 9M120 missile tubes and pylon for the Mi-28

If your textures assigned to the weapon model have some kind of alpha channel in them, this will happen. Common accidental reason it happens are if someone includes the muzzle flash mesh inside the weapon model rather than making it an external proxy model, or not using the conventional _co.tga (when saving as 32 bit instead of 24 bit) or _co.png naming suffix when converting the base texture format to .paa - which might cause the alpha of the game texture to not get formatted in the intended manner. But if the alpha is an intended part of the weapon texture set itself, it can be fixed with a forceNotAlpha = 1 named property in the weapon's geometry LOD

Make a view-Pilot LOD with nothing in it. This is the convention for most headgear, glasses and NVG items

Res LODs can be a bitch. How to make them kind of depends on what software you're using. If it's only Object builder, your options are kind of limited to either remodelling and re-UVing, or merging verts together so that the faces between them collapse and the UV space sews up too. Other 3D programs provide you with the option of selecting entire edges, deleting those and then deleting the verts that used to form those edges and letting the mesh relax back between the new endpoints of the edge. So long as you steer clear of deleting UV border edges the UVs will relax inside the boundaries and you shouldn't have to do much to change the UV maps except occasionally to sew up holes. As I say, it depends on what your 3D program is like. Personally I only know Maya, and have some insight in to 3DSMax from listening to a bunch of people who use it while we discuss modelling topics, so I know it can do basically the same process. But I'm pretty sure blender and other software are capable of the same methods of manually removing edges and then the extraneous verts without having to remodel the entire bloody thing and make new UVs that align with the original ones. To show an example of this I'll show you how I reduced certain parts on a model I have. In the base there is this dense topology in the pilot view and top could of visual LODs where I have added a bolthead that is sunk in to a hole. 1 I've UVed this in a way where the UV island for the face of the bolthead are placed inside the corresponding holes in the base so that if I remove the bolthead geometry and fill in the hole, it will still look like it is there in the texture. 2 3 I feel this is a pretty good area to reduce the face count while maintaining the appearance of the original model from a distance. So I go about removing any more faces attached to that area that wont be useful when I close it up. 4 And that leaves me with the above ring of verts on the old UV border edge (the edges that are highlighted as slightly thicker, are the border edges) that I can start to merge together to reduce the number of points. 5 But you'll notice that the border edge verts don't move in the UV space when they are merged. Therefore I have to sew the UVs for those points together along the edge I just closed together, so that it matches the model topology again and doesn't distort the texture. 6 Notice that the edge is no longer highlighted with a thicker line, now that it's sewn together and no longer forms a border edge. I can then repeat that on the other side and I'm just left with a UV island that has no internal UV borders. That means I can just delete any of these extra edges wholesale and then remove the verts that were attached to them to form nice tri/quads instead of nGons. 7 You'll see at the bottom though there are two verts that didn't delete because there is a connecting edge on the bottom side of the mesh. So then my next task would be to remove the unnecessary edges on that side of the model or reconnect verts that cannot be deleted because they form an outer border edge of the UV island in oder to get rid of nGons. As I said, you want to avoid deleting the outer UV border edges unless you're deleting the whole part of the mesh that connects to the other side of that border (like the bolts at the start of my example). If the other side of the border exists, then the UV map will try to bridge the gaps across the UV space between different UV islands 8 9 My personal recommendation is to do that kind of process for the first LOD or two to make sure you have maximum control over how the mesh is decimated, and the silhouette remains intact. But after that, most mainstream 3D apps have a "reduce" modifier of some sort that will delete edges, merge verts and generally reduce the polycount of an object for you by a set amount (usually offers to do it in terms of percentage). However the results of doing this can be a bit messy with complex models and merge parts together that you don't want to merge together if you're going to animate the model. So you need to be careful. (Same model from the start but just applying a 50% reduce modifier to the whole thing 10 face count is reduced to an appropriate degree but there is no real logic to the meshflow anymore) You can do this from the get-go if you're none too concerned about appearance after the top LODs though and just want to do it in the most fast and lazy way. But, there is also a great thing called Simplygon that can yield better automated results than the reduce tools in most 3D apps https://www.simplygon.com/and I know a bunch of people who use this.

No.

The RMR on the Larue mount as a standalone? Maybe. I'm Not sure yet: I've scaled the textures at 1024*1024 for the RMR and mounts to keep it fairly well optimised when loaded on top of the MDO and RCO (yep, I made a RM35 piggyback mount for the existing TA31RCO too). So my concern is it might look a bit low-res as a standalone optic. The lens textures and materials are the same as in the other addon I linked to in my previous post. The base transparent texture has a teal coloured tint but its visibility seems to depend on the ambient lighting conditions http://imgur.com/a/gP2VG I might try and adjust the lens materials a bit and see what happens, but the pics are how it is at the moment Yeah. Being a Brit myself; I was modelling the TA648RMR-UKS (UK Sharpshooter version for L129) first, and reworked the completed high-poly for RHS when I joined. http://i.imgur.com/1zB2wTZ.jpghttp://i.imgur.com/42jyWcS.png Will go back and finish the UK version for my addon at some point when I'm done with the MDO. It just needs the UV mapping, baking, and generating textures and materials with Quixel Suite. But working on the RHS one has certainly prepared me for all of those tasks.

No Docter It'll have a Trijicon RM05 RMR modified from the old RMR I have on my UK scopes (re-textured with a fibre-optic illumination strip, a new Larue mount model, and an amber dot instead of a red one). I'm nearly finished.

Tweaking the gating/contrast on the TI equipment definitely has my vote. VBS and Steel Beasts do it well Configuration-wise I'd also like to be able to set different view memory point positions for each vision mode, rather than only having a single memory point per turret. Things like the TI sight head are not always located next to the optical sights. And it might also provide an ability to see where the gunner is looking, from the commander's turret if the commander has a view mode that is able to reference the gunner's view mem point.

Looks nicely done mate. Good to see you still modelling stuff too

Can you say if we are getting a new _ADSHQ texture type (like _NO/_NOHQ/_NOVHQ) or is the tools compression algorithm just getting changed to produce _ADS with better fidelity?

I'm afraid not really, no :/ Only going from what I can see from the SFP Mod's BV-206 which looks like it has tracks working in this manner on a non-tank/tankX vehicle. From the config viewer it has car simulation rather than carX. But selectionXXXOffset defined further up http://i.imgur.com/LLrK45Q.jpg No idea what else might be involved like having it defined in sections[] array of the model.cfg or anything else. I'd guess granQ would be the one to ask how the model is actually doing this.

No idea mate. So far as I know it's part of the legacy vehicle simulation rather than a kind of animation source. Like the rotor static/blur switching for helicopters is selection+config based rather than model.cfg animation. But maybe there's other texture animation stuff like for the ocean surface and the weird shader on some of the VR units. Unrelated, but I think the track "simulation" works on 'Car' type vehicle now too, not just 'Tank' types like it did in the past. So we could do half-tracks and stuff with it now. I seem to remember the SFP mod's BV-206 is configured as a car and has moving tracks in Arma 3 at least.

Yeah, the tracks model doesn't really move at all apart from the suspension/damper deformation when driving over uneven terrain. IIRC the visual effect of track movement is actually the UV coordinates of the track selection, moving in UV space along the V axis. So that the texture and materials mapped to the faces translate across the surface of the model as the vehicle's engine rpm changes and vehicle moves. Default (Czech) selection names for the parts of the track that undergo this moving texture are PasOffsetL/PasOffsetP, but it is ultimately defined by the selectionLeftOffset= and selectionRightOffset= parameters in the config. Tracks are UV mapped across several UV tiles that have a tile-able track texture. So long as the start/end seam of the UVs line up with where the texture repeats, they should appear as a continuous belt and not split when the whole "texture animation" thing runs. Best way is to look at how they're UV mapped in those sample models.

The rifle in the picture represents the AK-74M3/MR Universal Upgrade Kit (modelled for RHS by PuFu) which has been issued to a some non-SF units since last year. Part of Russia's soldier modernisation program along with the newer AK-12 (which RHS haven't modelled yet) so should be fine for equipping Russian units in modern scenarios Some nice photos of the upgraded AK-74 in use here (along with a few AK-12s being tested): http://imgur.com/a/xuc0z The other new AK variants that Soul Assassin has made with Zenitco furniture, will fit SF and Recon scenarios very well though.

It's primarily for the new AKs with railed handguards. So that hands aren't clipping through lasers, lights etc. when holding the weapon without a vert-grip attached "additional zoom" in Arma is treated as the main 1x zoom. All BIS scopes are scaled relative to that (so a BIS 10x scope is 10x the "additional zoom" view one has with a red-dot). Removing the variable zoom on some red-dot and ironsight type sights means some optics will be overpowered in relation to what players without a scope can see. With RHS we have to use a slightly different (lower) base 1x value for a few of our scopes so that the reticles fit properly in the field of view and still have correct scale to objects in the game world. But there are optics where we have taken BIS' example to heart as much as possible..

This isn't how the Horus or any other mildot based reticle is supposed to work. Read this https://www.leupold.com/wp-content/uploads/2013/08/Horus-reticle-Man.pdf

They weren't supposed to be in the Arsenal to begin with, since they're not yet finished.

IIRC HKey was the propriety one that was mostly marketed in the US for civilian use and for the US Army's CSASS (however, they revealed a new Geissele MLOK handguard for CSASS this week at AUSA). The slots have the opposite orientation to Keymod (narrow end faces to the rear of the weapon - i.e. the direction of recoil) and the slot has a "snowman" or figure-8 kind of appearance where the round hole at the end of the slot is slightly wider in diameter than the straight part The previously posted G38 rail and other military rifle rails that HK Germany are pushing at the moment (such as the new rail for the SA80) appear to be the normal keymod orientation and pattern. But with a shorter slot length, presumably so there us more solid material between slots that might make them less prone to fatigue. Makes sense in Europe since Keymod has made some inroads to military use on Accuracy International AX rifles used by special forces in Belgium, Spain, UK and other places. As you say, I'm not sure who the propriety slot was supposed to appeal to, other than HK's shareholders (a bit like Apple removing the headphone jack on new iPhones). Guess one has to wait to see how the final configuration of G38 will be though. I don't think I've seen photos of them in the hands of BW yet. Potentially they want to see what the French want in terms of configuration with their HK416A5s before adopting more of them in Germany, given the EU's ambition for a single military structure and equipment commonality across member states.

The German military aren't going to continue their newfound love of poop brown weapons, and use the funky keymod rail seen on these G38-marked weapons? http://strategie-technik.blogspot.co.uk/2014/08/neu-im-katalog-g38-alias-hk416a5.html

https://community.bistudio.com/wiki/Arma_3_Analytics probably. Try turning it off with the info provided there

What size is the texture, in pixels? They must be in 2^n pixels such as 64, 128, 256, 512, 1024, 2048 etc. pixels. So all textures will have an exact 1:1, 2:1, 1:2, 4:1 etc. aspect ratio. If you use imageToPaa (the successor to texView for converting Arma 3 textures) it will refuse to convert the image, and show an error if you use a non-standard pixel size.

Warden had ready access to a completed high-poly model of the MRZR for baking normal maps etc. whereas a new LAV or Stryker need new high-poly models building from scratch before we can even begin to work on the game model. Having more than half the work done before we start, does indeed help to change how quickly something is integrated in to the mod. Feel free to spend a few weeks modelling a Stryker yourself if you still need more insight