Fishbreath

I've been looking forward to this one.

I haven't been able to make that work in the mission editor since I bought FC3 (on September 20th). The ground-based radars neither light up my RWR nor put contacts on the HDD.

Three Su-33 questions: 1. In refueling mode, the Su-33 HUD shows my speed in IAS and the target speed (i.e. tanker speed) in TAS. Is this intentional? 2. In a multiplayer mission, I have two client Su-33s set to takeoff from runway on Kuznetsov. They either spawn on top of each other (when I shut my engines down, and therefore left 'launch position'), or won't spawn at the same time (if I'm in 'launch position'). Is there any way to start two client aircraft on the carrier at the same time? 3. When landing and taking off again, is it necessary to press 'U' to get into launch position/raise the jet blast deflector?

More collective/pitch authority would make it easier to use the radar altimeter altitude hold as poor man's terrain following, at least.

It surprised me so much the first time I saw it I thought I'd been hit. :P

Multiplayer missions have aircraft slots—you select it and start on the ramp, on the runway, or in the air, however the mission designer set it up. Whenever someone gets shot down or leaves from a slot, the slot goes back to its original location. Multiplayer's definitely a riot, especially if you have a friend or two to fly your wing.

The sales on the ED website seem to be based on Moscow time: this one started at 4:00pm Eastern on September 19th (i.e. 00:01 Moscow).

I'm perhaps slightly leaning toward 'bug'. I have a shooting range mission I play around with, with targets to the west of Mozdok. The ground there is very flat, and the elevation is only 200m or so. Sometimes, after taking a laser range, panning the Shkval nearer to my helicopter will cause the range to increase at the same rate as panning it away. I can't really think of a sane range estimation algorithm which would do that.

In my effort to get to know the Su-33 fully, I tried a nighttime stormy landing. Highlights: Kuznetsov's ATC tells me to go to my alternate. Highlight not shown: me smacking into the back of the carrier on my first try. :P WQWQrS3spK0

I don't think that the fast movers have ripple interval/quantity modeled.

Without center trimmer mode on, you have about a second (?) to re-center your physical controls before they're unlocked. I prefer that in the Huey, but I use center trimmer mode for the Shark.

...the Su-33 is the first airplane I've ever successfully hit a tanker with, so I just have to share a picture.

I'll try one more time before I give up, just in case I still haven't made myself understood (and it's probably my fault :P). First, read this, which is a handy explanation of three components in typical autopilots. A proportional correction algorithm is, it seems to me, the primary mechanism in the Ka-50's autopilot: in hold mode, the amount of control input the autopilot uses is directly proportional to the amount of error from the reference attitude. The error from the reference attitude does not increase when you're holding a fixed attitude offset from the reference attitude, and so the maximum permitted autopilot inputs also do not increase. (It may ramp up to the maximum permitted autopilot inputs for a given error, but I haven't had much Ka-50 stick time in the last few weeks.) The autopilot only has 20% input, and the pilot has 100% input. It's probably a design feature, not a bug, that the pilot has enough input to override the hold autopilot, both so that the pilot can offset around a trimmed setting (for landing or slight turns for weapons employment) and for safety reasons as Flagrum suggested. The autopilot is still responding proportionally in route or hover mode, but the error is different. When you hold a fixed attitude away from the attitude the autopilot chooses, the error increases, because the reference position is a speed and heading. As you hold the nose down, the speed increases and the offset from the reference position increases. As such, the autopilot's proportional response grows larger. It appears that the autopilot is responding with an integral correction, because you're holding a constant control input and the autopilot control input is increasing, but this is only an illusion. The autopilot is responding to the error, which is the integral of the attitude error your control inputs are producing. Saying 'it's bugged' or 'it's wrong' is getting into saying how the autopilot should be, and that's not productive. I seriously doubt this is a DCS bug, and I haven't seen any evidence to suggest that my explanation for the autopilot is incorrect, whether or not you like it. :P The Ka-50 isn't fly-by-wire—the flight controls are attached directly to the rotor control servos, and the autopilot is also attached directly to the rotor control servos with authority to move them up to 20%. Actually, come to think of it, that's probably the answer to basically all of your concerns, and the reason why there's no auto-trim mode: the pilot's controls and the autopilot both go directly to the rotors without talking to each other, so the autopilot has no way of distinguishing pilot control inputs from other errors. You can do it with the Warthog software because you're (presumably?) using it to operate the trimmer, which serves to pause the autopilot so it isn't trying to correct pilot errors. Edit: for what it's worth, this has been a useful conversation for me, too. I had an instinctual mental model of the Ka-50's autopilot, but after this I have a formal model I can use to explain it to my Shark-flying friends.

No, but the definition of error does. In hold autopilot mode, the autopilot is holding a pitch, bank, and heading in relation to a horizon an infinite distance away. 'Error' is the difference between the current angles and the set angles. Since 3-5% control input only yields a very small error, the autopilot only makes a very small correction—less than the 3-5% you're inputting. In hover mode, the autopilot isn't holding angles as a primary consequence: it's holding a heading, a speed (zero), and a concrete position over the earth gleaned from the navigational systems. 'Error' means offsets from those things. If you're holding a five-degree bank against the hold autopilot, you're adding a fixed error. Your control input will only cause five degrees of bank. If you're holding a five-degree bank against the hover autopilot, you're adding a constantly-increasing error: every second you move a few meters further away from autopilot's set position. Because the error increases—not the angles, as in hold mode, but the distance from the hover position—the amount of control input the autopilot is programmed to use increases. As I touched on, that would have been a lot more expensive and a lot more complicated, and any flight control system that can fly a helicopter is already expensive and complicated. :P That said, it's definitely a great system when it can be done—the F-16's flight control system works a lot like that. When you stop making control inputs, it stabilizes there. It really takes a lot of the work out of flying. It makes me wonder whether the state of the art in helicopters has moved that direction—it would make the single-seat attack helicopter idea more viable. Edit: I want to further emphasize that I could be entirely wrong about everything I've said on the autopilot making proportional responses, and I wouldn't even be particularly surprised, given how complicated the Ka-50's flight control systems are (or perhaps 'must be'). The manner of operation I've described, however, does seem to me to be consistent with the way our Ka-50 works, so it's at least a useful approximation for someone. :P

I don't have any special knowledge, just a few hundred hours in the Ka-50. :P I'm not sure that what I'm describing is how the autopilot would work in an ideal world, or even how it actually works in the real world. To the best of my knowledge, though, I am describing how it does work in the DCS Ka-50. The goal in hold mode is simply to hold the desired attitude. Your definition of angles relative to the horizon will do. It depends on the nature of the change. Short-term changes are okay to do without the trimmer. When I'm in a hover or trimmed for slow flight for an attack, I'll frequently use the rudder pedals to move the Vikhr targeting cue without using the trimmer. I'll also trim for a near-hover before landing, and work the stick to put it down without trimming again. Some of that is because I don't have a force-feedback stick. If I did, I would use the trimmer even while landing, since with force feedback, hitting the trimmer would just reduce to zero the stick forces required to hold the current stick position. For changing pitch or bank longer-term, yes, I pretty much never move the stick without re-trimming. If I had force feedback, about the only time I'd ever make control inputs without trimming would be for yawing for the Vikhrs.

Sorry for the double post; there were some other things I wanted to respond to. Fly a little in flight director mode, then switch on hold mode. Compared to flight director mode, holding an attitude that isn't the one you've assigned is clearly 'fighting'. It doesn't stabilize itself. It never stabilizes on a new attitude without using the trimmer. The autopilot is still trying to return the helicopter to the set attitude, but it doesn't have sufficient control authority to do so. The sum of the control forces is the autopilot's stabilizing force subtracted from your stick force. Here's an experiment, actually: fly in trimmed autopilot mode. Turn on the Ctrl-Enter controls indicator. Push the nose down without trimming, and note where the cyclic indicator is. Center the controls and switch to flight director mode, then make control inputs such that the cyclic indicator is in the same place. You'll find that the same control inputs, given without fighting the autopilot, yield a much more aggressive maneuver.

It may be designed in a way you disagree with, but as far as I know, it's not bugged in the slightest. It's not 'choosing the wrong amount of authority', it's using the amount of authority required to achieve its goal in normal circumstances. Adding control inputs against the autopilot counts as abnormal circumstances, and there is no ordinary situation—by which I mean a situation you'd encounter while within the limits of the helicopter's flight envelope—where the autopilot would ever need to use as much control authority as it would need to to correct a pilot-induced error. Designing it to use the required amount of authority, up to its maximum, in any circumstances would be significantly harder. The autopilot would have to not only keep track of total error but also its past inputs, and be able to change its control inputs in an instant if the pilot releases the stick (or else it would overshoot and swing past the set point). It would also have to distinguish between error because of pilot-induced control inputs and error because of changes in the environment. The only thing a proportionally responding autopilot has to know is current deviation from the assigned settings. If you want it to behave that way, you can, as we've been over, use untasked route mode to fly around—because constant errors in attitude cause up to increasing errors in course and speed, it ramps up its responses as you add input. As it is, the trimmed autopilot is the way it is because it's much, much easier to design and implement, especially for a vehicle as complicated to control as a helicopter.

Yes, a small error is an error that the autopilot will correct. On the first paragraph, I'm afraid we're still talking past each other. I did just think of an example, though. Say you're landing the Su-25T (or anything with ILS). You notice that you're a little below the glideslope. You don't go to full throttle and full back stick to correct, however, even though you have that much control authority—you add a little throttle and a little bit of back stick. In other words, you elect to make a small correction, even though you have more control authority to use, because you're only correcting a small error. That's what the autopilot is doing. It will only use a small amount of control input to correct small errors—it has the nominal capability to use more authority, but its programming is such that it will never use it to correct errors below a certain size. When you introduce a small error with stick pressure, however, you're confusing the autopilot—your manual control input is greater than the amount of correction the autopilot is programmed to use for the size of the error you've induced. To make it more concrete, say you hold 10% controls against the autopilot, inducing a five-degree pitch error. (I'm just making up numbers, but it's not important for the answer here.) "Oh," the autopilot says, "I only need to use a 5% control input to correct for five degrees of pitch error." As you're ramping up to your 10% input for five degrees of pitch, it's ramping up to its 5% of input for five degrees of pitch. You'll always win. If the autopilot worked a little differently, ramping up its correction inputs to its maximum authority if the original correction inputs failed to bring the attitude back to the set point, it would behave like you're expecting.

In my experience, the autopilot will actively fight me in pitch (to maintain my set speed) as well as bank and yaw (more slowly, for whatever reason) while I'm in route mode. (Even if I'm remembering wrong, that's not necessarily an inconsistency—it might just be a Kamov design choice, or a design limitation.) It doesn't appear to be fighting in the standard trimmed mode because of the point below. No, I'm saying that the amount of input the autopilot will use to correct a difference from the set point depends on how big that difference is. A small error causes a small input from the autopilot, and a large error causes a larger one, but by the time you've reached a large error, you're pulling more than the autopilot's full authority anyway. Between route/hover modes and trimmed mode, the autopilot function is fundamentally different. Trimmed autopilot mode is counteracting errors from a defined correct attitude. Route mode is actively trying to hold a set of flight parameters, and errors in flight parameters are not the same as errors from a defined attitude. Flight parameters such as speed, heading, and altitude are the integrals of attitude changes, so holding a nose-down attitude or enough rudder to change course rapidly builds enough error for the autopilot to use its maximum authority.

In your example, route mode doesn't actively fight the pilot input because pitch has moved away from the datum—it fights the pilot input because speed has moved away from the set point. It's the same with roll/yaw and heading. As for the bouncing, Hunden Ynk seems to me to have the right explanation. The behavior where it appears to be 'holding' a stick input can be adequately explained by proportional responses—the autopilot doesn't input full deflection if you aren't a long way off of your set point, so that it can avoid overcorrecting. I'd imagine adding stick input confuses it—it's only a little bit away from where it ought to be, but the authority it's allowed to use to correct for a small error isn't big enough to overcome the small, but slightly larger amount of deflection imposed by the flight controls.

This is wrong for every application except for recorded live-action, or simulations of recorded live-action video. A frame in film represents a period of time, and interframe blur is an adequate simulation of smoothness. In a game, a frame is a moment in time. It's like The Hobbit in high frame rate, but on steroids—there is no blur whatsoever for the brain to interpret as smoothness, and even games with a 'blur' feature are just applying a filter to individual frames, which, as players of Arma will tell you, does not necessarily make them look smooth. There are also some complications with brightness and light levels, but the average human can easily distinguish between a game at 30 frames per second and a game at 60 frames per second, and a lot of people will notice the difference between a game at 60 frames per second and a game at 120 frames per second (though only through overall smoothness, if their monitors aren't capable of more than 60 hertz of refresh).

Do ground-based early warning radars work? I've been playing with them in the mission editor, and I can't even get them to emit, much less show contacts on the HDDs in the Russian planes. I have both of them in a group with a command post and a generator truck, and I even went so far as to set a mission start trigger to turn on unit AI and emissions.

I have saved profiles, which will hopefully keep on working—if keys change a little, I'm okay with not being able to change them as long as I can load my old profile. If they stop, I'll just have to re-do them. The most time-consuming part for me was working out how the bindings would go. Now I'd just have to reproduce them from my cheat sheets.

I couldn't get it—I had a group with the command post listed above the EWRs in the air defense category, both EWRs, both kinds of generator truck, an ATC command post, and an S-300 command post and search radar, and I neither saw the radar emitting with the RWR, nor any contacts on the HDD. Anyone have any ideas, or is this a thing that just isn't working right now? I guess I could try poking at the Su-27 and MiG-29S quick missions—those might shine some light on it. Edit: hello, potential Google searchers from the future! According to this post and my confirmation, for an EWR, you want it to be 1) the vehicle, not the static object and 2) the first thing in its group.

I've been playing with these a little, trying to get them to send contacts to the Su-27's HDD. So far, I haven't even gotten them to emit--I have Russian EWR and a command post in a group, but I'm not seeing any contact on the threat warning receiver in the Flanker. I take it I need other things in the group, or that EWRs and Su-27 datalinking don't work right now?