Fishbreath

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?

DCS World, which is free, is the base game which modules like Black Shark 2 plug into. You'll be able to play in any server in multiplayer which has Ka-50 slots.

It's a shame. During the run-up to 1.2.6, Wags did mention that one of the things they're working on is separate code for IRST and radar; I'd expect some fixes/improvements at that point. Hopefully.

Yes.

It's on my list, but I need to learn the Huey first, and I'd like some fast movers, so it's Flaming Cliffs 3 for me next. :P

This already happens all the time. On your other post on trust: that's immaterial. Either you thought it was worth $50 or you didn't. If you didn't think it was worth $50, you shouldn't have paid $50, and insisting that everyone else who didn't think it was worth $50 should also have to pay $50 is silly.

I paid full price for my candy, and it's very disappointing that Wal-mart would treat consumers so badly as to let these uppity newcomers get in almost for free.

If you respect your money as much as you say you do, you would have waited for a sale. If you wanted the Mi-8 at or close to release and you were willing to pay full price for it then, you have no grounds for complaint: having it immediately was more important to you than price. If you're complaining now, you obviously didn't actually consider the Mi-8 to be worth the full price when you paid for it, and you should have been prepared to wait for a sale (or for your opinions to change), whether it took two weeks or two years.

Working as designed, I'm pretty sure: if you have a point selected in the PVI, the datalink will prioritize that.

Great! This means you've evaluated your preferences and decided that having a DCS module the moment it's released is less important to you than having it for a discounted price. In the future, with respect to ED, you'll be making more informed decisions as a consumer, and this is good. It's the market working, and in the same manner, if enough people change their buying behavior as a result of ED's sales policies, ED might change them someday. I, too, tend to wait for sales, because I don't have a ton of time for flight simming these days, and I find that having a game soon is less important to me than having a game for a lower price. (Except for the Hornet, which I'm going to preorder for beta access as soon as ED lets me.)

And the fact that they've done it twice now suggests that people complaining on the forums are vastly outnumbered by people who are willing to jump into DCS during sales. Speaking of which, I'm looking to snag FC3 tomorrow when the sale starts. Is Ubi's shop the best place to get a copy of LOMAC to put beneath it?

I'm down-repping anyone who starts a sale-whining thread today Because if you do, you deserve it. I'm not going to beat around the bush; we've been over this during every sale I've been at these forums for. Let's look at a few of your (referring only to the people complaining) arguments: 1) It's bad business sense! Evidently not, because Eagle Dynamics keeps on running them, and Belsimtek is in with a second recently-released beta module after already doing it once. The upshot is clear: the sales are great for business in spite of the sky-is-falling forum whiners. It's not even an unexpected result from a microeconomics standpoint. There exists a class of people for whom a utility helicopter does not represent $50 of fun (I count myself among them), but who do consider a utility helicopter at least $20 of fun (me again). By dropping the price, the developers pull in a bunch of people at $20 who wouldn't have ever paid the undiscounted price. 1a) The Mi-8 was just released two weeks ago! Why is it on sale already? You're cheapening your product! Apparently, it worked well enough for the Huey that BST decided they should do it again. "You're cheapening your product" is another terrible argument, one I only really see in the flight simming and wargaming communities. A game's worth doesn't come from its price, it comes from how good a product it is. People view the goodness of a product differently, and from there they decide what value to attach to it. The goal of any developer should be to make a game appealing, and to price it so that the product of price and people who will buy at that price comes to the largest number. 2) I paid full price a week ago, and now I'm angry that it's on sale! This doesn't make you special, except insofar as it makes you irrational. Consider: I go to see a movie on release night and pay $15 for a ticket. That doesn't mean I'm going to rage at people who go see a Sunday matinee next month: the utility of seeing the movie as soon as I could was, to me, worth paying twice the ticket price. In the same sense, I paid full price for Black Shark 2, because having it immediately was more important to me than the money I would save by waiting for a discount. If you paid full price and are angry when it goes on sale, that's on you: you didn't think hard enough about your preferences and what they're worth to you, and you paid more for a module than the value you actually assigned to it, even knowing as you probably did that there would be another sale soon. Your impatience is not ED's fault.

Oh man. I don't know if I'm going to be able to ignore Flaming Cliffs 3 when I can get it for $10 (LOMAC from Ubi) + $20 (FC3 from ED).

An autostart sequence would literally compress three key-presses to one, or two if it's in the radio menu. Much better would be distributing one of the various quickstart guides from these forums with the Steam download.

I reinstalled, and still no joy. Hoping for a fix or workaround soon.