They changed the way the launch system works. It now does it all automatically with a single action now rather than two actions

This issue made its way in to the 1.54 stable patch so have updated the relevant version fields in the ticket

Aye, I just re-checked myself with the VR 1m Cube obstacle instead of the User Texture object (never thought to use that one before, but it's probably easier since you don't need to setobjecttexture to make the cube visible).

You're right: the objects observed through most BIS sniper scopes seem to be about 1/8th bigger than the size they should be (1.125 scale), so the 1m cube spans 4.5 mils @ 250m instead of 4.0 mils, 2.25 mils @ 500m instead of 2.0 mils, 1.125 mils @ 1000m instead of 1.0 mils, etc. etc.

I was certain that the LRPS and MOS had properly scaled reticles recently, but I think BIS has tweaked the FOV/magnification values slightly since then, to standardise magnification values between scopes prior to releasing Marksmen.

BIS could solve it by scaling the affected reticle textures by a factor of 9/8 (1.125) or increasing the FOV by the same factor, in the config for those afflicted scopes.

Thankfully my own scopes are still perfectly scaled :D

Unit is 1.83m tall in the standard T-pose (legs slightly apart) without a helmet. Height will differ slightly depending on animation and headgear.

If you want to check the mil-spacing properly, use the 1m x 1m User Texture object in the editor. I've always found that the BIS scopes are well calibrated to this object, as are some community addons like RHS's Leupold scopes, and I use it myself to calibrate mildots on my own scope reticles.

Use this setObjectTexture [0,"#(rgb,8,8,3)color(1,0,0,1)"]; in the initline to make it a perfect 1m x 1m red square that you can see. You can set the range from your player using getpos/setpos to set precise values from the point where you're standing. IIRC the Rangefinder only works to the nearest meter, so you can get some discrepancies in terms of cm scale accuracy.

Disadvantages of silencers ingame are that they add weight and inertia to the weapon, which has an effect on fatigue weapon handling.

The increased muzzle velocity also changes the ballistics in a way that the Page Up/Page Down zeroing no longer matches the ballistic arc programmed for that weapon, so all bullets will hit slightly above the crosshair even if you zero the sight to the range that the target is at. This means you have to hold the crosshair of the scope lower down than normal and makes shooting at long ranges more difficult than before, unless you're very well practised.

As I mentioned in the forum thread discussing this issue (http://forums.bistudio.com/showthread.php?190685-Blurry-2D-Reticles):

Even when textures are set to Very High, the game has a tendency to mipmap the 2D reticle textures along with other items in first person view; favouring the allocation of high-res textures to newly rendered environment objects instead.

Once mipmapped to low-res, these reticles and first-person objects tend to stay low-res for the rest of the session, rather transitioning back to high-res in the way that environmental objects transition between mipmaps depedning on how close the player is stood to them.

It would be good if reticles and first person objects had greater priority when allocating the high-res mip-map stages from those textures currently held in memory.

Depends on the bullet used. Modern "insensitive munitions" are quite resistant to shrapnel etc. So small-to-medium calibre rounds might struggle to set off explosives packed inside something if they fragment or lose significant energy before they impact the explosive component.

Obviously, large-calibre rounds or smaller rounds fired directly at explosives would almost certainly still manage to set off even an IM charge.

The US and UK militaries have already largely replaces TNT with equivalent Insensitive Munitions such as IMX-101 (using NTO & RDX compounds) because they're much safer to transport and are unlikely to explode in the event of fire or shock.

Related tickets, i.e. directly caused by weapon initspeeds not matching magazine initspeeds:

http://feedback.arma3.com/view.php?id=23119
http://feedback.arma3.com/view.php?id=22407
http://feedback.arma3.com/view.php?id=23231

It was also mentioned on the forums as soon as soon as the weapon-based initspeed feature was implemented, since people had noticed the same thing happening for a long time with muzzle attachments that modify initspeed using class MagazineCoef. It was obvious that zeroing calculations were purely based on the magazine value and not the actual speed at the muzzle.

For reference, should BIS choose to make an MTP version of the NATO helmets. Revision do produce fabric helmet covers for their Batlskin helmets (upon which the Arma 3 NATO ECH is based):

Basic version (shown in UCP rather than multicam/MTP):
http://www.revisionmilitary.com/store/media/catalog/product/cache/1/image/9df78eab33525d08d6e5fb8d27136e95/b/a/basic_full_cut.jpg
http://www.revisionmilitary.com/store/media/catalog/product/cache/1/image/9df78eab33525d08d6e5fb8d27136e95/v/i/viper_helmetcover.jpg
http://www.revisionmilitary.com/store/media/catalog/product/cache/1/image/9df78eab33525d08d6e5fb8d27136e95/v/i/viper_helmetcover_elastictrim_closeup.jpg

Enhanced version (this style is used by the Danish and British militaries on their new Revision "Cobra" helmets):
http://www.revisionmilitary.com/store/media/catalog/product/cache/1/image/9df78eab33525d08d6e5fb8d27136e95/c/o/cobra_fullcut_enhanced_multicam_profile_720x613_72_rgb.jpg
http://www.revisionmilitary.com/store/media/catalog/product/cache/1/image/9df78eab33525d08d6e5fb8d27136e95/c/o/cobra_fullcut_enhanced_multicam_helmetcover_top_720x612_72_rgb.jpg

Premium version (mesh fabric):
http://www.revisionmilitary.com/store/media/catalog/product/cache/1/image/9df78eab33525d08d6e5fb8d27136e95/m/o/modernization_kit_-_essential_kit_final.jpg
http://www.revisionmilitary.com/store/media/catalog/product/cache/1/image/9df78eab33525d08d6e5fb8d27136e95/v/i/viper_premium_helmet_cover_-_above_-_web2_1.jpg
http://www.revisionmilitary.com/wp-content/uploads/2014/05/Viper-Premium-Helmet-Cover-Back-Web.jpg

The helicopter blades aren't motion blurred. It's a 2D texture on a polygon plane that replaces the 3D model of the rotor blades then the engine is turned on and goes above a certain rpm.

You can't blur 3D objects like the MG belts and ejected ammunition in the same way as rotor blades.

As I said on my ticket (http://feedback.arma3.com/view.php?id=23205) I think the problem is only that when the game restarts, it restarts by the Arma3.exe rather than the Arma3GU.exe.

As such, the bug will only be effecting those of us that run the dev branch as a a separate install using Game Updater and have to launch the game via Arma3GU.exe instead of the normal .exe - which is why Iceman can't reproduce it with his set-up (I guess)

It probably wont affect the game when the update hits stable branch, like it doesn't appear to affect people like Iceman who run only the dev Branch, via Steam's beta opt-in.

I'm currently running the dev Branch via an additional install, using the official Game Updater application:

https://community.bistudio.com/wiki/Game_Updater

So verifying integrity through Steam only resolves the Main Branch files, not the dev branch where I'm experiencing the error.

I've re-run the Update process via Game Updater, which validates the additional install outside of Steam.

I'm thinking maybe that's the problem; the restart doesn't initialise the .exe that's compliant Game Updater installations of the game. My apologies for overlooking that - I guess that could make it a separate issue entirely.

Can confirm this is happening on the current dev branch. It only appears to affect the hexcam patterned Lynx used by CSAT.

I think the model.cfg is corrupted or conflicting with something.

The NATO units wear multicam, it's just called MTP ingame because the name "Multicam" is copyrighted.

The ingame pattern itself isn't the same as real-life British MTP (the splotches are a different shape on real MTP), it just shares the name because "Multi Terrain Pattern" is a pretty generic name that describes the pattern well.

It's because the new weapon-based initspeed values aren't taken in to account in the zeroing calculations that the game does. The trajectory calculation used to resolve the muzzle elevation when adjusting the zero only uses the initspeed value from the magazine, not the final muzzle velocity of the weapon.

30Rnd_65x39_caseless_mag for the MX and the derivative magazines for the Katiba have:
initSpeed = 800;

The standard-length MX (arifle_MX_F) has:
initSpeed = 800;

The Katiba Carbine (arifle_Katiba_C_F) has:
initSpeed = 820;

These classes follow the zeroing calculations quite well because weapon-initspeed is the same as (or very close to) the 800m/s value used to resolve the zeroing calculation.

The Katiba Carbine POI might show a very small deviation from the POA at longer ranges because it's 20 m/s faster, but for shorter ranges the trajectory wont have deviated enough for you to noticeably miss the target.

As for the other weapons...

Long-barreled Katiba (arifle_Katiba_F) has:
initSpeed = 900;

MXM (arifle_MXM_F) has:
initSpeed = 920;

MXC (arifle_MXC_F) has:
initSpeed = 720;

These weapons have an initSpeed value that deviate greatly from the 800 m/s value used to calculate their trajectory for zeroing, therefore the POI shifts from the POA quite a lot.

You can see that the classes where weapon-initspeed > magazine-initspeed are the ones that shoot high, and the classes where weapon-initspeed < magazine-initspeed are the ones that shoot low.

Yea, the current function in the Arsenal on devBranch doesn't seem to be picking up the parameters from class compatibleItems. I.e. compatability defined in the format:

    class compatibleItems {
        MY_Optic1 = 1;
        MY_Optic2 = 1;
    };

The list remains empty for weapons that only have a slot with compatibility defined in this manner.

This is fixed on the SPMG and Navid, but the SIDE proxy (for fitting IR lasers, flashlights etc.) is still misplaced on the Cyrus.

The proxy just needs moving a couple of cm upwards.

Completely fixed in 1.43.129911

Can be marked as resolved and closed.

I guess this is still kind of a bug but now that there are keybinds actions for infantry weapon switching in Version 1.39.129457 and later, the problems associated with turning out with no weapon selectable for FFV are no longer really apparent.

If a player turns out and is unable to use FFV initially, simply drawing their primary weapon using the appropriate "Switch to Primary Weapon" action resolves it. To be honest it's fairly logical to have FFV turn-out positions operate in this manner, but still the behaviour is inconsistant (i.e. players still automatically get FFV when turned out if they initialise via moveincargo or manually get in to a vehicle)

The simple way to do what you're doing, without cutting and pasting the parts of the model back in to rearrange the alpha sorting order, is simply to select the glass section and click "\Faces\Move Top" or press [Ctrl+Shift+Home].

That will bump those faces to the top of the Alpha sort.

Can confirm that it seems to be fixed in today's dev Branch patch.

Thanks!

Indeed, there seem to be a lot of cases whey keystokes are registering as though the user is double-tapping them. I wrote on the forums about the effect I noticed with optics zoom/fov keys:
http://forums.bistudio.com/showthread.php?152866-General-Discussion-%28dev-branch%29&p=2853519&viewfull=1#post2853519

Since the 07-01-2015 dev branch patch included the change:

*Fixed: Key blocked by script is blocked even if held for a while

The games standard keyboard controls have sometimes been quite erratic

AFAIK hiddenselectionstexture doesn't work on weapon attachments anyway, even if they are set up with selections inside the model.
Same goes for most proxy items.

Works on the weapons themselves though.

We had a report of something to this effect happening with our rksla3.bikey file as well:

http://forums.bistudio.com/showthread.php?178555-RKSL-Attachments-Pack-1&p=2866462&viewfull=1#post2866462

Can't really work out what's causing it, or why it effects this key on their server (so far they're the only group who have mentioned this problem with our key).

Strictly speaking this is an issue for any insignia without x-axis symmetry, rather than one that affects the TF Aegis insignia alone.

It's most apparent on insignia images that have text or numbers though. See that the number 12 is reversed on the NATO fatigues in the image I attached, but the correct way around on the AAF combat uniform (and all other uniform models).

Really, all that needs to be done to fix it is to flip the U coordinates on the 'insignia' selection's UV map.

Have you tried the "combat pace" with rifle lowered? It's slightly slower than the lowered jog speed and less fatiguing IIRC.

@ oukej

Do these more precise zeroing calculations take into account the recent addition of initspeed settings for weapons, or are they only based on ballistic information from the magazine initspeed?

Can we please have this BIS?

It's pretty nonsensical that there is a addSecondaryWeaponItem command, but no removeSecondaryWeaponItem command, and I'm working on an addon that would benefit greatly from the removeSecondaryWeaponItem command being available.

This is only an issue with the TMR mod's 2D scope replacements. It doesn't happen with the vanilla 3D scopes Arma 3.

IMO they should at least have a DPICM/Cluster-munition version of the rockets since the majority of munitions developed for the real-world MLRS were DPICM munitions (M26, M30(GMLRS), most warheads for the MGM-140 ATACMS and IIRC SAGE 227 were all DPICM).

In the past, the UK, France and Germany used to have AT2 rockets to deploy AT mines, but stopped using them due to various landmine and cluster munition conventions (which I know Arma 3 doesn't adhere to, hence we have 155mm DPICM and mine munitions), so they are also a realistic option for the Sandstorm.

Unitary munitions (single warhead HE) like the one used on the Sandstorm are actually a fairly recent addition to MLRS' arsenal; only becoming a mainstay with the introduction of the M31 GPS guided rocket. Nowadays this is the only munition used by the UK's MLRS (and I think Germany too) because of the previously mentioned conventions on cluster munitions.

The US had an XM29 SADARM munition as well.

Have you adjusted the elevation of the gun with Page-Up/Down and Shift+Page-up/Down (for slower, more precise adjustment) until the REL and ELV numbers in the bottom-right of the reticle match?

Bear in mind that there will be a bit of a spread pattern to where the rounds land

"Also the US flag, and probably other nations flags as well, should only be worn on the right shoulder"

This is only a convention in the US Army.

AFAIK USAF, USMC and US Navy personnel wear the flag on the left shoulder, though only aviators seem to wear flag patches regularly. I've seen pics of US SOF blokes with flags on both arms though (not sure what branch they were).

Other armed forces and nations have their own regulations. In the UK, the Union Flag patch is supposed to be sewn on the left shoulder in PCS and the old CS95 uniforms. The Netherlands, Canada and France seem to use the left shoulder for their flag patches too IIRC. German and Polish soldiers wear flags on both shoulders

Be better if they made them both additional hiddenselections, so we you can do the following:

*this setobjecttexture [0,"texture1.paa"] change the uniform texture
*this setobjecttexture [1,"texture2.paa"] sets the flag on the right arm
*this setobjecttexture [2,""] //clears the flag texture on the left arm

The eye cup on many NV and Thermal imaging devices are like that, it works as a sort of rubber 'sphincter' to stop light escaping from the eyepiece when the user isn't looking through the optics.

They have a special design where if you push your eye against the rubber cup, those four triangular flaps open, allowing you to see the eyepiece behind the rubber flaps. When you pull your eye back out of the eye cup, the flaps close again. See the gif below:

http://www.bfro.net/news/images/hseries-eyepiece.gif

Reason that you don't want light from the eyepiece escaping is that it allows enemies to spot you in the darkness.

Yep, it seems to have been resolved. Took me a little while to check and confirm - sorry!

Thank you for taking the time to work on this Borivoj.

Yes, the ability to lock the camera to a ground position or simply having greater stabilisation would be great.

Right now the MQ-4 jitters rather a lot as it lines up to engage a lased target from the turret; which throws the turret's POA off right before that critical moment where the aircraft launches a missile.

This can increase the chances of of missing the target quite substantially if the aircraft doesn't stabilise long enough to correct the turret POA before it launches a missile (without much warning due to the fact missiles are released without a "command fire" order).

As Nod said, this is particularly troublesome when trying to use the 35x zoom

Even in good conditions the Milky Way is nowhere near as visible to the naked eye as most published photos make it out to be. The photo you've used as an example is clearly a long exposure or has been post-processed.

This site shows examples of a simulated 'naked eye' exposure of the Milky Way under good conditions (low levels of terrestrial light pollution, no moon - e.g. high NELM) and compares it to typical camera exposures and adjustments used in published photographs of the Milky Way:

http://intothenightphoto.blogspot.co.uk/2013/02/view-milky-way-with-your-naked-eye.html

Looking at what stars are visible in Arma's sky though, I'd say a hint of the Milky Way should be faintly visible to some degree. The real one is discernible from the background sky at a NELM (Naked Eye Limiting Magnitude) of around 5. Arma's sky seems to have a NELM of around 5.5 to 5.75.

As Instagoat says though, a NELM of 5.5-5.7 isn't quite enough to see a Magnitude 6 object like the Milky Way in any great detail.

Created a small video to demonstrate the bug:

http://www.youtube.com/watch?v=5xh21ZfYGYs

@galzohar

You do need some sort of velocity value attributed to the magazine or ammunition class in order to account for different propellant loads for e.g. the difference between subsonic and conventional ammunition.

If MV was wholly determined by the weapon, all magazines would fire at the same muzzle velocity regardless of the load, unless they made it so you manually defined muzzle velocity for each magazine in the compatible magazines array of the weapon. Defining specific MVs for every possible magazine that someone might want to use for your weapon would be tremendously labour intensive and would mean you couldn't simply rely on class inheritance from BIS weapons of the same calibre to automatically add suitable new magazines to a weapon from community ammunition mods (e.g JAM in the past, lkr_ammo for Arma 3 etc. etc.).

I guess muzzle velocity is determined where it is at the moment because if it was defined in cfgammo you would have to define a new cfgammo class AND a new cfgmagazines class to make something like a subsonic magazine (If you define the initial velocity in the magazine, you can use just one cfgammo class and make the variations in the cfgmagazine classes) and like I said, having it entirely in the weapon is too confining when it comes to magazine inheritances.

Having a weapon-based coefficient to the magazine values is by far the most streamlined solution to simulating the effect of barrel length on internal ballistics.

I would like this feature very much.

Likewise it would also be excellent if more cfgweapon properties such as the 'dispersion' parameter could also be modified/overwritted by muzzle device coefficient. I'm thinking of weapons that have field-exchangeable barrel+gas-system assemblies of variable lengths and the different barrel harmonics created by attaching devices to the muzzle causing changes in POI/grouping.

Yes, seems to be fixed.

Nice work guys :)

Do paratroopers wear body armour while jumping IRL?

I was under the impression that most parachute rigs cannot accommodate bulky body armour underneath the straps or that special, cut-down plate-carriers had to be worn in order to jump safely while wearing a vest.

If they don't, perhaps the best alternative would be to make the parachute item into a vest-slot item rather than a rucksack-slot one, allowing rucksacks to be worn in conjunction to the parachute, and if a player needs body armour allow them to store it in the rucksack and swap the parachute vest for an armour vest on the ground.?

No, the error message is no longer present in Dev Build 107070 (28/06/2013).

Seems to have been fixed. :)

According to the description stringtables in the Arma 3 config, the standard ARCO and HAMR infantry optics are supposed to represent 12x magnification, and the SOS is supposed to represent 10x-85x Magnification.

If this is the case, the default rifle optics in game already have a fairly significant magnification factor beyond typical real-world infantry optics (which tend to be around 3.4x to 4x), and are comparable to the low-magnification settings on the game's sniper optics.

What I meant was you can't do it with the current implementation BIS are using for sight models, in the context of this being ticketed as a bug.

The ACE system was a separate FSM-based scripted solution to provide an overlay on top of the weapon optics IIRC. It didn't use any of default core modeloptics mechanics other than the FOV settings. Adding something like that would need ticketing as a feature request, not a bug-fix.

There is already a ticket to add it as a feature:

http://feedback.arma3.com/view.php?id=8446

Not entirely sure how well the old ACE method would work now either, since the sights are now being modelled without the black shroud around the edges which occluded the parts of the reticle that were scaling outside the field-of-view through the scope.

The stepped zoom results from the sight having two different opticsview models that allow the mildot reticle to be correctly scaled against targets at both zoom levels (each dot is one mil apart, i.e they measure a length of 1 meter at a distance of 1000 meters). One model has the mil-dots scaled correctly for opticsZoom = 0.04 (nominally 10x zoom) and the other model has the mil-dots scaled for opticsZoom = 0.01 (nominally 85x zoom).

Allowing the mil-dots to scale with zoom is an important feature for range estimation:

http://www.mil-dot.com/articles/how-to-get-the-most-out-of-your-mil-dot-reticle

This is why most real-world sniper optics have the reticle in the First Focal Plane.

Currently it's not possible to scale reticles based on sight zoom levels using the continuous zoom feature of Arma 3, as continuous zoom only uses one opticsview model. This means the mil-dots would only work for one exact zoom value.

The continuous zoom feature can only be used on sights that are intended to represent scopes with the reticle in the Second Focal Plane.

BIS could try and approximate a more smooth transition between the minimum and maximum zoom levels by having more 'steps' in the modelOptics array, which requires making more models for the optics view with appropriately scaled reticle textures for each model.

For example I have made a scope addon for Arma 3 that has 5 discrete zoom levels (5x, 10x, 15x, 20x and 25x) using 5 separate optics view models with the reticle scaled correctly in each model. I can assure you it's quite a lot of work to make lots of different models for each zoom level :D

It's a Monolith Arms foregrip - a real life accessory for the F2000/FS2000

This was an intentional change as reflected in the changelog:

http://forums.bistudio.com/showthread.php?149636-Alpha-Development-branch-changelog&p=2399989&viewfull=1#post2399989

"TRG now uses correct 5.56x45mm ammunition"

Just a little FYI that this appears to have been resolved at some point (though I've not round a reference in the changelog). The SOS now has a fixed 100m zero for the backup sights.

Ticket can be closed.

Even with the current implementation of reticle scaling at discrete zoom values in the dev-build I think there is room for improvement along the lines of the first focal plane optics simulation that Fincuan and ACE did in Arma 2.

I think it'd still be good to have the ability to scale the reticle smoothly using traditional variable zoom (like we had for sniper scopes since OFP) as is the case for most real-world first focal plane scopes, rather than have it only for 'stepped' zoom where each zoom level is a discrete value with a different optics model (as was introduced for vehicles in Operation Arrowhead).

The stepped zoom is more commonly associated with vehicle-based electro-optics than rifle-mounted optical sights.

@MadDogX Technically NLAW is disposable/semi-disposable, the missiles are delivered to a unit as an all-in-one pre-packed weapon and you'd only be able to get one shot out of them in a given contact before the launcher is set aside for the rest of the fight.

http://www.saabgroup.com/Global/Documents%20and%20Images/Land/Weapon%20Systems/NLAW/NLAW%204_sidig_org_0811a.pdf

"NLAW, a maintenance-free, disposable
weapon"

However, what the site you linked to refers to is the fact that launchers can be reloaded by Saab, and most operators would be encouraged to recover them at the end of a contact in order for them to have a new missile packed into them at a later date, or at least recover expensive, re-usable parts like the sighting and electronic systems, rather than leave them on the battlefield.

Making them non-reloadable, single-use weapons in Arma 3 would be still be appropriate - Retaining the empty launchers would probably be a matter for how realistic milsim players wanted to be in their ingame actions ;)

@Dr Death

I was on about military vehicles w/r/t the 5-point harnesses - I did mention later that I thought it might be okay in civvy vehicles with more simplistic 2-point lap-belt or 3-point cross-belt harnesses.

True enough that in the past, not many military vehicles had seat-belts, but operational experience in places like Afghanistan and Iraq has brought about a major change in how important secure seating inside military vehicles is perceived.

There's an article covering some of the improvements to crew restraint that were made of HMMWVs during the course of the Iraq war:
http://olive-drab.com/od_mvg_hmmwv_safety_improvements.php

But as you see, on newer vehicles like the MATV (Hunter in Arma 3), 4/5-point harnesses have been sought to offer even greater protection

http://newsblaze.com/pix/2010/0527/pix/1005027-A-2848B-293.jpg
http://imminet.com/wp-content/uploads/2013/03/Occupant-Safety-Sell-Sheet_Final_lo-res.pdf

In my experience with the UK's military vehicle fleet, 4/5-point harnesses are now the norm on new military vehicle designs and regularly form part of the safety upgrades of older military vehicles.

In the UK we've even ditched bench seating in the back of trucks in favour of what have been dubbed "rollercoaster seats" that feature a roll-cage and 4-point harness, such is our current obsession with keeping occupants secure in the event of an accident or explosion.

http://www.revolve.co.uk/uploads/rops-flyer_web.pdf

Needs to be something that can only happen on certain vehicles I think.

I can't imagine anybody would get thrown out of a vehicle like the Hunter or Ifrit when they have a five-point safety harness on all the seats and armoured glass keeping them from being thrown through the wind-shield. The safety harnesses alone are pretty good, even in open-cockpit vehicles: how often do you see Formula 1 drivers being thrown from their vehicles wearing those sorts of harnesses, even in 100mph+ impacts?

Can fully understand it for things like the quad-bikes and open gunner's stations on top of vehicles, and possibly civ cars with less secure seating. Though in real life, something like 3/4 of cases where a person is ejected from a vehicle in the road accident it's because they weren't wearing a seatbelt. Might be easier to just consider that Arma 3 civs are safety-conscious and belt-up properly ;)

Might be worth adding if they added features like barrel overheating and changes as well, else why would you choose to operate the MG on anything but maximum cyclic-rate if it has no real downside other than burning through your ammo a bit quicker? (assuming your ability to do controlled bursts isn't very good)

It's not hard to add different cyclic rates to MGs as an addon though, you just add a couple more firemode classes to the weapon with different 'reloadTime' values and a displayname like "Gas 1", "Gas 2" etc. for each setting. Then you can cycle through them with the F key like you would between Semi, Burst and Auto modes.

Downvoted.

As an experienced Arma 2 player I found the 'weapon safety' feature annoyed the crap out of me in VBS2 and I turned it off ASAP; so I'm not keen to have it replicated in Arma 3.

Why not?

From the Tracker's "How To" guide:

"Voting will help us to determine what is important for players. You can also vote down, when you disagree with reported issue or it is minor issue for you."

I'd rather BIS spent time addressing other issues in the game so consider things like this a minor issue, and believe that adding a "safety mode" to weapons would adversely affect gameplay, based on my experience of how using it in another piece of Software on the RV engine - hence I disagree with its introduction to Arma 3.

I'd like to see this so long as the rangefinder doesn't constantly lase like it does now; as this would make the Fire Control System constantly adjust the zeroing/elevation range to match, making gunnery far too easy. It'd be simply a matter of holding the reticle over the target while you fire (I think the AH-99 Blackfoot's cannon FCS currently works in this uber-simplified way).

The vehicle rangefinder should only calculate range when the gunner tells it to find the current target range, then the FCS should zero/elevate to the last calculated range that the gunner measured and stay there until the gunner measures the range again.

Currently it's the rangefinding that is done (more or less) automatically while the zeroing/elevation is done manually; this should be the other way around - thus simplifying the gunnery procedure by reducing the number of manual keystrokes required, while still simultaneously requiring some skill and manual input to obtain a correct firing solution.

In real life, having the FCS constantly emitting laser radiation would also allow the vehicle to be easily detected and targeted by tracing the source of the laser emission - which is part of the reason LRFs don't work that way.

So you believe in the middle of a firefight a soldier CAN perform the following task:

Unscrew the caps on top of the RCO with his hands to access the adjustment dial

Find a screwdriver in his webbing and use it to turn the adjustment dial on the sight until he's adjusted it by the number of clicks needed to adjust the zero of the sight from the elevation needed to shoot 200m (IIRC the RCO is zeroed to 200m as standard), to the elevation needed for 600m**

Put the cap back on the sight and tap it to set the prism, and put away the screwdriver so their support hand is free to hold the weapon correctly (carefully, so the screwdriver doesn't get lost for the next time they need to adjust the sight ;))

Start shooting until the need to change the zero again.

I don't think they CAN do this in the time it takes you to press Page Up four times - which is what the mechanics of this would be in Arma 3.

**Bearing in mind that according to this ballistic table http://i435.photobucket.com/albums/qq75/opie011/CMRreticlechart.jpg the difference in elevation adjustment needed between 200 and 600 meters is 4.75 mils for 5.56mm and 4.16 mils for 7.62mm - So at 0.1 mils per click on the HAMR/RCO elevation dial this would be in the region of 40 to 50 clicks to make the adjustment for most medium calibre rifles. All of which he'd have work out and count in his head because there are no numerical references on the elevation dial to show how much the dial has been adjusted previously.

Much like the ACOG in the video above, on the real-life HAMR/RCO sight you have to remove covers from the windage and elevation adjustment dials. You can even see the rubber/plastic lanyards on the RCO model that stop the covers getting lost when they're removed while fixing the sight zero. The adjustment dials under these covers are countersunk, and can only be turned with a flat-head screwdriver, it's only the cover caps that are unscrewed by hand.

Detailed pic of the countersunk elevation screw and cover on a HAMR (RCO ingame), showing that it requires tools to adjust the zero and cannot be done by hand:

http://www.shootingillustrated.com/wp-content/uploads/2012/02/xW7487_SI_8004.jpg

The other sight in Arma 3, the ARCO/Specter, requires a basic tool (like a screwdriver or the edge of a coin, or the end of a rifle cartridge) in order to provide leverage when adjusting the windage screw at the front of the sight, and also to move the locking tab on the elevation drum at the back of the sight which must be unlocked before the drum can be adjusted.

The large hand-adjustable knobs on the sides of both sights (the ones with numbers written on them) are for adjusting the brightness of the reticle illumination on the real-life items, not for adjusting the zero.

If you contrast this with any real-world sight that is supposed to be constantly hand-adjusted to alter the windage and elevation during a firefight you will see that none of them have covers that obstruct access to the adjustment dials, none of them require additional tools to perform the adjustments. Most of them also have numerals written on the adjustment drums so that the shooter can refer to them and consult a range table to get the correct number of 'clicks' quickly, without counting them in their head or remembering how many clicks they adjusted for previously.

Everything about the RCO and ARCO indicates that they are not intended to use RscWeaponZeroing and they they should only rely on the BDC reticles for shooting at extended ranges.

I think this would require some sort of fireLightIntensity modifier/override to be placed in MuzzleItem type attachments, similar to the initSpeed, hit and sound modifiers that overwrite/modify the original weapon characteristics when equipping a suppressor.

Currently though I think all weapons have firelightintensity = 0.012; inherited from the 'Default' class, with no modification in sub-classes up to the in-game weapons - This would imply that BIS are yet to tweak firelightintensity values for weapons, since they all use the same value whether they are an MG, a Rifle or a pistol.