Haril

Pretty sure step 3 isn't necessary. At least I can't remember having to fiddle with the datalink system to get it to work. You just need the skhval reset, the target point selected and the HMS deactivated. When all this is set, you uncage, and it'll activate and snap to the coordinates of the target point.

Uncage SHKVAL, pan to the elevation you want to scan across and bearing you want to be the centre of the scan. Press the Uncage SHKVAL button again and it'll start scanning. There's a knob on the right hand panel, at the bottom, to alter the speed of the panning. There's no cleverness involved here. It won't identify targets or anything like that, just sweep backwards and forwards until you reset it.

Rudder trim affects the final position of an Auto-Turn-To-Target attempt. So does wind, for that matter. It's unlikely to always be spot-on, so get used to adding a little rudder to finish the line up.

The autopilot channels only disconnect in the below-4m-condition if auto-hover is on. Do not land with auto-hover on or you'll go spinny-side down.

Try harder? <shrug> Worked for me fine in 1 and 1.01. I was reversing waypoints all over the place.

It used to work in previous versions. It was "fixed" in, I think, 1.02. I miss it.

When you're flying forwards normally, the helicopter is pitched nose down. When trimmed at this attitude, the autopilot will try to maintain this nose-down attitude. When you pull back to enter the hover, you're changing the attitude to nose up. The autopilot tries to counter this by adding some nose down stick. You then counter this counter by adding more nose up stick. When you've stopped and are hovering, the nose is still above the location it would be if you were going forwards, so the autopilot is still adding nose down stick to try to get the attitude back to where it was, and you're still pulling back to counter this. When you hit the trimmer, the autopilot lets go and stops trying to lower the nose. All that's left then is your back stick, which causes the helicopter to pitch up. To avoid this, don't manouver the helicopter without first holding down the trimmer. If every stick movement is done with the trimmer held down, you won't experience jolts like this. Real Pilots can tap the trimmer as they're going through the manouver, but then Real Pilots don't have to recentre the stick every time they press the trimmer. Hope this helps.

No, not really. Every single other piece of software that's come out in the last 5 years has been able to follow Microsoft's guidelines and put config files and user generated files like Lock On's tracks and screen shots in Documents And Settings (XP) or Users (Vista, 7). I was stunned when Black Shark came out and was still trying to save user generated config files in the game's install directory. I'd like to think that ED has moved on from this to save files in locations where they're meant to be saved, but your answer doesn't exactly fill me with confidence.

Out of interest, is this stuff fixed for DCS:A10, or are we still going to have to mess around with UAC, VirtualStore and the like for that too?

Does that not just deselect and select the target type? That's been my experience in the past when I've tried it.

How do you ingress to the second or third target of a target type?

Surely the easiest way to determine this would be to look at the stick in the cockpit (or the ctrl+enter display) when the autopilot's straining and see if it's in a different position that when it's not? I don't believe the cockpit stick moves at all unless the user moves their controller. It's also known that the collective's altitude hold adjustments aren't fed back to the pilot - the collective is unable to move up or down whilst the brake is engaged, and yet the actual collective still adjusts itself to hold altitude/height.

Sorry, no. It's from a half-remembered post from one of the ED team several months ago.

Are you sure about this? From what I've heard in the past, the autopilot is downstream of the controls, and doesn't feedback its inputs to the pilot. I believe a real pilot's experience is very much like ours, except he doesn't have to worry about recentering the controls after trimming, allowing him to trim far more often. This would reduce the autopilot jerk you're talking about.

After some testing, I've determined that preemptive flare launch *is* modelled in DCS:BS. Setting myself up agaist an Igla dude and a Strela, I set up countermeasure programs of 017, 011 and 012 and and started them just before I got into range then slowed down time using alt+z. When the hostile launched, I stopped the countermeasure program and watched the missiles. With the Igla, the majority of the missiles with 017 and 011 went after the flares dropped before launch, but usually hit the helicopter with 012. With the strela, it was around 50% with 011 and pretty much a guaranteed kill with 012. It seems more important to have a flare near the helicopter at the time of launch than having a billion flare strung out behind you but further away. Launching single sided with 011 resulted in the same effect as launching two-sided with 011, so double launching seems like a waste. I'll be flying with 011 programmed from now on, with a single side selected, and pressing the go button when I'm somewhere hostile. That's 2 minutes of semi-protection assuming you remember to switch sides half way through.

Last time I completed it, I followed the convoy at 600m about 3km behind them. When the ambush ambushed, the woods got all my rockets then I tidied up with the cannon. This would not be sensible in an environment with enemy air defences, but the guys hiding in the wood don't really have any.

That thread only had AlphaOneSix saying he thought that preemptive flares did have an effect of attracting launched missiles. The testing itself wasn't really testing this, unfortunately, and was mostly testing to see which dispenser patterns are most effective. I still don't believe that preemptive flares have any effect on a launch, though they would have an effect on a loose missile where they provide an additional non-helicopter target to get fixated on. The only real way to test preemptive flares would be to dispense right up to the missile launch, and then drop nothing else and see where the missile ends up.

DCS:Blackshark doesn't model that aspect of flare use, unfortunately. I'm suggesting dropping flares every second as I know my reaction times aren't good enough to make it to the countermeasure button between missile launch and impact at the sort of ranges where MANPADs are a threat.

You could try dropping a pair of flares every second from when the combat starts to when it ends. If you know a more accurate time when the stinger spawns, you could drop them more densely just for that period. I've played that mission twice, albeit not with this current patch, and the stinger never launched at me. Maybe I was just lucky.

It died due to a lack of interest. If there's still people that want to do it, I'm sure it can be resurrected.

As far as I'm aware, ground forces are not affected in any way by light levels, fog or cloud. They do not notice units more or less if they're lit up like christmas trees or completely blacked out. Only AI aircraft have decent spotting AI at present.

You need to reduce collective again to maintain a stable altitude before releasing the collective brake, but otherwise, yeah.

I believe it's for the other way around - telling radar-equipped friendlies that you're not a target. The shark doesn't have any way of interogating locked targets as far as I'm aware.

Perhaps it's too dark? Some missions start early in the morning when it's too dark to get a steady lock.

DCS currently only uses about 1.3 cores due to modern graphics drivers being multithreaded. Depending on how (if?) the FC2.0 sound stuff is ported to DCS, this should increase slightly as the new sound is split into two additional threads. It still won't get anywhere close to getting the full performance out of your 4 cores, though.