da12thMonkey

Does adding an autocenter = 0 property in the model's geometry LOD prevent it?

Since he asked about fighters and bombers I think he means how expansive the VVS (air force) content will be in RHS, not about the VSS rifle

You can only do a clean install after first upgrading a current Win7/Win8 installation though. You can't just download the ISO and install straight to a new drive. In order to allow me to install Windows 10 on the new SSD I got, without losing my Windows 7 installation on the current HDD: I've had to install Win 7 on my new SSD using the existing OEM key and activate it (which I'm able to do on this new drive since it's still the same motherboard as registered to the OEM key from the HDD installation) then wait through the tedium of downloading, installing and restarting for all the various Windows updates until I get the one that begs to reserve Win10 again on the new drive. Now I should be able to install Win10 to the new drive without risking anything on my large capacity HDD getting lost in upgrading or potentially having to format and roll back to Win7 on a drive that has all my stuff, if I didn't like Win10. Fortunately the two concurrent Win7 installations don't appear to be interfering with each-other at all but it may be since I have to switch BIOS to AHCI for it to attempt to boot the Win7 installation on the SSD, and switch back to IDE to boot the one on the HDD.

You can already set the reload gestures per magazine by including a reloadAction parameter in the magazine class. This is how we have separate reload gestures for the game's UGLs. The problem is that the reload gesture for that magazine is then the same regardless of the weapon - which is rather useless for magazine commonality between weapons. And as you say, it also doesn't solve any issues with how those different magazine reload gestures might sync with the reloadMagazine source animation in the model.cfg for the weapon.

Don't know if this belongs in the Scripting Discussion thread or the more general Dev Branch one, but here goes. Is there a particular reason why (backpackContainer player) setObjectTexture [0, "#PATH"]; will work, and allow you to change the textures/materials of a unit's backpack on the fly, but (vestContainer player) setObjectTexture [0, "#PATH"]; doesn't work? As far as I can tell the backpackContainer and vestContainer commands return virtually the same information about their respective containers (with an ID and model name) and both containers appear to be functionally the same in almost every other respect other than they occupy different inventory slots: So I'm wondering why one is able to target an item worn by a player and apply setObjectTexture to it, and the other isn't? Certainly in terms of modelling, animation and config there is very little difference between how a vest and a backpack are set up in themselves, or how they appear on the character model via proxy: So perhaps there something fundamentally different about the way vests are simulated in the engine compared to backpacks that means setObjectTexture wont work on them, and I'm mistaken in thinking it's to do with the xyzContainer commands I'm aware that some BIS vests classes aren't set up for hiddenSelections even if the models are (so obviously setObjectTexture wouldn't work on those) but the command doesn't work on the vests classes that are set up for it either. In fact I've tried the above script on Teriyaki's addon which has a version of the BIS Rangemaster belt set up as a backpack and it works on the backpack-configured belt, but not the retextured vest-configured belt even though they're using the same model and hiddenSelections sets. It'd be kind of useful if we could setObjectTexture/setObjectMaterial vests the same way as we can do with backpacks, since they seem so similar. Headgear, and maybe weapons too; but there aren't equivalent xyzContainer commands for those items, so I have no expectation of being able to target them to execute the setObjectTexture command like we can do with a backpack.

They're not. You're just using the wrong naked eye "zoom" as the baseline 1x value now that BIS has changed it to be consistent across all optics on the dev branch. All optics zooms on weapon scopes and vehicles are now relative to the narrow naked eye FOV (which is the game's true 1x "zoom", but appears as 1.8x zoom in your video). The game's default init FOV (appears as 0.9x zoom in your video) is now about 1/3 of the baseline naked eye value used to calculate optical magnification; so the scope that is nominally 5x the narrow FOV is ~15x the default FOV, as you've discovered. The default view is not considered as 1x magnification because the resolution is nowhere near as good as real-life 20/20 visual acuity, but as discussed before the "zoomed in" naked eye is pretty close on a display with 1200px vertical resolution. Prior to this, BIS were inconsistent in what the 1x value was in calculating their vehicle and weapon optics, and the Mortars used one that was relative to the default FOV.

All of the scope magnification values for vehicles and weapon sights alike are now based on the new naked eye FOV value when "zoomed in" (e.g. a 10x scope is 10x the "zoomed in" naked eye), so I don't feel it's too much compared to other optics in the game. And I think it's fine in terms of visual acuity for 1x eyesight.

The mod's been around for 12 years. How many times do you think somebody has asked them "when will X be finished?" in all that time? Do you think after answering the same question every few days/weeks, year after year, you'd still give a shit about being friendly?

Pixel to texel ratio will depend on the user's monitor/graphics resolution settings, so it's kind of pointless trying to get it exact when it'll only display like that for you anyway. As long as it doesn't cover more than 95% of the screen's vertical length even a 1024px*1024px reticle texture won't be stretching to fit a standard 1080 HD monitor, which AFAIK is still the most common screen resolution. It'll only look a bit naff to people with >HD or UHD screens. A problem you do get using high-res reticle textures though is that unless you have a lot of memory, the game likes to mipmap 4k textures and sometimes the 2k ones as well in order to show other textures in the scene at better resolution - which does usually result in a blurry reticle. Ticket about BIS' blurry, mipmapped reticles here : http://feedback.arma3.com/view.php?id=23655 As such, I only ever use a reticle plane with a 2048 or greater texture when the the reticle plane covers more than 50% of the scope aperture, or use polygon geometry with a black procedural texture #(argb,8,8,3)color(0,0,0,1.0,co) to actually model the parts of the reticle that I worry about suffering due to stretching to fit screen res. 1024 is more efficient if you're not filling the screen with your reticle. For example: Ingame, playing with 1440*900 resolution (native to my monitor) they both look pretty sharp both at 6x and 12x; without texel-stretching since the screen space covered by the texture is lower than the texel resolution, and mipmapping is very rare since at 1024*1024 the textures are comparatively small in filesize and don't hog much VRAM. Once upon a time I did make the whole reticle using 2D polygon geometry. However, I found that the reticles, particularly at low magnifications (i.e. when the reticle is small); suffered from a lot of aliasing on the mil-dots (because they're curved) and the stadia lines weren't as visible.

The zeroing for the turret is configured by the values entered in the discreteDistance[] array or distanceZoomMin distanceZoomMax config parameters for your turret. Whether the turret uses discreteDistance or distanceZoom for to control the zeroing depends on turretInfoType, so you'll have to check. discreteDistance weapons/turrets are the ones that have Page-up/Page-down zeroing so the array contains all the ranges you allow the player to zero the weapon to. distanceZoom weapons/turrets are the ones with outdated OFP/Arma 1 style of zeroing - the weapon's zero is the distanceZoomMin value when the optics are at their lowest magnification value and distanceZoomMin at max zoom. If you want to fix the zero at 550 just enter a value of 550 in those parts of the config. If your turret has a discreteDistance array, you might also need to look at the discreteDistanceInitIndex parameter. Basically this is a value that tells the game, which index in the discreteDistance array to use for the player's default zero. discreteDistanceInitIndex = 0 is the first value in the array, discreteDistanceInitIndex = 1 is the second value, etc. etc. So if your discreteDistance array only has a value of 550 in it, you should set discreteDistanceInitIndex = 0, since there is only one index in the array.

Arma's ballistics modelling isn't 100% realistic so using the real reticle is unlikely to fit the whole trajectory without at least some tweaking. I'd conclude that it's probably better to get the ballistics right as right as possible (or just trust the values you got from Arma 2), then make a reticle to match. You might find the reticle you're trying to replace the A2 reticle with doesn't match well because the magnification value for the optics is a bit off compared to the real thing upon which the picture is based, or the weapon's zero doesn't correspond to the stadia line that lies exactly across the middle of your optics. Looking at the reticle you posted there, the weapon should have a default zero somewhere between 500 and 600m since the mid-point of the vertical axis of the texture lies between these two range stadia lines.

https://en.wikipedia.org/wiki/AR-10 (Pikula, Sam (Major), The ArmaLite AR-10, p. 36, 38) I'd assume the one being fired is a very early one from before the charging handle was disconnected from the bolt. It has an early Sudanese/Dutch Test model handguard rather than the later handguard depicted on the rifle in your addon http://www.ar10.nl/all_model_overview.html Ed: - I guess the model you have is a Portuguese one, since it has the straight-backed charging handle and top-mounted bayonet lug. These weren't produced until 1960, so wouldn't have a reciprocating handle.

You can work it out looking at this chart: http://www.bistudio.com/assets/img/licenses/images/license_chart.jpg If the mod itself is released with APL or APL-SA then you're supposed to be permitted to modify it. But only the APL-SA license automatically carries over from the BIS source data: i.e. If the mod is sourced from BIS's APL-SA data you're permitted to modify the parts of it that are sourced from that APL-SA data. If it's derived from BIS's APL data but not released under an APL license itself, then you should to talk to the author. By convention, items released without a licence are treated as intellectual property with all rights reserved by the author so one cannot assume that they optioned to extend the APL waiver from BIS.

Can place one of your vertex axis points, lock movement to the Y axis in the viewport (press the [Y] key or the green Y button in the toolbar) and copy and paste your memory point before moving it down in your selected viewport. Press [Y] again to bring back X/Y movement in the viewport or click the corresponding button in the toolbar. Can also 0 scale the points in the X and/or Z axis to align them along Y. Select the verts, press [Shift+C] to activate the pin at the centre of your current selection (should look like a cross with a small circle in it) then use the Scale Points tool (the 3rd Yellow cube-looking button along the toolbar) with values of 0 in the X and/or Z input boxes while leaving a value of 1 in the Y axis box. You can snap the pin to vertexes in your window model by pressing [C] (or [Shift+C] if the pin isn't previously activated) while the vert you want to align to is selected, and again use 0 scaling values to align memory points to these pinned points in a specific axis.

I know. What I'm saying is that beheading is part and parcel of the current terror threat facing Europe, and is no more unusual a tactic for the Islamic extremists here, than it has been in the Middle East. Suicide bombings, mass shootings etc. are also a lot less common here than they are in the ME, but the level of security in Europe is much greater over all; and ultimately that's what's prevented a number of beheadings in the past.

Not really. Over here in the UK there was intelligence about plots by Islamic extremists to behead people since ~2003/2004 inspired by the typical methods of execution by AQ-affiliated groups in Iraq and Afghanistan. 5 people were convicted for such a plot in 2007 In 2013, a British soldier called Lee Rigby was run over by a car and beheaded on a street in London. Since then a another extremist was arrested for preparing an attack inspired by the killing of Lee Rigby - he was carrying a knife and jihadist flag when he was arrested. And just yesterday a White Supremacist was convicted for stabbing a man he thought was a muslim (he was actually Sikh) with the intent of beheading him, as an act of revenge for Lee Rigby's death. The threat of it has become fairly synonymous with Islamic extremism here

Yeah, I think it started doing that for me 2 or 3 dev builds ago.

Probably because there's more MOPP gear than just the mask. As soon as there's a credible CBRN threat in theatre, people are expected to carry the whole set of hood, mask, rubber gloves, and boots and wear an oversuit all the time. So the mask is pretty unrealistic without at least the oversuit. The only circumstances where just the respirator is carried without the rest of the gear is when there the enemy has CBRN capability, but it's determined that CBRN is unlikely to be used (MOPP level 0), i.e. the mask is carried on the basis that it's probably not going to be used. Or when conducting riot control operations and employing tear gas, pepper-spray etc. But since Cunico is already making tons of stuff for RHS I'm sure they'd know to ask if they fancied adding his M40/M50 masks to the mod ;)

Nice update. The cleaner optics views and shaders are really good. I noticed the low-mounted Aimpoint Micro doesn't have the reduced "tunnel effect" of the updated high-mounted version. Is that a limitation of the model geometry (like the VCOG) or just an oversight? Also, in a yesterday's SITREP it was mentioned that BIS have adjusted the naked eye FOV/magnification values so that they're standardised across the whole game. On the dev Branch they've changed the collimator naked eye FOV values to: opticsZoomMin = 0.25; opticsZoomMax = 1.125; opticsZoomInit = 0.75; And quoted magnification values for all scopes are based on that value of opticsZoomMin = 0.25, so things like the RCO (which is described as a 2x scope now) has opticsZoom values = 0.125 (0.25/2). Thought I'd mention it in case you want to make the collimator etc. consistent with BIS' optics following the next patch.

Since it's set up to use the Vehicle Customisation options used for the Virtual Garage, you can set the vehicle to Olive using: [this,["Olive",1],Nil] call BIS_fnc_initVehicle; Other examples for initialising/randomising VhC are detailed in the thread linked above.

1) The optic proxy position and rail dimensions on BIS weapons are often inconsistent anyway, so you'll probably find it clips or floats a bit on one or two weapons. That said, if you align the upper surface of the picatinny rail cutout with the Y = 0 line in Object Builder then move the whole sight upwards by 0.007, it sits on the MX rail pretty damn well. The optic position on most weapons does seem to be correctly justified in the centre of the weapon's rail though, so if you align the middle of the rail cutout with the X/Y plane (i.e. the middle of the cutout is at Z=0) it should sit in the middle of the rail. 2) Easiest way to do it is to make your optic compatible with ASDG Joint Rails. Pretty much every community-made weapon and attachment addon uses this to ensure attachment compatibility with all of BIS' weapons and community-made ones. 3)Model.cfg is used to program animations on weapon, vehicle and building models. You set up a bunch of axes in your model's memory LOD using named pairs of vertexes and animate the named selections in your mesh by programming them to translate along, or rotate around those axes. The trigger for these animations is defined by the "source" controller - there's a list of animation sources on the BIS wiki I wrote some tuts on programming simple model.cfg animations: http://www.rkslstudios.info/public-forum/33/180 http://forums.bistudio.com/showthread.php?171511-Animate-Bipod-Model-cfg-Help&p=2599648&viewfull=1#post2599648 Animating hand positions, magazine-change animations etc. is a bit more complicated since it's a character animation. There are some basic handanim tutorials around on the forum for getting units to hold your weapon correctly though. http://forums.bistudio.com/showthread.php?139652-Tutorial-Creating-Custom-Weapon-Animations (read the thread all the way through since there's some discussion of other methods and problems)

The Russian company SPOSN/SSO who make Gorka suits and other popular private purchase equipment for Russian forces, make a copy of the Eagle A-III called "Adler" (Трехдневный/Ðдлер): http://sso-mil.com/catalog/109/4679 There are a couple of other packs already in Arma 3 that are based on SPOSN/SSO products as well Field Pack = "Gorod": http://sso-mil.com/catalog/109/167 CarryAll = "Tortila": http://sso-mil.com/catalog/109/151

Can't really be done simply in an addon since the apparent width and brightness of the reticle is determined by a texture and material files inside the optics model. You can't change these particular textures in the model the fly, so it involves modelling multiple versions of the same attachment and scripting so that you can swap between the models. We made a small addon that allows changing between models and has been used by some addon makers to recreate optics with multiple, selectable reticle designs/colours: http://forums.bistudio.com/showthread.php?181338-MRT-Accessory-Functions And as such it could be done for brightness using that method, but it's somewhat impractical to create dozens and dozens of alternate models This isn't really practical since the co-witness is dependant on the height of the optics mount compared to the height of the BUIS over the rail. An optics model with a cowitness that works on one weapon may not have the same co-witness on another weapon because the irons are a different height, so one would have to create multiple optics models with mounts of differing heights. The only way to ensure it works would be to design both the optics attachment and weapon models together, with co-witnessing in mind. For example, I made a RMR model that I designed to have a co-witness with the BIS 4-Five pistol, but if I mount it on another weapon such as the Glock 17 from CUP, it's no longer co-witnessed because of the height of the irons on the Glock being much lower and the mounting point for the optic being cut higher into the frame. Rather unintentionally, the rail-mounted version of the RMR that I made, lollypops quite nicely with the Navid's front sight post. However, as you can see the same is not true when fitted to other weapons with sight posts of a different height, like the Mk1 EMR (the dot is now at the bottom of the front sight post) With these two weapons, the rear sights automatically fold down when optics are attached ingame so one can't really determine what the co-witness with the rear sights is like. ACE 3 adds the ability to set up scopes with click turret adjustment for windage and elevation. There are a couple of optional files included in the mod to add such sight adjustment to community scope addons when running them with ACE. http://forums.bistudio.com/showthread.php?190433-ACE3-A-collaborative-merger-between-AGM-CSE-and-ACE Suppressors in the game already increase muzzle velocity by ~5% to provide an analogue to free bore boost. The game's default 100m increment zeroing system doesn't account for this change in muzzle velocity so there is usually an apparent vertical POI shift compared to the unsuppressed weapon, which is the result of the increased muzzle velocity no longer having the same ballistic trajectory.

:eek: Nice work BIS!

As a player I prefer the ACE method - I feel image clarity through the optics is king when it comes to a scope being usable In terms of doing it as an addonmaker though; drawing good 2D images to use for the ACE method can be pretty work intensive compared to the RHS method where you simply adapt the 3D model you already have. But I suppose it depends on one's skill as a 2D artist. Personally I tried making one by rendering my model in Marmoset (or another program with decent PBR will probably do) and using the FOV and DOF sliders to get it looking nice. It was much faster than drawing it all by hand in PS or Illustrator or something, however because it's based on a polygon model it's probably not as smooth as it could be: