You've answered it yourself - YABNON-R is not Greyhawk. The former is recon, the latter is - looking on payload options - a multipurpose strike/recon. With this in mind, having greater speed at the expence of several percent's worth of loiter time seems entirely justified. MQ-9 Reaper - Predator's strike/recon cousin - has max speed of 400 kph compared to Predator's 217. Common sense ;-)

I don't honestly see why was this ticket assigned.

@DarkWanderer: Saying "you're wrong" doesn't make me. All you're saying is that this is "possible" now, or could be "possible" 20 years later...without specifying why or how.

"i feel it should be so" was taking into account whatever info i could find, basically saying "have we hit a wall, as far as speed/engine size/aircraft weight and shape are concerned?" and if yes, then is it reasonable to assume that this aircraft should not be able to fly that fast.<<
You're wrong assuming that "reasonable" is an argument. For you one thing is reasonable, for other person - another. The only common denominator is (tadaam!) physics. You have also failed to provide any "reasonable" explanation except "well, look at it, it can't fly that fast".

You're right in one aspect, however, I haven't elaborated enough.

There are tens of factors which affect the fixed-wing aircraft modelling, but let's do a simple as an axe calucaltion with two factors:
1.Drag. It consists of three parts: induced drag, form drag and wave drag. For the purpose of our discussion, we're limited to first two, as wave drag is insignificant at speeds lower than 0.7M.
Formula for drag is here: http://upload.wikimedia.org/math/9/9/a/99a6015b6a230860c9b1517b238e5de9.png
Fixing all the components except velocity, we get the following: F_D = (Cfx + Cix)*(v^2) (Cfx and Cix are normalized drag coefficients, assuming constant height, same body, etc. Cfx is form drag, Cix is induced drag)
2.Lift, in the same way can be expressed as F_L = Cy * v^2.

Cy and Cix are functions of Angle of Attack; Cfx can be assumed roughly constant.

Then, if we're taking one aircraft and starting to increase its speed (from 200 to 300 kph), what happens is:
1.To maintain the same amount of lift, angle of attack must be reduced so that F_L remains the same (because the weight of the aircraft is roughly constant)
2.Reducing AoA leads to reduction in Cix. How much exactly depends on many factors, but roughly (in our condition), it is reduced proportionally to inverse fourth degree of speed. Let's assume it doesn't change (for now, you'll see why later). However, due to v increasing, overall drag (F_D) still increases. Given our assumption, it increases almost quadratically (to become (3/2)^2 = 2.25 times larger). This means that the thrust the engine must be exerting is 2.25 times more.

Which basically gives us the engine which (assuming the worst case - same T/W ratio) needs to be 2.25 times heavier. However, since engine weight is (usually) a minor part the weight of the aircraft, this increase is more-or-less balanced by the Cix reduction. If you're not comfortable with equation convergence, you can assume the total weight of the aircraft stays the same and the heavier engine is accomodated by the expense of some fuel.

Hence, what we get is that all we need to account for are increased requirements for materials to handle the load and increased fuel consumption. First problem was successfully solved in WW2 time (see, again, P-51), second problem is a simple tradeoff - either you have good loitering time, or you have good speed. Not both. Seems like Greyhawk constructors sacrificed some of the latter for the former.

So, let's put it this way: I've already accounted for all the factors you've named and some you didn't ever hear of, that's why I said you're wrong ;) In real life it is not that simple, of course, but, as I wanted to show, you don't possess the qualifications to tell whether something will fly or not. You'll need something better for that than just characteristics comparison and "common sense".

You're wrong.

Hint: "I feel it should be so" has nothing to do with physics.

Except, again, the Greyhawk is not the Predator. I wasn't even referring to 2035, by the way. This kind of UAV is entirely possible now, with all the characteristics. Where is "magic"?

There's no fundamental aerodynamic difference between UAV and a piloted plane.

:D
P-51 is a propeller-driven plane. It has max speed of 700+ kph
http://en.wikipedia.org/wiki/North_American_P-51_Mustang

Why do you think it will have same characteristics as the Predator? It will not...

Can't reproduce - both dev and stable build. Locks normally.

Have you recently changed your settings to default? Try T key.

I'm not arguing for the sake of arguing or because I don't want to be wrong.

You're doing exactly that, Killzone_Kid ;) Sometimes it is better to admit your mistake than keeping arguing because of fear to look stupid...
Which is exactly what happens when you ignore direct questions ;)

They are ENEMY camo nets. AI will shoot them until they are destroyed it is logical. Why they dont get destroyed sooner is another question.

Again, will YOU be shooting at empty camo net?

@Killzone_Kid, so you're shooting at a camo net with everything you have? Every time you see it?

@rogerx: yes, compiling requires Windows SDK installed, DirectX SDK is part of it now. I haven't tested compilation with anything but Visual Studio 2013. I'd say it should be compilable with anything recent enough, though (C++11 features used)
You're welcome to try it - source is available at https://gist.github.com/DarkWanderer/3ac07a213bfc8a02932d I intentionally packed everything into single file, to allow those wanting to try it but not risking downloading .exe's to give it a shot.

Let me know if it works for you.

If someone could launch the test utility by the link above on Win7 and/or win 10, that would help to confirm or reject my theory.

It's not a segfault. It's that a function asked to allocate a piece of memory (malloc or VirtualAlloc or similar) cannot do so, and somewhere in the chain of calls this situation is handled incorrectly - specifically in Win8.

There was no answer so far from BI on the investigation results I have provided, don't know if that issue was abandoned or still worked on.

Speaking of code size, it's actually not so big - see the piece of code I gave a link to above. Listing DirectInput devices only takes around 20 lines.

And as for TrackIR issue, TrackIr is detected via separate mechanics, so no one forbids to keep it detected every time you open controls but detect joysticks only once on start - win-win for everyone.

Turns out there's a difference in behavior when launching application under debugger, even in Release configuration (as I did when launching it locally). This resulted in the test not reproducing the issue in some cases where it should.

Updated the test utility accordingly and added some more output. Available at the same link (http://1drv.ms/1DQ5ptA). Let me know what it shows for you now.

@rogerx: problem is, BI can't fix it. It's a DirectX or Windows issue. They can only workaround it, that's why I suggested the workaround.

Can someone test that exe file by the link above on win10 machine, please?

@oukej: You're welcome, it's an honor to help.

you can, for example, add a command-line switch - "-noControllerChangeDetection", that'll both workaround the issue and preserve the functionality. Just an idea.

Guys, I have reproduced this issue successfully in a C++ console app. It's a DirectX memory-related issue. Basically, once you have used enough memory in your application, DirectX functions stop reporting ANY devices to the game. TrackIR is detected differently, I suppose, so it stays; but the game can't query for controllers anymore.

Here is a small executable to test (run with joystick attached; WARNING! You're downloading an executable file, do it at your own risk):
http://1drv.ms/1DQ5ptA
Source of that program:
https://gist.github.com/DarkWanderer/3ac07a213bfc8a02932d

I don't know why it is specific for Win 8, but it looks like an "endemic" DirectX problem indeed.

I suppose the only workaround would be to not query for devices when opening options - either optionally, or as a change to default behavior.

@oukej: sent a response... I've successfully reproduced the effect in a test console app, it looks like it is a memory allocation issue affecting DirectInput. Details in reply PM.

Possible workarounds on player side:
1.Start with a low value of MaxMem, say 512 or 768 (can someone please test if it helps?)
2.Use Stratis to perform test flights and assign the keys

Hi oukej,
What's the API function you're using to query for joysticks?

Still an issue as of 1.07

He (JohnnieConcrete) is just a fat troll :)
"AMP needs to go to 11" is an old internet meme: http://knowyourmeme.com/memes/these-go-to-11-spinal-tap
He should be banned.

@OMAC: can you also remove the part about "player as gunner", please? This issue can be reproduced in other ways (example: starting as pilot, then switching seats).

It happens with every vehicle which has optics; also, this causes the player to have a "turned out" view in armor while actually being turned in, because the driver "optics" are inaccessible.

I suggest to rename the ticket (put "every vehicle")

I use flares in a more tactical way just like real pilots do

Can we have tickets without this elitist attitude, please?

I'd suggest adding not only single mode, but one more burst mode. Like 2 ("single" mode), 8 and 32 flares. This will allow a compromise between need to slam the countermeasures button wildly and excess flare spending.

1. Not enough thrust. Turning at full throttle will cause your plane to loose all your speed and you will fall. Maybe it should not be able (or pilot will not be able to handle) going hard turn at 700 km/h. However at 300 km/h any jet will be able to keep a steady speed, if not trying to accelerate while full throttle is applied.

Nothing wrong here, btw. This aircraft has very low T/W - it's not a fighter. Turning at max available G will bleed your energy at any speed.

(IF YOU HAVE AN OPINION PLEASE LEAVE A COMMENT)

Opinion: these should be 7 separate issues. This will help developers much more.

Probably a dupe of #0014639, but not sure - at least related. I'll keep them both for now, unless confirmed otherwise.

Certainly not a duplicate - #14639 (= #12851) is questionable.
This issue, OTOH, can be fixed separately by fixing the Respawn module.

@ProGamer: can you please correct the title? Now it basically reads "In the game, clouds DO NOT show as sphere, but they should be".

Fixed in release.

Should mission maker also add sounds for the sea and for all the vehicles?

Seagull sounds/crickets/dogs/etc. can be present and can be not, dependent on weather and other factors (including mission maker mood). Wind turbines must always have sound, if they are spinning. It's the same as those oil pumps on Takistan.

That's "Virtual Ammobox System" problem, not ArmA 3

Ticket title is confusing - should be "Shadows shouldn't be totally disabled" or "Shadows can be totally disabled"
Now it looks like shadows can't be disabled now and it's a bug :)

Well, what sense is there in adding this button if half of the players (those playing on Elite) will not be able to use it? :) And what sense it is to break the huge part of the game for those players by enabling this "by default"?

Example: there's a nice mission in Steam Workshop about downed pilot - player doesn't have GPS, so it's all about navigating "by hand" first alone, then with team members. Adding such button will break the gameplay in this mission immediately (if playing on Elite/Veteran, that is)

you should be able to report your coordinates if you have a map...

Yes, YOU should be able to report, not a magic button instead of you.

Currently a large portion of realism play (without GPS) is map orientation - where you have to remember where you was and where you were going to determine your position. If the player would be able to arbitrarily say his position in chat, it will be an instant GPS cheat.

I agree with you in principle - that those requests without response are annoying - but that will be a tradeoff between a small feature and a huge exploit.

There are missions and events where this is actually played on (example: Russian WoG)

I think this was removed to prevent an exploit of knowing your position without GPS. More realistic as it is, actually.

The machines are avenging fallen comrades :P +1

Implementing the ticket as it is will be harmful, because sometimes you need to move slightly while staying in adjusted position (see "slicing the pie" technique).

I think, stance should reset, BUT only for movement in tactical pace (with lowered weapon) and for sprinting. Sometimes you just need to abandon current position and run. In this situation, having the player stay with his adjusted position is harmful.

So, we have two types of movement:

• Firing position movements - when you adjust your stances and/or position, while remaining ready to fire. For this type adjusted stance should be preserved
• Position change - for this type adjusted stance would be harmful.

On a side note, for those of you wanting more control over all the stances I recommend to remap the keys as follows:
1.Z = Prone (NOT toggle)
2.X = Crouch (NOT toggle)
3.C = Stand (NOT toggle)
This way, when pressing Z/X/C you will end up in a desired default stance with no adjustments.

Hi, B00tsy. You can close the ticket yourself (see 3 buttons below "Attached files" section)

Well, looks like it's fixed in the latest devbranch. All missions are now cached and updated in background.

I understand what you are saying. What I am saying is this is a virtual environment. It is possible to have the runway on the actual heading of 200 instead of 195. Why would you not want that?

Because having imperfect stuff is pretty much realistic? :P Besides, I bet it's the same on the real island.

Now #12529 has one more :) Please close this one, then.

Still actual, version 1.03.

duplicate (of): #13152

if an empty UAV spawns which is of the opposing faction, then whatever actions triggered the reward of the spawn become pointless.

That's a problem of mission designer, not game design. It's pretty simple to edit scripts which are reponsible for reward creation:

if(getNumber(configFile >> "CfgVehicles" >> typeof _vehicle >> "isUav")==1) then { createVehicleCrew _vehicle; };

I think the ticket is non-issue. Current logic is good enough, if you use it correctly.

Here's an example of an airsoft replica ACOG sight at night:
http://home.earthlink.net/~pubftp/acog.jpg
HOWEVER, real sight also possesses this capability:
http://www.opticsplanet.com/trijicon-acog-3-5x35-scope-dual-illuminated-crosshair-223-ballistic-reticle-w-ta51-mo.html
http://www.trijicon.com/na_en/assets/image/ACOG-Features2.jpg
http://www.trijicon.com/na_en/products/product1.php?id=ACOG

It looks like MRCO's reticle is similar to this:
http://www.trijicon.com/na_en/products/product3.php?pid=TA31-D-100194
The part up from 500m mark should be illuminated.

Can't be reproduced for me, and that's certainly not ArmA 3 bug. It may be a bug in Steam (i.e. you should write to their support), but most likely it's a problem with your drivers or hard drive.

Can you perform a full drive check with sector scan?
(chkdsk C: /F /R /X, repeat for every drive. will take a few hours)

Reproduction steps?

Observed this in MP recently. Issue is also reproducable if the player joins the slot previously occupied by someone else.

Gets to ridiculous levels. See screenshot:
http://cloud-2.steampowered.com/ugc/919023475302758498/B18403B47505EB3BCF04C5E32F7B4FA257B72F96/
Basically, the optics become non-transparent - and look like cheap plastic instead of glass. Needs fix ASAP.

<nitpick>
yawn: to open the mouth wide and take a deep breath usually as an involuntary reaction to fatigue or boredom
yaw: the action of yawing; especially : a side to side movement
</nitpick>
Sorry, couldn't resist after imagining a yawning helicopter :) upvoted.

The night sky does not look that way, really. Even far from cities, all you can see with naked eye is a number of stars. These pictures are created using false-color, huge light intensification, long exposure times, etc.
(nebulae are actually seen by naked eye, but as dots, not as large objects)

Well, yeah, you can see Milky way from rural area with no towns around on a moonless night, but is it worth implementing?

Still actual as of latest build.

Turns out it's a duplicate of #4774. Please close.

#8528

Duplicate of #1533

How about pretending USMC changed their minds in 2035? :)

@ThePredator: Was it an attempt to offend me? If it was, sorry, it was too plain dumb.

People who use "it's not CoD" argument like a club to clobber whatever they do not like are not better than any game fans, in fact. Even worse, actually - they have this false sense of excellence "because they play a milsim".

IRL suppressors aka silencers are assumed to give 20 to 30 decibel reduction of peak sound pressure. This means 100 to 1000 times decrease in peak levels. Give me a solid data proving otherwise or screw off.

You've misread the ticket. It's not about names. It's about how by some twisted logic wrong name means wrong sound levels.

Whatever you call it - the ticket is not legit unless proof is provided in the form:
Ingame suppressor - Real life counterpart - Ingame sound reduction - Real sound reduction.

You want to get it real - do some real job, not some ArmA vs. some abstract "casual shooter" comparison.

Point is, the term is coined. Soldiers are calling M4 a "rifle" and a "gun", even though the correct technical term is "automatic carbine" (which is also arguable). And the fact that some people do call the device "silencer" and some do not, does not change the fact that it has a pretty fixed and determinable sound reduction - in the range of 15-30db. Alas, being anal about some word won't change the facts. Is there proof that the sound reduction in the game is i.e. 40db instead of 20?

Back up your words when talking. The word is widely used, within military as well. It's what they call "colloquially known as".

U.S. ATF calls them "silencers": http://www.atf.gov/firearms/faq/national-firearms-act-silencers.html

See:
http://www.youtube.com/watch?v=ug76TCVsvrA at 0:24
http://www.youtube.com/watch?v=QijetGUlJ4A
http://www.youtube.com/watch?v=7ayGr7bWIg0
http://www.youtube.com/watch?v=uYbx5H5e9Es at 0:48
http://www.youtube.com/watch?v=j-piEL58hsg at 0:38

Sorry to spoil the fun, guys, but OP is wrong and will be wrong. MadDogX, I didn't expect that you will fall for that.

New duplicate of this ticket: #15688

Then you must be so great as tools what world biggest airplane manufacturers use to model their planes, shows that the rotating axis is not middle of the helicopter body as you think, but above it below rotors.

Which tools? Screenshot, proof? Otherwise it's just talks.

I can not argue with you what you can even feel and see when you are in flying helicopter as it is against what you say.

"I feel it should be that way" is a great argument, no doubt. Unfortunately, feelings do change nothing here, it's pure physics.

I am back flying helicopter on next week and I must just be in other world as I can even feel instead just see that the middle of fuselag is not the turning axis as you claim.

Again, what you feel is not what you get.

You say you have played DCS:BS(2) but still you can not even in it see that what you say, is against it. In ARMA helicopters fly as you say, but on simulators and reality helicopters don't fly in that manner. Which one you want now to defend, ARMA or simulators and reality? As both can not be correct.

I don't defend any simulator. I'm saying you've got wrong assumptions. And in both simulators and in reality helicopter fly like they should - adhering to the physics I've described.

To add here, I am aware of laws of physics so you have nothing to add here.
But you fail here to apply those laws of physics to helicopter as you believe rotating wings behave exactly with same manner as fixed aircraft.

Nope, it's you who fails here. Because newtonian physics apply to any macroscopic body. It's not even aerodynamics, it's basic physics you fail at.

Different design, different flight model.

Different flight model, yes. Non-newtonian physics, no.

You claim that helicopter fuselag generates torque and thats why whole aircraft rotates around center of mass => Center of fuselag.

That's what you're saying, not me.

Tell what is wrong in this: http://i.imgur.com/NKF2TfA.png [^] (just imagine helicopter is not co-axial)

Do you think this picture proves me wrong? Nope.

ps. When you call someone manipulative troll, be careful as some people would find it very offensive. As you are one doing personal attacks like very experienced person on that area.

First of all, the first personal attack was yours. You claimed that I have no knowledge in the area.
Second, you are ascribing many wrong points to me - the ones which I never stated. This is pure and plain manipulation.
Third, yes, I do have quite good experience in modelling of mechanical processes and software development.

OMG...

I hope noone here will argue that physics is wrong? I truly hope so.

In mechanics, when you have a body, you have following parameters:

• body position (vector)
• body mass (scalar)
• body moments of inertia (second order tensor == 3x3 matrix)
• total force applied to the body
• total torque applied to the body

Both force and torque vectors are always applied to center of mass. The only exception is when the body is fixed with less than 6 degrees of freedom (i.e. on a hinge). With helicopters - this is not the case. They have full 6 DOF of motion.

Hence, when you have torque applied, in the reference frame fixed to the helicopter, it will always rotate around center of mass. Period. No other options possible. That's the basics of physics.

When the helicopter is moving, it may appear to a stationary observer that the body of the helicopter is rotating around some other point. For example, when performing funnel maneuver, the body of the helicopter will seem rotating around a vertical axis starting at the funnel focus. However, if we look from the helicopter's point of reference, the rotation will always be around CoM. Period. End of story. What you see is NOT what you get, unlike Microsoft Word.

And - surprise, surprise - aerodynamical forces and torques are just parts of the "total force" and "total torque" vectors. It may look as if it works otherwise - but it is not. It's all the same equations -
F = M*(dv/dt) (Second Newton's law, I hope you know at least as little as that)
T = I*(dL/dt) (torque equals inertia tensor multiplied by angular acceleration)

All the aerodynamical calculations are applied on top of that - to get the forces and torques. They are complex and different, yes. But when the aerodynamic stuff is done, Mr Newton takes the wheel - and all goes according to his laws.

Hence, Mr. Fri13, yes, I compare my physics background and experience in aerodynamic modelling to your ostensibly hardly finished high school physics. Surprise again - all macroscopic bodies comply to the same newtonian physics, be they helicopters, planes, or anything else. ISS motion is described by the same equations that apply to a bowling ball, WWI fighter, WWII fighter, modern fighter, ballistic physics, basketball, volleyball, gyroscopes, mechanical clock, lawnmovers, parachutists, skateboards and policemen.

And for the reference: yes, I've played DCS: Black Shark, Lock On series, Falcon 4 (plain and AF) and Orbiter space sim. I've also developed a couple of addons for Orbiter. In RoF, I've worked on physics of the Fokker triplane - there, we had some problems with actually making the thing fly like IRL - because NACA wing profile data does not give any information regarding the interactions of three closely-placed wings.

In all of these simulators, the model I've described is in the base of everything (except some scripted spins in Falcon 4 and Lock On). You can ask developers of any of those sims - or you can ask BIS developers. They've done good job with the TKOH flight model. Obviously, the answer that it's the same good ol' physics will surprise you.

Don't tell me *I* don't know physics.

EDIT: Damn it, I've fell to a manipulative troll. Shame on me.
Good job, Mr. Fri13. I hope your pimpled personality feels much better now.

My "opinion" is based on physics knowledge and experience in working on aerodynamics in Rise of Flight project (http://riseofflight.com/en). This experience tells me physics better describe what's actually happening with an aircraft than a layman's senses. Clear?

Uh-huh. If you're saying sun is not a teapot - prove it.

What you're requesting here is against the basic physics (okay, not basic... http://en.wikipedia.org/wiki/Theoretical_Mechanics, actually). You should prove it, not me.

Hint: the torque (rotational force) is always applied relative to the center of mass.

Nope, it's just the camera in these games may be fixed slightly higher w.r.t. the chopper frame, than in ArmA 3 :) The helicopter still rotates around enter of mass.

Why?
When torque from the rotor is applied, the helicopter is rotated around the center of mass, not some artificial point "below the rotors". That's base physics.
And the center of mass certainly can't be so high, the current position is actually a pretty good representation.

Well... As I've already said, I'm wrong in some respects, but in some you, guys, are also not right.

First of all, I agree, I was wrong about the videos explanation - I already said that above. I was also wrong about the NV gear wavelength sensitivity - multiple sites say that it operates around 1000nm, but, as it goes from more scientific sources, it's more of 700-900nm.

HOWEVER, you guys are wrong about the masers and all that.
Here are three links:
http://electronicstechnician.tpub.com/12419/css/12419_26.htm
http://www.northropgrumman.com/Capabilities/SOFLAM/Documents/soflam.pdf
http://www.globalsecurity.org/military/systems/ground/an-peq1.htm
They all explicitly state that SOFLAM's operating wavelength is 1064 nm, not 1000 micrometers. Also, see the characteristics of Nd:YAG laser: http://en.wikipedia.org/wiki/Nd:YAG_laser

Nd:YAG lasers typically emit light with a wavelength of 1064 nm, in the infrared.[3] However, there are also transitions near 940, 1120, 1320, and 1440 nm.

Nowhere near millimeter range. There's no and could never be a laser that can emit a microwave pulse.

And point three - no, smartphones can actually detect fairly long wavelength - because a smartphone camera is essentially a bare CMOS sensor with a very thin layer of glass or plastic onto it. CMOS are sensitive enough to pick 1100nm+ radiation - see https://www.google.ru/search?q=cmos+wavelength+sensitivity&um=1
Again, try this at home - by your logic 940nm used in TV remotes would not be detectable. But they are.

That's not to say I was right about the initial premise - for this reason I'm closing the issue. But this is because I don't have any proof that any NV devices currently in service can detect such lasers, not because "they'd be spotted!!!" :)

I guess, you should tone down a little, shouldn't you?
You're still wrong about 1000 micrometers. That won't change.

Okay, I must actually admit I can't really back my position here.
The point on lighting up a target with a weapon IR pointer does actually explain a lot in the videos. It's also possible that on the original video I was referring to a separate IR laser attachment was connected to the SOFLAM for whatever reason - I vaguely remember it being about some tests/training. So, I take my words back - I may be wrong here. I'll do additional research.

That said, "enemies can spot the source" is still a weak argument ;)

What you're saying is cool, but you're still wrong.

First, regarding the detection - why do you think modern armies use IR laser pointers? They are visible to any opponent wearing NVGs, so anyone using it is a target.
The answer is asymmetric warfare. Such things are reserved for lasing targets at day, when noone's wearing NVGs, or against targets which do not possess it. There was no conflict where both sides were technically advanced recently...

Second, you're confusing "optimal" and "still visible" wavelength for camera. There's a long "falloff" curve in sensitivity vs. wavelength graph of every camera.
See the following video:
https://www.youtube.com/watch?v=xDktGyCG5Eo
Even cheap handheld digital camera captures 1064nm, BUT very dimly.

That's why you're wrong on your point about blinding - it won't blind you, because it will be barely visible. It's gonna be on the edge of the detectable range, but still inside it. It was outside for Gen 2 and Gen 3 devices (proof: http://www.gamma-sci.com/wp-content/uploads/2012/06/Measuring-Spectral-Performance-of-Night-Vision-Devices-ANVIS-Gamma-Scientific.pdf), but Gen 4 (which' characterestics are classified at the moment) certainly do pick it up.

How do I know? Watch other videos.
There's a clearly visible laser from the helicopter guiding the missiles. And AH-64's and AH-1's use same Nd:YAG laser with 1064nm wavelength - hence, if you see it, you'll be able to see SOFLAM's laser.
Proof:
http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA392484
Video of Apache attack captured through NV:
https://www.youtube.com/watch?v=-LIZJ2W86oc

So nope, your smartarseness is wasted ;) I actually saw the video with SOFLAM being shown which emitted a beam fairly visible in NV. Problem is, I can't find it now - but I wouldn't be arguing if I didn't see it.

First, the fact that it's pulsed won't mean it won't be visible - CRT screens were also "pulsed". Pulses are very short and frequent (see datasheets).
Second, it's 1000 nanometers, not micrometers. 1000 micrometers is one millimeter - that's gonna be a maser (http://en.wikipedia.org/wiki/Maser), not laser.
Third, 1 micrometer is in range of thermal radiation, hence it would be picked up by thermal
Fourth, the standard commercial NV cameras capture the range up to 1200-1500 nanometers with ease. Example: http://www.cam-it.org/index.php?topic=2286.0 - 920 nm is considered optimum. For military-grade stuff, that certainly will also be true.

And fifth - watch that: https://www.youtube.com/watch?v=6gSW33R8UCM
If you look around for more videos, you'll note, that helicopter lasers are also visible in NV IRL. So, that's also a thing to fix.

EDIT: Sixth: try picking up your smartphone and direct a TV remote into its camera, while pressing a button. You'll see purple glow invisible to the eye - because smartphone's camera is picking it. And that's 940nm - pretty close to the 1000nm used in SOFLAM.
https://www.youtube.com/watch?v=nEBX4_SzEwg

Hahaha, sorry, copy-paste went wrong. Meant #10616

Seems like the "magic guidance system" has already been reported: #12272

Foxhound_USSR: Titan IS actually a homing missile. There's a big optic dome at the front end (you can see it in launcher).

What InstaGoat says is a big bug, though, if it reproduces. Will try later.

@Smurf:

Downvoted because of wording? lol

I have voted it up, but I'm pretty sure most of downvotes came because of "Immersion asdasd". Gotta respect those who are to vote for your idea.

Smurf, can you please update the description to be... a little bit more serious? I'd like to see the feature as well, but right now I'd downvote your ticket myself because of wording.

The ticket is perfectly valid (it addresses the specific problem), the linked one is too broad.

I believe you meant pivot. "Pivo" means "beer" in both Russian and Chezh :P

+1 for the video showing the bug

I'd want to have a few additional variants AH-99 with attached wings and more armanent.

<devil's advocate>It may be used for some internal mechanics, so disabling it may not be possible that easy</devil's advocate>

But an important thing to be done, indeed.

Good description - great job... Unfortunately, #10143 was posted earlied :/

+1 for another slot.

@InstaGoat: maybe you can change the ticket description/title?

Duplicate of #9193

Your problem can be solved easier...
{_x moveInCargo heli} foreach units group this;
Place this in init of any unit of the group.

Latest dev build, confirmed

Same issue: #11583 (for the sake of continuity)

@FeralCircus:
It's you who are saying, citation:

"But it would benefit us who play much larger scale missions with a very high draw distance."

This exact phrase is not true by any account, because viewdistance can't be made more than 10km from the ingame menus now. There's no "us" you're talking about.

And why would I request something that my PC couldn't handle? lol

See above - you are requesting exactly it. At 10km viedistance the effects are absolutely negligible, even more so at 200m-1km (typical engagement ranges). And rest assured, I'm certain you have your viewdistance capped at 2-2.5km. What are you requesting then?

Anyway...
Depending on which direction and location the shooter is aiming and standing on earth, The Coriolis effect can significantly affect rounds at distances as little as 1000 yards (914.4m)
Simply changing direction from East to West to a target of equal distance & altitude would require different scope zeroing due to the curvature & rotation of earth.

Wind effects are much more apparent in magnitude for shooting. Example:
Coriolis effect: 3 inches (8cm) at 1km http://www.straightdope.com/columns/read/2944/how-does-the-earths-rotation-affect-the-path-of-a-bullet
Wind effect: 56ft (17 meters) at half a mile (800m): http://www.thesun.co.uk/sol/homepage/news/article158181.ece

Hence, wind effects are required to be implemented before going into Coriolis "force" effects, air density effects, rain/dust effects etc.

First, what I'm saying is that here's a request for a feature which is not backed by any justifiable reasons. I've provided counter-arguments on each and every one - please care to re-check.

Second, there are things which do not work in humanitarian way - "everyone's opinion must be respected", blah, blah, blah. In the technical world, statement is either right or wrong. Your statements are wrong - as I've shown. And what did you expect, to put some statements and for everyone agree to them because it's "friendly way"? This is a textbook fallacy known as http://en.wikipedia.org/wiki/Groupthink No good things ever come out of it.

Third, there's little point in being "friendly" if you don't respect the person you're talking to by listening to what he's saying. Please take your time to read through my posts and understand that I'm not in the "argument" for the sake of argument, or dominating someone, or boosting my ego, or whatever. I'm in it just for the truth(tm). This thing is nasty, and it can't be bent by juggling words ;)

And to go through it again:
1.It adds realistic bullet behaviour - false, without wind effects it's not adding any value
2.It adds realistic horizon visibility - false, noone will ever see it due to viewdistance limit
3.It will waste no resources - false, a lot of developer time will be spent on that
4.It will allow modders to create planets - false. It's impossible to create a planet size map with the detalization necessary for infantry sim. Full X-Plane maps take how much? 50Gb? And they are basically just textures with barely any objects on grand scale.

Get real, guys.

No, it will change one thing... BIS would spend a lot of time which is better spent on much more pressing issues.

If such changes are implemented in some other title like TKOH or TOM and simply merged to A3 - fine. But now, there are features like bullet-in-chamber accounting (just one example) which are much more beneficial to realism.

And... Before telling about some mytical "us", show me a screenshot of your game having 50km viewdistance and decent FPS. Otherwise, you're just talking dreams...

I can see that 50% get this and 50% don't.

Yeah, 50% of people are not getting it, but it's the other 50% from what you think ;)

Such effects are no doubt realistic, but they are well beyond the scale of ArmA simulation. Even air combat simulations like Lock On and Falcon 4 don't use such simulation - and they have roughly 100 times the typical action scale distance of ArmA.

It's the same as asking to implement relativity in ArmA - while no doubt realitic, the effect is actually indistinguishable from floating point rounding errors at such velocity scale.

Keeping things on a flat plane reduces a lot of unnecessary calculations. That being said, if the maps of Altis and Stratis were to be combined into a gigantic 600 km^2 region

600 km^2 is just 20 by 30 km. The length of one degree on equator is 111 km. Basically, it means the whole island is just a speck on the Earth's curve - one-third of a degree. The effect of curvature is practically negligible.
(if you want to nitpick - if you're looking at another point on the ground d=30km from you, it will be same d/R = 30km/6400km = third of a degree higher if using flat modelling than if using spherical model. 30km are unachievable in ArmA engine).

i dont say this thing is easy to do or REALLY useful, but it has to be accounted for being useful in big scale battles, and if they add realistic flight simulation of planes, for this last reason too.

I can safely say in both ArmA 3 and ArmA 4 will be never such large scale battles as to span more than 200km (approx. two degrees of latitude). Hence, it's just a tremendous waste of resources on a feature 99.5% of people would never notice.