Report file: https://drive.google.com/file/d/1-p-xtKumyT01CSwiHV2gTZw8bepNQ-4p/view?usp=sharing

I can confirm the issue. Given that Sentinel can carry HARM missiles, it would have been a great SEAD platform... if the RWR worked correctly
P.S. It seems for all aircraft, RWRs shows signal when "the radar can detect me", not "when I can receive their radar". In reality, RWR detection should be at least twice as much as radar detection range

I can take my comments wherever I want. Use emails if you can't tolerate notes on your tickets.

EDIT: And hey, your other tickets - for example #20855 - do follow this rule. One issue in description, accurate repro steps - why not just make another good ticket?

By "bad tone" I mean dumping all the info into one ticket and leaving all the work in separating the info to developer. You want them to do something, can you at least do your part and make tickets properly? That's the respect they deserve. You're free to skip my advice, of course.

If you want those issues fixed, I'd recommend you make one ticket for each issue. I am a software developer myself, and I usually just skip "all-in-one" tickets ;) as it's really a bad tone

Yes, you're right, I didn't understand your ticket. You have attributed this issue to Debug CRT itself, which is actually wrong. That got me confused.

Debug CRT only sets the memory to the provided values *if the buffer is allocated within it*. When the buffer is passed into extension by ArmA, that is obviously not the case - the buffer has been already generated by Release CRT that is used by ArmA and stays there. The runtime which your extension was linked against has no effect on ArmA's runtime - meaning ArmA will always give you a zero-filled buffer, regardless of whether you start with debug

Judging from your description (unless there are some more details missing), what you're actually looking at is an issue with sprintf_s function. It is not a C standard function, but rather a Microsoft extension; and Microsoft did their best there in not following the "least surprise principle". Debug version of sprintf_s just fills the rest of the buffer with bogus data - that is why your buffer ends up filled up with 0xWHATEVER instead of 0x00 that were there previously.

Why am I saying it is not Debug CRT fault, if it's debug version of function?
Because with a slightly different code you can get it working regardless of runtime:

    memset(output,0,outputSize)
    std::string balls("My balls");
    memcpy(output,balls.c_str(),balls.size()); // Copying without the 0-byte, as the buffer is zero already

Neither your code nor my example above use any explicit allocations; hence, Debug CRT's stack overflow protection is irrelevant.

To workaround this issue, you can try to:

• use code similar to above
• use undocumented function _CrtSetDebugFillThreshold(0) which disables that bad behavior[1]
• just take a more standard-conformant function like snprintf().

[1] see more here: https://social.msdn.microsoft.com/Forums/vstudio/en-US/16ce9c2a-341e-4601-82cd-bb437ab8a6bf/sprintfs-slower-in-vs2010-than-in-vs2008

I agree with your suggestion regarding ArmA's behavior. What I'd like to note is just that your issue is not with Debug CRT per se, but with a specific gotcha in one Microsoft's function.

P.S. output[outputSize-1] is not "2nd-to-last" byte, it is the last.

If that's true - how on earth do extensions work now? If in debug mode the check hits an unallocated space, then in release it should have hit uninitialized area => only 1/256 chance of having zero there.

Something does not compute.

That's 2 separate feature requests

He's not conservative, I'm not sure it's a good idea either.

Well, for me it happens in SP as well. Do you use Advanced Flight Model?

Fair point. But #14924 talks specifically about MP, it will need to be updated to close this as duplicate

Do you have this issue with default model as well, or with AFM only?

Updated repro steps - I didn't notice stress damage is enabled separately, thought it was part of AFM.

Hi Adam,

I'll try to, not sure what more can I say

The issue is that if you apply rudder sharply (for example, press E or press right pedal "instantly") in a horizontal flight at 200 kph with advanced flight model enabled, the ATRQ rotor blows out.

For more reliable repro you can try combining the motions - try to zig-zag rudders, or make a coordinated turn (http://en.wikipedia.org/wiki/Coordinated_flight#Coordinating_the_turn) to the right side

I'm not sure what other information I can provide, it is happening to me regularly just with those conditions. No mods, stable branch, Advanced Flight Model enabled, reproduces for me with Saitek X-52, Saitek X-55, keyboard. Video above shows how it looks (that sharp metal squeaking).

Perhaps one more thing I forgot: in AFM, I have all options enabled

Actual cause and repro of this issue is #23956. No relation to power settings at all, it's a code issue with AFM enabled

The effective range should be 500m-600m since there is a similar gun called the VKS 12.7mm with subsonic ammo that could shoot up to 600m.

Russian "effective range" is pure marketing, effective range for AK-47 is stated to be 1000m - obviously bullshit.

No, that's a "don't try to control a helicopter with an apple". If you want advanced flight model, buy a joystick.

Hi George,
I'd suggest two ways to do it:
1.crop the hashes at first 32 or 64 bits. Hashes retain their "randomness" property even in cropped form. This may increase probability of false positive, but we still have a signature check upon join. 2^32 is not good enough for crypto, but certainly is for rough mod check.
2.Encode hashes in Base64 instead of Hex - 4x space saving.

These approaches may be combined.

The awesome TMR mod is exactly the reason why I created this ticket. TMR scopes behave just like 2D ones - and it feels just so much more comfortable - just like old 2D scopes over current 3D. Unfortunately, TMR brings some non-client-side changes too, so it can't be recommended to be used always - because if some players don't have it, it becomes a mess.

I intend to make a fork of TMR to have a clientside-only addon, but the problem remains valid for core game.

Besides, you can still mod 2D scopes, can't you?

The whole point is to avoid mods while having consistent experience. Right now, half of the scopes in vanilla are 2D, half are "3D". And it's not even tied to magnification really - NVS scope has mid-range zoom, yet is 2D.

Besides, you can still mod "3D" scopes, can't you?

Doesn't seem BI is interested in it anymore :(
PiP scopes are certainly better. I'm all in for proper implementation. But given the choice between current terrible scopes and "old" 2D ones, I choose 2D.

Already reported and I don't know why people consider this an issue. Just look at the body instead of the weapon when opening the gear.

The problem is that sometimes you're looking at body, but the game has other opinion. Upvoted until we find the original ticket.

Maybe you watched too many movies...

Maybe you stop insulting people's judgement head-on?

Any unmanned vehicles are NOT intended to attack enemy without human confirmation.

Who said that? You? Who you are?

Because otherwise it may cause some catastrophic effect, especially if im trying to sneak to enemy and UGV opens fire.

It's your problem, not game problem. If you don't know how to use a tool - don't use it.

but, if i recall, doesn't centripetal force affect fighter jets significantly less? (again assuming no control input) and since the game doesnt have any slow movers yet, its hard to guestimate what the implemented effect is.

This is wrong. The "centripetal force" as you call it depends solely on roll angle - it is L*sin(θ), where θ is the roll angle, and L is lift (which is equal to m*g for a properly trimmed plane at any orientation). There's no "jet/no-jet" factor in the formula.

Example @45 degrees bank:
1-st case: no pilot input, plane is trimmed for level flight (1g, L = m*g)
Lvertical = L*cos(θ) = m*g*cos(θ) = 0.7 * m*g
Lhorizontal = m*g*sin(θ) = 0.7 * m*g
As you can see, the plane would experience a 0.7g lateral acceleration and a 1.0-0.7=0.3g vertical acceleration (losing altitude)

2nd case: pilot is countering loss of altitude by adding pitch input
Lvertical = L*cos(θ) = m*g => L = m*g/cos(θ) = 1.42 m*g
Lhorizontal = L*sin(θ) = 1.42 m*g / 1.42 = m*g

As you can see, lateral acceleration with additional pitch applied is only 42% faster than same without manual input. So, the effect would be VERY noticeable. So, EagleFlying is totally correct here.

Moreover, a jet at bank must experience sharp slide to the side of the roll, unless countered by rudder. This is also missing.

UPVOTED. But you DONT need to GO ALL CAPS!!!!!

IRL, pitot tube doesn't measure side speed...

@Vitdom: obviously, there are no weapons except machineguns, and Darter exists in reality.

Upvoted. Quads of such size can carry cargo in order of kilograms, and .22LR gun + 20-30 rounds would weight far less than 1kg. That's not a machinegun, but will also have its use (example: Ghost Recon Alpha short movie http://youtu.be/7-wAzlqzXH0?t=7m28s)

I'm also experiencing random crashes in multiplayer, attached two archives (Crash-1.zip+Crash-2.zip), rpt+dmp+dxdiag inside

Suggestion: can you post a video of the bug and provide map coordinates?

Duplicate of another ticket (#5374)

Write time in the mark description :)

I don't thing ИЛС is a correct translation for HUD. ИЛС is a HUD in aviation context only - it's strange to talk of "Windshield indicator" (which is a literal translation of ИЛС - Индикатор на лобовом стекле) when talking of a soldier (which it is applied to in ArmA 3).

Otherwise, good finds

Possibly same for Windows binaries.

That's still not a reason to create more and more duplicate tickets...

First ticket about it: #768

I also would like to see F-22 instead of F-35, due to larger payload and higher possibilities (maneuverability, larger set of weapons)

I'm afraid it's a fix for another isse brought up recently on the tracker, where miniguns were totally uneffective due to low rate of fire

its a dupe, not the first issue to adress this, dont remember the ticket number

Yes, RobertHammer has gave the link to the first issue here.

@Mods: duplicate of #768

It seems that normal suppressors are not capable of preventing a flash.

You're confusing flash suppressors (http://stickman.rainierarms.com/galleries/WeaponEvolution.com/IMG_7494%201028%20WEVO.jpg) with "normal" suppressor (https://d2t1xqejof9utc.cloudfront.net/screenshots/pics/05a213ebf9d4b2f0040bb93d471aa0f6/medium.JPG). The wikipedia article talks about first kind.

Not actually a bug.

See http://en.wikipedia.org/wiki/IEEE_754.

It is standard for computer representation of number to have positive zero, negative zero, plus infinity, minus infinity and "Not A Number" signal value. Also, the function for raising a number into a power is called "pown".
Welcome to the wonderful worlds of computers :)

However I don't see this coming to ArmA anytime soon - I think calculations would be quite intensive especially for a moving target.

ArmA 2 OA had it, actually, after some patch. Locking a target with Tab would make your guns shoot with target's lead - you only needed to keep crosshairs on target. So it definitely was implemented and later disabled.

I'd suggest you close the issue, as it always worked this way since OFP.

If you use script of wind effects with aircraft you will be able to stall with FULL THROTTLE. Only because the reference is GS !

It looks like your script is wrong, then. Whatever the type of HUD indication is, if you're flying, you're flying. I can't see how HUD indication can affect airworthiness of an aircraft.

Did it actually download the update, or did you launch it straight away?
Have you tried verifying game cache? Is development branch actually off (IIRC, if you press Escape, settings are not saved)

Remove showScriptErrors from your startup line and don't complain about feature you've enabled yourself.

ARMA 3 is not REAL LIFE. It's a sim, but not EVERY realistic aspect is enjoyable.<<<

Okay, let's then put fireballs, healing spells and trolls into it... It's a game, after all, no? Oh, and we can make dead players into spirits, so that it's easier to revive them.

"Revive" is not a core mechanic, and what you're proposing will look just stupid in vanilla game. Why won't script authors do something about it? Or why don't you just ask yoiur buddy to reduce the timer?

My buddy sets his revive timer to 5 minutes. (He likes realism on his server) But getting stuck underwater for 20 minutes . . . is not cool. Thanks.<<<

20 minutes respawn == realism? Huh.

Related: #17275
If the sights would be reverted, the problem will disappear

I know some might disagree, but when you tell your driver to go forward, in most times it doesnt mean you want him to crush into something, but follow some street for example or avoid obstacles.
They shouldnt ignore obstacles imho.

Actually, as written here, I disagree :) When I tell the driver to go i.e. forward, to avoid being fired upon by enemy armor, I want him to do exactly just that and crush trees and whatever is ahead - catching an enemy APFSDS will be much less pleasant than that.

This mode of command is for combat, really. For usual movements, there is the <~+left click>. Otherwise, commanding the AI crew in combat will be a constant battle with AI stupidity (which it is sometimes now, but only sometimes - all in all, it's pretty good).

For the same reason I disagree with p.3 - "combat" emergency orders have priority over normal "route" orders. Again, when I'm under aim of several APCs and MBTs, I don't want the AI to look for "good" route, I want him to get the hell behind this concrete building.

P.1 and P.2 are agreeable - but since everything is in one ticket, I don't vote at all.

If you're the ticket creator, you have "Close" button available. It's near the " monitor" button.

Already reported as #15457 and #14840 - relates to all vehicles with optics.

Closing as no people support the idea

Yeah, I mean what's seen in first video, as core functionality. "Nah".

What if you execute the sequence backwards? Like, first put the player/UGV far of airfied, then close to it. I feel this may actually be related to multiple previews (#15201)

@Fri13: I'm not arguing with demagogues.

And as a reminder, in helicopters (and airplanes etc) Center of Mass is always somewhere in fuselag and below main rotor. But Center of Gravity (CoG) does shift [...]

...Illiterate demagogues who don't know shit about physics yet argue.

@antigoon78: Well, if the videos don't convince you, I give up. There's a lot of materials around, but, well - if you don't want to believe me, I won't be able to force you.

True, but nog JUST CoG, that's my only point here.

I get what you're saying, but that's what I'm trying to tell you. It is CoG, CoG and only CoG :)
I understand that for you it's me vs. something you heard a while ago, but please understand that here I'm talking from the position of science approach, not from my own intuition. I think you agree that scientific approach has precedence over opinions. Otherwise you may as well believe in flat Earth on 4 elephants and a turtle :) And I would not be able to prove otherwise to you.

I am sorry for (possibly) mentoring and/or blunt tone, however, I just don't know how to bring my point otherwise.
As a physicist (by education) with some experience in creating aircraft simulations, I'm feeling painful when someone is promoting an incorrect point.

I kindly ask you to review the videos I've provided again - in every video you'll see proof to my point.

Well, the Wikipedia has bad wording here

In forward flight, the center of mass will move aft to balance the negative pitch torque produced by applying cyclic control to propel the helicopter forward; consequently a cruising helicopter flies "nose-down" in level flight. (end quote) <<

By "movement of center mass" it's actually meant that since the helicopter pitches forward, the rotor center will be ahead of center mass (and, vice versa - the center of mass will become behind of rotor center)

In the blackfoot the roll axis is not placed somewhere in the middle of the aircraft where it should be, but on the bottom of its fuselage.

With that, I agree fully. The center of mass seem to be too low in many of ArmA choppers, lying close to gear. However, that still doesn't mean that, quote from your ticket:

when executing a right roll, the fuselage should tilt left alround an axis that runs through the rotor head.

Instead, the rotation should be done around *correct* center of mass, and not the arbitrary one currently present in the model. If you change the wording in your ticket, I'll happily change mo downvote to upvote.

(pitch movements turn around the rotor head)

No :)
http://www.youtube.com/watch?v=uYbx5H5e9Es see at 0:48
http://www.youtube.com/watch?v=j-piEL58hsg at 0:38

You can see that the helicopter turns around center of mass, until the backward rotor thrust makes the movement too complex to understand anything again.

"Rotating around rotor" is just an illusion, appearing because the rotor is bigger and is subconsiously taken as point of reference.

So it's actually not JUST CoG. Helo's are a strange beast of dynamics. But i'd have to try and find my helicopter books to really see what that exactly was.

Whatever "strange" they are, they still obey basic laws of physics. Human perception and intuition, on the other hand, are faulty, and don't work well in complex matters. For example, rotation + motion can easily be confused for rotation around another axis - which is what happening now ;)

there is actually a play between the center of force (ie the rotor head/swash plate) and the CoG. So it's actually not JUST CoG.

Well, I guess, helicopter technician training instructors cared not about scientific correctness, but about you getting the idea ;)

From physics point of view, there is only rigid body dynamics, which is affected by aerodynamic forces/torques. Aerodynamic is complex, yes - but once it's accounted for, it's plain old mechanics from the Newton age - CoG + mass distribution + forces distribution = movement. Everything is simple as an axe.

In actual helicopter physics, all movements revolve around the rotor head, that is the main pivot point of the aircraft.

No, they are not... All rotational movements of a free system are always going around center of mass. Physics 101.

I wonder how many people will fall to this same fallacy again...

See my comment (http://feedback.arma3.com/view.php?id=12443#c58619) for the list of videos disproving your point.

Duplicate of #12443, by the way

Well, tab lock is another issue... Here, I mainly talk about A2A combat.

Of course, if this gets fixed, AA would benefit too.

I don't mind the AI pilots flaring. Just make sure you got good angles.

Problem is - angles don't make a difference here. There's no "guaranteed hit" envelope, like it would be with real aircraft (read: missile launch from behind at close distance. Due to inability to spot the launch, accounted for vast majority of MANPADS-"induced" Soviet helicopter losses in Afghanistan).
I'm not against giving AI chances to stand against the player, but curretnly the engagement is all about the chances and nothing about tactics.

If there's an auto-dispensing system modelled - it should be given to the player as well, if not - well, make the AI have some delay before launching flares. Even 0.2 seconds would make a difference.

Sorry, there is no Merkava in Arma 3. However there is a fictional vehicle called the M2A1 Slammer which isn't equipped with a 60mm mortar or a 12.7mm commander's machine gun.

Or M2A1 Slammer is an army designation for the Merkava Mk4 which was actually put on service by US armed forces in 2030+? FN Minimi == M249 is a nice modern example of this.

Anyways, giving M2A1 Slammer a mortar would both bring it closer to the real prototype and give it great tactical flexibility. I support the ticket.

Since I'm not a pilot, and I'd assume turning when banking probably happens in real life due to aerodynamic properties of the airplane, this is a bug with the aerodynamic model itself and shouldn't be relied on autorudder on/off either way.

You are correct here. See my post in the Fixed wing discussion thread:
http://forums.bistudio.com/showthread.php?167067-Fixed-Wing-Flight-Model-(dev-branch)&p=2545932&viewfull=1#post2545932

Hi, Heisenberg,
There's a "Close" button below the description of the ticket (near "Monitor") - please use it to close the ticket with the "Resolved" resolution.

On what?...

where in real life it will take around 5

Where is the info from? Any reliable source?

@Squeezebore: Thanks for correction, it turns out I've actually confused 9x21 IMI vs 9x21 Gyurza Russian round (which *is* slightly longer). Even better then.

EDIT: Although 9x21 IMI actaully is still slightly longer than 9x19 parabellum: 29.75mm vs 29.69mm. I don't know if 0.06mm of difference will require magazine modification, but that's not important here.

Similar to the problem with the Vermin and that other weapon, hopefully we can see the correct caliber for this one.

What is "the problem" with these weapons? Both Vermin (TDI Vector) and Sting (CZ Scorpion EVO3) have correct caliber.
http://ru.wikipedia.org/wiki/TDI_Vector (.45 ACP)
http://en.wikipedia.org/wiki/CZ_Scorpion_Evo_3_A1 (9x19 mm parabellum vs. 9x21mm ingame - same caliber, different cartridge - but that's a matter of slightly changing firing chamber/magazine dimensions)

I agree with the OR (Original Reporter) - I personally find red-dot sights more convenient than those using a "reticle" (Holo/ACO) - because a reticle does (wrongly) obscure the objects behind it - it should actuallly use additive blending.

I've shot helicopters - and even jets - going on attack runs multiple times in A2. When the aircraft is coming (almost) exactly at you, there's practically no lead to take - it's as easy as taking a shot at slowly moving vehicle.
Do they do anything superhuman, like shooting a jet when it's flying perpendicular to the line of sight?

1. It is most likely not 9x21mm Guyrza, but 9x21mm IMI (given that there are many Israeli weapons in the game): http://en.wikipedia.org/wiki/9%C3%9721mm
2. Why should 9mm round have similar performance to .45? Any hard evidence?

Duplicate of #13255

One more repro case: when switching between gunner and pilot multiple times via Team Switch, optics also stop to be accessible. Also, may be related to #15701

Figured out the repro - you need to die before restarting preview.

Exactly the opposite for me - works great first few times, then breaks. Agree, definitely looks like something uninitialized or undefined behavior.

@alef: It happens in multiplayer only.

Not true, I've reproduced it multiple times in the editor.

Damn, just wanted to report this bug...

Actually, you stop being able to access optics not when switching to "player as gunner", but after a certain number of previews (may be 1).

My repro is as follows: place an AH-99 (player as gunner), place preview, try to access optics, exit back to editor. Repeat preview. At some point optics will stop to be accessible.
Restarting the game fixes it.

@InstaGoat

It is not a bug because (...).

Sorry, but you're plain wrong.

1.In ArmA 1/2, there was no visible cloning of aiming reticle/point
2.In real life, blur of out of focus objects is radial
3.In real life scopes, the reticle is in one of the internal focal points of the optical system. Hence, it will not be blurred when looking at target.

Hence, it is a bugged implementation of an effect that shouldn't be there. I'd suggest you stop changing terms and arguing for the sake of arguing...

@InstaGoat: Why do you think it's not a bug? Yes, it disappears with the DOF setting, BUT real DOF must be 1.gaussian blur 2.not applied to scope reticule (I am assuming DOF is Depth of Field effect, given no other explanation)

It is a bug for sure.

Also appears, GeForce GTX 570.

I think he said clear enough - HUD in choppers and airplanes (which is not changeable through options).

7.62x51 has almost 50% more energy at 1000 meters, so damage does actually differ. Due to that, it's still much better cartridge for a marksman rifle. Source: http://www.shootersforum.com/rifles-rifle-cartridges/8865-6-5-grendel-vs-6-8-spc-7-62-nato-5-56-nato.html

(I'm assuming the bullet is of "Grendel" type, because the rifles caliber is described is 6.5×39mm caseless)

@samogon:
These values work only at reference velocity. The game has simulation of ballistics, meaning the damage will be scaled with distance and velocity drop.
As for Grendel, I've already said this is an approximation. But this approximation is better than just naive "Well 6.5 is almost same as 7.62".

"Almost" is a bad word here. 5.56 and 7.62 are also "almost" the same. The devil is in the details.

Closing - too unlikely to be added

Closing myself as a duplicate of #12243

You can disable the crosshair in extended difficulty configuration for any difficulty, also, crosshair snapping can be disabled in options.

As was already pointed above, It's not "earth curvature". It is viewdistance "bubble" (*sphere*) intersecting with sea (*plane*), resulting in a circle being visible (http://www.vias.org/calculus/img/11_partial_differentiation-9.gif). Your "maxed out" 12 km is still very far form real life - where you can get as much as 100km.