ShuRugal

If that were true, then you have just committed spillage by posting information contained in a classified document on a public web forum.

This is a good simplification, and is the one I always use when explaining to non-aviation-minded folks. A more technically correct explanation is that the ground also interferes with the formation of wingtip vorticies, drastically reducing their size as clearance from the ground decreases, and therefore reducing induced drag.

erm, not quite. it's three times the velocity, but that does not mean 3x the power. At loaded weight of 21,000 lbs, the rotors are producing 21,000 lbf of thrust to hover. If thee power output tripled, they would be producing 62,000 lbs, which would accelerate the helicopter upwards at 3G (29.4 m/s/s)

hmm, maybe they could add an expansion to take the input from a USB scale, and then use that info to apply G-effects to the virtual pilot based on actual load the chair pilot would experience, rather than relying solely on relative load of G-force?

so, regardless of whether or not the FD is engaged, the AP will get the pilot wet?

the autopilot has only 20% control authority. If you want the AP to maintain a precise radar altitude in mountainous terrain, you will need to set a very slow forward speed. The autopilot in this helicopter is NOT like the autopilot in an Airbus: You cannot simply set it and walk away, you must still fly the helicopter. The AP in the KA-50 is ONLY intended to ASSIST the pilot so that he may spare some attention to searching outside the cockpit and manipulating the targeting/weapons systems.

Hallelujah!

This might sound like a silly question, but what is your graphics card/processor vendor, and are your drivers up to date? I do NOT see any frame rate loss when killing things with my shkval on them and I'm playing on a laptop (I7 processor, GTX 780M). My frames have been pegged at my v-synch cap since 1.5 dropped.

I know that the PVI-800 does not store elevation data, so when entering a target point, the shkval will point at sea-level. I am not 100% certain, but I believe that the same applies to targets shared over datalink: only lat/long and target type is communicated.

ah, so the first three are supposed to go directly backwards in the event of mission failure. Makes sense now.

your image is broken, it says i need permission to view. Also, I have failed both the 1st and 2nd missions. first mission failure has me play first mission again, second mission drops me back to first. Does not seem to be progressing on to "failure" missions.

Hey, I've been having a problem wherein the campaign reverts to the previous mission on failure instead of re-playing the failed mission. I can understand jumping to a different mission, wherein your failure has had Bad Effects on your side of the campaign, but dropping back to the previous mission is just annoying. Is this something we could get patched, or am I going to need to fix it myself?

you may find chapter three of FM3-04.126 to be instructive...

From a theoretical standpoint, your only issue should be loading times. To make compatibility less of a problem, I would create a folder shortcut for it on your local drive (IE: C:\games\DCS or whatever) that points to the desired location on your NAS. If you do this, then as far as windows (and therefore the game) is concerned, you have installed the game onto your C:\ drive. The only issue should be loading times.

the "stop engine" command does not kill the engine, nor does the "start engine" command start the engine. A jet engine is not like a car engine. You, the pilot, have little to zero direct control over the operation of the engine in anything approaching a modern jet aircraft. The ADEC or FADEC receives your commands, interprets your intent, and then does what is needed to get the engine to operate as commanded. What you are describing is a result of the F/ADEC seeing the engines die due to a drop in fuel pressure, and subsequently re-starting when fuel is available. The F/ADEC has no way of determining that the fuel simply ran out (it probably isn't even programmed to consider that a possibility). For all it knows, you had been performing sustained inverted maneuvers, which starved the fuel pumps. Since this likely -is- a programmed failure mode, the F/ADEC assumes that you wish to be able to fly your plane when you turn it back up the right way, and it re-starts the engines when it sees fuel pressure in the lines.

just make sure to throttle down and kill engines after a deadstick landing. This would be the correct way of doing it IRL as well. ECU doesn't care -why- the engine shut down, if it sees commands that tell it to attempt restart, it will...

LUA files need not be changed in order to change missile behavior. If they change how the backend handles missile dynamics, then the results will change with the same missiles.lua entries.

move on Guy's what? Onto which things belonging to Guy shall we move?

sounds like the AMRAAM has been getting some flight-model love?

So, i've just noticed that Evochron: Legacy recognizes the ministick on my X55 throttle as a pair of usable input axiis. Is there any way to get DCS to do the same?

I don't get it. The missile tracked. How is that worse than a missile that didn't track?

Split-S and release at -90 degrees...

Yes. Enough to cause my missiles to miss (by about 60 degrees divergence) from under 20km Blows that theory, then.

@GGTharos: On the note of this bit here, I noticed something last night that had never happened to me before. I was flying on a server with a fair amount of AI traffic, and I had an AI F-15 exhibit this behavior. I had always been under the impression that this particular gremlin was a result of the server receiving bad position data from a particular client, and then passing that bad data on to another client. Now, it would make equal sense that the server could send me good position data, but it gets banged up in transit and so i receive a bad contact... but there is one other piece that bothered me: I had engaged several other AI craft (drones and transports) and none of them so much as twitched. Is this only a bug that is possible with PFM (or whatever the acronym is this week) airframes? Is the bug not actually caused by bad positional data between client and server, but bad positional calculating of PFM craft by the server? Also, how difficult (from a technical standpoint) would it be to add a sanity check to position data? At the very least, the client and server should be smart enough to reject movements which are physically impossible, even if it can't be made to distinguish the merely improbable.

Easy enough to add a condition to missions that requires the bird to be parked in a designated spot on the runway to flip the final bit for completion. Forcing ATC compliance is more difficult. IRL, pilots have administrative action taken against them for violating ATC instructions when in controlled airspace. No real way to implement that here, as the sim does not have any RPG-elements built in.