Swift.

It was updated around the same time a lot of the other HOTAS commands for hornet were added

So with IFF in the sense we are talking, mode 4, its either a friendly response or no response at all. What this means is that an interrogation, by Castle depress and Castle right, can only ever make a track Friendly or leave it as unknown. Marking a track as hostile will require another ID source.

In this test, is the target aircraft friendly?

If you are inadvertently commanding AACQ, then you are waiting too long between depress and SCS right

Sorry I meant always as in ever since the in and right motion was added.

Awesome, so it looks like Alpha and Echo are nearly identical with Alpha having the receivers directed in externally, and Echo having the whole thing self contained?

Thats how its always worked, at least thats how I've been doing it successfully thusfar

SCS Depress then release, then immediately press it towards the radar TUC is any track that your cursor is placed over

Off topic, but heres a question to ask yourself. What changes in the radar in STT when an AMRAAM launches? Should there even be a launch warning for ARH missiles.

To your problem, you should be able to offset the designation itself from the radar, and then drop a Mark on that. Theres no need to mark the initial radar contact first.

Historically in DCS, countermeasure success has been a simple matter of chance, with each additional 'unit' of countermeasure adding more chance of defeat. So the idea is to get as much CM in the air as required as quickly as possible. ie the best program for an IR missile would be 120 flares in a single shot. Having said that, I dont think DCS yet models prelaunch defeat, ie you can still track someone with your seeker even if they have a decoy hotter than the sun behind them. So its a balance. Run in programs, long delivery so you can have maximum chance of defeating an unseen threat. Reactive programs, maximum deployment as quick as possible, ie 5 or 10 in one go.

You can't, if you dispense in bypass it wont count them even if you switch back to ON. Your best bet is to set up some programs on Prog 1 and Prog 5 and use the Manual mode as a quasi bypass if you need.

I noticed a similar thing the other day with just pressing the EXP button on the MPCD itself. I just assume its related to the bug where the STEP button doesn't work, it seems the cursor on the SA page isnt behaving how it should.

There is an interesting image floating around of a Markpoint with an offset applied to it from a real hornet, but no idea the OFP of said hornet.

I have the same issue myself, Winwing SuperTaurus

Ive noticed that Harpoons launched from AIs such as a ship, tend to skim at a proper height of 30ft iirc. Then do a nice acquisition pop up before descending back for terminal.

If I were to hazard a guess, I would say the 'arming needed for setting' is a Spanish software thing. Especially when you realise that the current mechanisation of code setting in ATFLIR (UFC>LTD/LST) is also probably a Spanish thing. The mechanisation described by the pilots I've spoken to is that press UFC will box the codes and whichever code is boxed (or both) will be the code that changes when you enter a code in the UFC.

Going by what Tholozor said, no. Because the gens are still online, the ground power switches wont engage. I havent looked at the systems myself, but I do know that the checklist for setting the alert only lists connecting the ground power after shutting down.

When you have assign an offset to a waypoint, making it OAP, the range to the waypoint shown in the HUD will instead show the range to the offset. Example, we are 12NM North WP1 1. Select WP1, HUD shows 12NM range 2. Offset from WP1 10NM South 3. Select OAP1 as the steering, expecting the HUD to show 12NM range, instead it shows 22NM 4. Designate OAP1, Hud shows TGT 12NM as expect 5. Offset the designation, Hud Shows TGT 22NM as expect OAPHUDbug.trk

When attempting to place a markpoint on an Offset, the markpoints location will instead be placed on the OAP location even though the offset is the current designation. OffsetMKbug.trk

'The common way' being the way that is never done IRL

24 squares is a lot. 2400km from your current position Edit, read the rest of the thread now, ignore me

This is an attempt to capture in a bug report the as yet unfixed facet of the reverse ground effect bug, whereby the nose of the aircraft is 'sucked' into the ground when landing. DCS In DCS, 2 approaches were made in Half and Full flaps, both trimmed to OnSpeed using the E bracket and both flown as hands off as possible. Approaches were made at an airfield to allow minimal control input. Refer to tracks: Fullflap.trk and halfflap.trk It is observable that the AOA, shortly before touchdown, will reduce enough for the AOA indexer and the E-Bracket to be showing a 'Fast' landing. Here is a clip of a carrier landing where this effect is displayed, more control input is made, but it is noticed that the lack of pitch input does not correlate to the lack of AOA movement. Real World See this clip of an FA-18C landing on the carrier, notice how the E Bracket stays relatively steady compared to the DCS examples. Supplementary to this, here is a clip showing an FA-18E landing on a carrier, also showing a steady E-Bracket, however this time it is also visible that the pilot is not inputting a back force on the stick (along with a reduction in power) as would be required in DCS to achieve this behaviour. Abstract In an attempt to further understand this behaviour, I attempt 2 low approaches with the gear up and flaps in Full. On the first pass (notrim), no trim was applied after flaps were dropped, leading to an already 'Fast' approach. A significant reduction of this nose down effect was observed. On the second pass (trim) the jet was trimmed to 8.2 AOA prior to the approach, in this example reductions to ~7 AOA can be observed. The conclusion I draw from this is that the effect appears to be attempting to nullify the trim applied to the jet, which is why it is not seen for the 'notrim' track. halfflap.trk Fullflap.trk notrim.trk trim.trk

Is there a way to designate a surface track? It seems like something that should definitely be possible. Having said that though, its probably something more to do with a deeper simulation of Link16 than we have.

What I've noticed is that those who tend to PIO are better off not looking at the basket, but if you aren't likely to initiate a PIO then looking at the basket is easier because you can actually see where you are going. Personally I like to avoid staring at one thing for too long, by glancing at everything, I find I have a better appraisal of the relative movement. Doesn't help so much for hitting the basket, but helps keeping it stable.