da12thMonkey

32,000 vertex normals. How many polygons that translates to depends on the allocation of smooth/sharp edges (e.g. smoothing group boundaries and/or unwelded edges) Can be anywhere from 18,000 tris up to nearly 32,000 depending on the mesh really

T129? Neat!

No, I think he's on about his previously announced M1117 project https://forums.bistudio.com/topic/183098-m1117-guardian-asv-wip/ It's a security vehicle and has a Mk19 in the Cadillac-Gage turret so fits the description

Mk19s have never been used by regular British forces. SAS etc. used to have them, but the only GMG used by regular forces has been the Heckler Koch L134A1 Mastiff and Ridgback are capable of mounting the L134A1 GMG since their weapon station uses the common ISTEC Universal Gun Mount that's on other vehicles like Jackal and RWMIK. But the main armaments on Troop Carriers are more commonly L7A2 GPMG or L111A1 HMG Small-ish pic of a Mastiff 2 with a GMG fitted And Ridgback with one

That's not the same problem he described: He's saying the switching between attachments isn't working. You're saying the attachment switching works but then the attachments fail to function because the laser/light wont turn on like normal. Is there a specific attachment item that you're using that you don't think is functioning as it should be? I just conducted some tests running CBA+MRT+ACE3+SMA and was able to pick a rifle, attach the SMA Vortex 3x or Eotech+Magnifier (which use MRT to switch optics mode with [Ctrl+NUM/] / [shift+NUM/]) then attach the Green/IR or Red/IR laser from ACE3 (which uses ACE's attachment switching system to go between visible and IR laser modes when [Ctrl+L] is pressed) then attach my own Laser/Light addon (which uses MRT to change between the IR laser and light modes when [Ctrl+L] / [shift+L] is pressed). In my play-through I was able to switch between all combinations of modes on these attachments and the various laser/light modes would activate whenever I pressed the game's default [L] key (as bound under \Configure\Controls\Common\Headlights on/off). I was running Arma 3 v1.54.133596 (stable), CBA v2.2.0.151130, MRT v1.2, ACE3 v3.4.0.0 and SMA v2.1.1.1 (v2.1 hotfix) and as I said it all worked well together so far as I could tell on the attachments I used, which I know to be set up for MRT or ACE3 item switching specifically. I'm wondering if there's something that's different in your setup? It's perplexing that you say it's the game's default on/off function that isn't working since this addon has absolutely no functionality that is related to the turning off/on of attachments. The addon simply registers a kebind with CBA that switches attachments with remove__WeaponItem then add__WeaponItem, then exits until you press the keybind again. You say that the switching function works when you press the MRT keybinds, and that literally is everything that this addon is capable of doing, so I can't think what there is in this addon that is being conflicted or otherwise interrupted because it appears our script is running to completion for you. At any rate, the whole keystroke detection and handling funtionality of this addon is done via CBA - it's not something anyone at MRT made. In fact it's the very same keybinding framework that ACE3 uses, since that too depends on CBA. If there is some issue of incompatibility with CBA keybinds shared by two different addons or something (though like I said, they appear to work fine for me), I would think it would be something that proved to be an issue for the CBA team rather than something we can do at our end. Ed:- Sorry I missed commy say that it was an ACE issue while I was writing this post. Like I said though, I didn't experience the problem when I was just testing various attachments that use our respective scripts in ACE 3.4 - guess it's because I didn't have binocs on me. Glad it can be resolved! :)

For models that are likely to appear several times in the scene (things like weapons and attachments) I personally go far enough down with the halving that the face count of the bottom LOD is as close to 100 faces as I can get it (ideally below). Often I end up with around 6 or 7 res LODs But as x3kj said depending on the starting polycount; 5 or more res LODs going down to around 300-ish faces (mixed quads and tris) seems to be normal for a lot of the assets in the game. I also recommend making your shadowVolume LODs very well optimised - as low-poly as you can go while still following the general outline of your high-poly LOD. Generally you can afford to get rid of most concave surface details (holes etc.) from the shadow and keep the bits that stick out, since only a silhouette is projected on to other surfaces. Have a look at some of the Arma 2 sample models and see how their shadows look.

Wait, so the article is suggesting that hit detection of the vest is based on named selections in the visual/res LODs of the vest model. Those selections aren't just there because they're needed for weighing the vest to the character skeleton? I know the selection names in the vest match the names in the character model's hit-points LOD and the class hitpoints config, but they also match the selection names/bones in the character's visual LODs and model.cfg in order that the whole character and vest/helmet/rucksack animate in the same way via .rtm. Why does the underlying character model need a hit-points LOD if the game can reference the visual LOD for hit information? solzenicyn's previous explanation suggested it wasn't a model-based solution, and was instead only defining (via config) the vest's protection of multiple hitpoints within the base soldier (the new class HitpointsProtectionInfo). I.e. how much damage actually gets transfered to the unit when a shot intesects the expanded number of hit-zones in the character model's hit-points LOD.

The resolution LODs do not transition at set ranges any more - they haven't done so since OFP. The distance that the LODs start to transition depends on various graphics settings of the client, and current game performance. That's why each res LOD is designed so that it has roughly half the number of faces of the previous LOD. Texture resolution changes completely independent to the model resolution (the process is called mip-mapping). If the game is using a lot of VRAM to store many high-res texture you will occasionally see the game swap textures on certain models to low-res mip-maps or the original texture, while still displaying the highest poly resolution LOD. Unfortunately, mip-mapping even occurs in the view Pilot LOD, which is typically the most detailed model and the closest to the player. Lots of mip-mapping in the scene becomes particularly apparent if you use 4k textures and materials because they use a lot of memory (BIS generally use textures no higher than 2k resolution) Anybody who says making resolution LODs isn't beneficial it is a fucking idiot - don't listen to them. You'll only make the game's performance worse for players if you don't make them, and your model hogging performance will drive other models in the scene to start displaying low-res textures and dropping to their lower LODs so there is no net benefit if players are only seeing your model in high res when everything else looks worse.

Our parliament has voted in favour of extending RAF air-strikes to include targets in Syria (397 in favour 223 against)

The Germans have only allowed themselves to provide recce with their Tornadoes anyway (same as they did in Afghanistan). Even more of the Luftwaffe Tonkas were airworthy it probably wouldn't significantly contribute to what that France and the UK want from their partners in action against ISIL. Even the UK is still waiting on parliamentary approval to do more in Syria than provide recce (our Tornados, Reapers etc. are currently only cleared to strike targets inside Iraqi borders). Availability of aircraft is no substitute for a lack of political will to use them. The British vote on extending strikes to Syria istomorrow (It's being debated in Parliament all day today for some 10 hours) but it's already been stated by our PM that the RAPTOR pod on the RAF's Tornado fleet accounts for 60% of all our surveillance intel against ISIL in the region. But even beyond that, the UK has been increasingly keen to be less reliant on aging Tornadoes by finally giving the Typhoon a more complete strike capability (keeping our Tornadoes airworthy is also an uphill battle, same as it is for the Germans and Italians) but other European partners have been reluctant to place that investment in upgrading the Typhoon's capabilities. Again, willingness to invest in such capabilities would be something that would be reflected in whether an EU armed forces was a "decent" armed forces as you put it, and how effective they'd be in a conflict like Syria rather than continuing to have member states operate independently. Overall I have seen nothing from our EU partners that makes me believe we would ever have a situation where they are doing more together about ISIL than France and the UK do currently by themselves. I don't think an EU armed forces directly beholden to the EU parliament would be any more decisive in getting involved with Syria than the German national parliament is, since Germany would be the major actor in a EU parliamentary decision on it. We'd still have a situation where one major actor in the EU (France) is fully committed and willing to invest in armed forces, where others are not, and simply want to play safe and pass the burden to the members that are willing to act alone.

The changes I was on about there are only if the mod contains custom unit models, so probably only affects a handful of addons. Vest, helmet, rucksacks etc. - other wearable models; don't include their own hitpoints LOD so should only have issue with the config changes. Retextured BIS unit models (which form the majority of unit addons) will contain the new hitpoint selections unless someone retextured them by extracting the .p3ds from the game data and hex-editing them instead of using hiddenSelections. The model.cfg hasn't been changed to my knowledge; only a few extra named selections in one LOD. But swapping the .p3d files for a new one would be something where you'd need the unbinarised MLOD source file for the unit model, and to repack the .pbo. BIS released the updated source files that contained these hitpoints LOD changes when they were announced on the dev Branch months ago.

"Firing From Vehicles" is written in the changelog instead of "FFV", in a manner that relates it to all the other "FFV" changes listed elsewhere in the changelog: Admitedly it's near the bottom of the list of changes relating to FFV, but AFAIK (As Far As I Know ;)) the changelogs are kind of written in reverse order, as accumulated from the Dev Branch changelog with older changes being further back.

It's the same amount of work if one was actually bothered about making custom animations for GL ammo in the first place - it's just a matter of reconfiguring the animation from the ammunition/magazine config, to the GL muzzle. Most people didn't bother with attempting custom GL animations previously since they mostly used the game's default 40mm ammo for the sake of magazine compatibility - so most custom weapons utilised the game's default GL reload anims because they came with the magazines. The new system is overall much better for those that want custom GL animations but it doesn't make creating the .rtm reload animation files for the character any less difficult than it has always been. There's a reason that not many community weapon addons come with proper reload anims - it's a very separate skill to texturing, modelling etc.

It's a new feature. The animation source for animating the GL on the weapon itself was added a few patches ago, but the config changes for the unit to perform weapon-specific GL reloading animations came in the recent patch. Prior to that the reload anims were specific to the magazine so you had to make custom magazines with unique animations to fit your weapon geometry if you wanted to make use of the new animation source for the weapon. In RHS' case it probably also requires adding any of the newly named hitpoints to a character model's LOD (since they have custom character models rather than just retextured BIS units using hiddenSelectionsTextures). Otherwise the points named in the vest/uniform config don't necessarily exist in the base character model they're protecting. BIS updated the sample character model (A3_Character_Example.p3d) to include the new hitpoints selections. So it's a matter of deleting the old points from the LOD and copy+pasting the updated LOD from the sample model.

It's stated in Steam's EULA that uploading content that you don't own is against the terms of the Workshop Licence. Legally, content is only allowed to be on there if the author uploads it themselves.

Yes, the AAAV/EFV was cancelled back in 2012.

That would be the other important convention for formatting textures: Textures must have dimensions that are of the order 2n. So 32, 64, 128, 256, 512, 1024, 2048 etc. etc. Checking the dimensions of the pic you posted, your texture somehow ended up being 1026 pixels vertically instead of 1024, so has an invalid texture ratio. 2048*1024 (the original dimensions of the texture) should work fine.

Diffuse/albedo texture names should all end with _co.tga (or _ca.tga if they contain an alpha channel). The tools use that information to format the texture when it converts to .paa - if you don't name things properly it can cause rendering problems like this..

Thank you for pointing this out. It will be fixed in Dev-Branch soonâ„¢. Chance you can fix the holes in the MK200 ironsights mesh while you're tweaking the model for the reload anims? http://feedback.arma3.com/view.php?id=23292 I'm pretty sure the faces that should cover those holes are just missing from the animated selections after splitting from the ironsight topology or something, but they are still in the model. Redefining the selections should only take a few minutes right?

Judging by the size of the red axis in your Object Builder viewport grid relative to the size of your model, your structure appears to be large (possibly bigger than the 20*20m grid area). Could just be that the camera is clipping through the structure and looking through the backfaces if you don't have any interior geometry. I just tested by making a 30*30*30m cube in OB and trying to view it in buldozer - I couldn't see shit either. Try pressing the [Enter] key on your num pad in Buldozer to set the view position further back and use the WASD controls to move further back still if needed

You mean an IRST (Infra Red Search and Track) or EOTS (Electro-Optical Targeting System)? No, the Raptor doesn't have one currently. The PNVGs were developed for pilots before they were adapted for ground use by special forces units (the G in GPNVG-18 denotes they're that they're adapted for Ground use). The original AN/AVS-10 PNVG are black and less rugged than the GPNVG The USAF started issuing PNVGs in 2005 but they'd been in development since the late-1990s.

Hah, yeah I was just about to post that I updated the set of reskins I did for Firewill's F-16 to reflect config changes he has made in the months since. Basically I've updated the config to the updated standard loadout, with a Master Arm switch enabled and added some of the stuff that Firewill included in the updated texture template such as the dirt overlays. I've also added a couple of additional details to the textures such as No Step/Walkway lines on the upper surface and the engine warning line on the underside. Displaynames for the Dutch, Belgian, Danish and Norwegian skins have been changed to F-16AM instead of F-16C. New additions are F-16C Block 50/52 and Block 50+/52+ in Greek and Turkish schemes (different squadron markings between those with/without CFTs) and a Portuguese F-16AM. There's also a mod.cpp logo to help find the skins I did, in the editor. DOWNLOAD V.1.1 @ Dropbox ED:- One of the .pbos was the wrong version so I had to update the archive again. PWS has logged this hotfixed version as V.1.1.0.1 http://imgur.com/a/MyKge

Multiple shootings and explosions in Paris tonight. Thought to be suicide bombs near Stade de France and shootings in restaurants. Earlier reports said at least 20 dead, but some outlets are now reporting more than 40 Ongoing hostage situation at the Bataclan theatre - up to a hundred people are thought to be inside http://www.bbc.co.uk/news/world-europe-34814203 Explosion near Stade de France was audible on the TV coverage of the France-Germany match https://twitter.com/ArsenalTerje/status/665285613961244673

https://community.bistudio.com/wiki/BIS_fnc_customGPS According to that page you pass the texture path to the function with an array. "_this select 0" is saying the the image path needs to be the 0th (first) index in the array so you'd call the function with. ["PathToTexture"] call BIS_fnc_customGPS; Or if you need to use the other optional parameters to include a "Delta Y" or "Delta X" value (not sure exactly what it means by the delta values - I think it's some positional offset) you'd call it with ["PathToTexture",ΔX,ΔY] call BIS_fnc_customGPS;Where ΔX and ΔY are numbers.

Is that image the texture you're trying to use? For a start, texture files have dimensions that are in the order of 2n (2*2*2*2*2*2*.....) so they must be something like 256, 512, 1024, 2048 etc. pixels in height/width You can't have 900*900 images like the one you posted.