"I understand that the current system is not likely to change" Well thank gosh for that.

"They didnt create tracked aphibious, so they think they dont need to amphibious physx."

@Fighting Power: On their Twitter the devs have said that a fix is planned, though probably because they are planning tracked amphibious vehicles for the Expansion DLC. No idea why this ticket hasn't been updated beyond "reviewed" to reflect that it's been internally assigned.

@ Fireball: The path-of-least-resistance solution would be to replace the Mi-48 Kajman with the PO-30 Orca, since that had an unarmed variant.

It was as at least as oddly-high as a bunch of the other weapons have tended to be when I tried the Zubr.

This is unfortunately a limitation imposed by the current hard limit of three attachment slots ("underbarrel" is not simulated as detachable). I suppose that a combined laser/light unit as a single attachment is possible, but unless you're suggesting something like LCtrl+L for toggling between them I'm not sure how it would be implemented.

magirot's got a good point; MattyB could you please report how to reproduce this beyond "kill an Opfor unit in game", especially since at last check they're supposed to be wielding Katibas?

None of the magnified scopes work with nightvision, hence what you saw, ALTHOUGH the collimators (both the standalone ones and the ones built into the ARCO and RCO) and iron sights (including the one built into the SOS) both work with nightvision.

A 2011 promotional image showed a separate, dedicated nightvision scope, so maybe that will come by in beta? :)

The most likely 'difficulty'/issue with implementation might be that "reload animation right hand portion", especially when the bolt-action rifle's rate(s) of fire may be WIP...

So no worse than Arma 2, just no better?

Right now the underbarrel grenade launcher used in the game is dubbed 3GL, so in the context of "only vanilla/non-addon content" there is no naming conflict.

I would describe the issue differently:
(Here I use "ADS" to mean aiming down the weapon's iron sights or optic; its equivalent in the Arma 3 keybinds is "Optics" but I choose to use "ADS" for brevity. Likewise, I describe the default movement speed as "run", not "jog", and "unsighted" view -- that is, not ADS and crosshairs visible if enabled -- is considered the default view in this explanation.)

When moving without ADS the paces do not present the error; likewise, ADS while walking does not present the error, and ADS while running correctly forces the character into combat pace for the duration of ADS.

The error is that when the player manually toggles combat pace from the default unsighted view and then aims down the sight, the character's movement speed instead changes to run and there is a different "weapon bobbing at bottom of screen" animation than when normally running. From THIS state, "de-toggling combat pace" causes the character to return to combat pace and thus enter "aiming through sight" view (ADS) while leaving ADS will cause the character to return to the normal run. HOWEVER, from the aforementioned state where the character runs with the different first-person-view animation, clicking the ADS button (which would NORMALLY -- and in the prior stable build did -- just cause the character to leave ADS) causes the character to 'revert' to unsighted view and combat pace.

TL;DR: The current situation essentially "reverses" the ADS/running/combat pace dynamic from the way that it was in the prior stable build, where if you manually toggled combat pace from the default non-ADS view and then ADS you would CONTINUE moving at combat pace UNINTERRUPTED, while in the current situation attempting to ADS instead forces the character into running speed with the different "weapon bob" animation, and attempting to "de-toggle" combat pace instead CAUSES combat pace-movement-with-ADS.

At this time the only way to simulate the prior situation (with the prior stable build) is to be simultaneously pressing "combat pace toggle" and "optics"/ADS so that the effects counteract one another.

The error is also present on dev build 0.59.105634 as well as the stable build.

If what was on the devblog was accurately representative of how detailed the radio implementation in DayZ will be, then no, DayZ is not "getting this feature".

I reproduced this issue in the Editor after only placing a BLUFOR Marksman and a BLUFOR Support crate before clicking Preview.

Just replicated with the BLUFOR Rifleman (Light) and suppressed MXC.

Needs more details as to what's actually meant by "controller support is very much lacking".

One may also place a BLUFOR Support box before clicking Preview, and upon using it may be found that the Sound Suppressor (6.5 mm) is not compatible with the MXM.

Issue corrected as of build v0.53.103754

As of build v0.53.103754 the BLUFOR Marksman spawns in with the loaded magazine and six (6) spare 6.5 mm 30Rnd STANAG magazines, for a total of two-hundred-ten (210) rounds of rifle ammunition, in the default loadout.

I am also using the same development build (v0.53.103608) and I can confirm that this is an issue with the current dev build.

More specifically, the previous situation was that the same twenty-round magazine chambered in 7.62 x 45 mm (nice touch, I actually would want this back) was used in both the EBR; however, as of this dev build there is only a single twenty-round magazine chambered in 7.62 x 51 mm (I actually preferred the "not-so-cliche" 7.62 x 45 mm choice) but which is ONLY compatible with the EBR, while the MXM has been rechambered for 6.5 mm STANAG caseless and therefore those magazines are now compatible with all of the MX series weapons.

If this "rechambering" is indeed correct and intentional by the devs, then the problem appears to be that the BLUFOR Marksman's default loadout has not been corrected to replace the 7.62 mm magazines with the 6.5 mm STANAG caseless magazines.

EDIT: The submitted file is visual proof of this issue being reproduced, as well as the same file used as visual proof of the issue described in ticket # 0006682 (MXM suppressor compatibility was not updated).

EDIT: As of build v0.53.103696 this issue has not yet been corrected.

"As it is ArmA 3 is now a 'futuristic tactical shooter' not a 'military simulator'."

I cannot help but imagine a BI dev looking at this sentence and smugly thinking to himself, "Just as planned."

I wouldn't be surprised if 2035 and the "future warfare" look was chosen specifically because the devs themselves were bored of modern warfare...

"the ArmA series was a milsim... no longer I guess..."

Considering how people are showing up to Arma for other things BESIDES DayZ -- that is, things which they can't get in BF3 or COD -- why is it impossible to believe that maybe, just maybe, the devs feel the same way as them?

+1 to gotmiki!

EDcase, your idea is interesting but the main pitfall to implementation would seem to be how... seemingly "we were obligated to do this so we're not going to put effort into it" the current deadzone implementation is.

It APPEARS that in dev build 0.55.103923 all non-walk speeds got nerfed but without any turning change; maybe someone hasn't found out how to differentiate turn speeds between the movement speeds and thus it's "one turn speed for everything"? One might hope that RV4 doesn't work like that, but who knows.

As of the dev build v0.53.103608 the weapon has since been rechambered to the same 6.5 mm STANAG caseless caliber as the rest of the MX series and uses the same magazines as the rest of the MX series.

Wasn't this already done on dev branch and then retracted/removed?

I'm actually cool with the round being listed as 7.62 x 45 mm... at this point 7.62 x 51 mm seems almost boring by now to see in the future warfare-themed game, and it was actually funny to see a however-subtle case of "CZECH STRONG" in the alpha.

The issue has popped up again with the 4-five pistol -- although its "high profile" sights are so tall specifically in case of use with a sound suppressor, the misalignment of the Sound Suppressor (.45 ACP) on the model undoes this. Examples of what should instead be presented can be seen here:
https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcT5TSRF9Os71_uTgirH9ss51sDK0FcQg8DI6uBrYmx9znrF5BWOfw
http://i.imgur.com/4gJe7.jpg
http://www.aacblog.com/wp-content/uploads/Clint_TR45-600x433.jpg

Speaking of which, the ironsights are NOT co-witnessing with the MRD as depicted here:
http://i1042.photobucket.com/albums/b425/racer88_bucket/Gun%20Stuff/FNP-45T-RMR_0005.jpg

Note that the below-waterline compartments were for surface warfare vessels, apparently -- and there was only a limited level of submarine simulation.

EDIT: I was talking about VBS2's maritime simulation.

For what it's worth, dev neokika said that for the June 1st livestream they used a work machine with an i7, 8gb and a GTX 660, "And Arma 3 runs very well on it, with great visual quality", and for the second stream "during it we were having very smooth gameplay, >40 fps all the way", but that the video stream didn't reflect how fast and smooth it was for the devs playing.

So that at least is a guideline to what a dev was using...

Seconding that confirmation that the issue can be reproduced in 0.54.103957 by the described method.

I like the silhouette and arrows, would vote to keep.