Brun

Here's a track. Not perfect by any means, but I reckon it's reasonable enough. NellisApproach03R_001.trk

Are you sure you've read the roads right? Flying a perfectly normal (as far as I'm aware) approach doesn't even take me south of Carey Ave. Edit: Attached image looks about right, no? Downwind leg 1.1nm abeam the runway. Final turn starts with the runway threshold 45 degrees behind the left wing. Final approach is about 1nm. Lake Mead Blvd is miles away. Edit2: I am an idiot and have just read *EAST* break :D I can apprecaite that makes things rather tighter, but I've flipped the image and it still looks very doable.

Sure. Download it here... FA-18_headingPanel.obj

Better (very) late than never, heading panel is now available! https://www.shapeways.com/product/5JFSJH3FT/fa-18-headingpanel?optionId=122336315&li=marketplace It fits by simply pushing on to the bottom of the HUD panel. Should be secure enough without any extra hardware.

Plenty of details in this article.

Unless the wings are folded, NWS HI will only be active while the button is held.

It's normal. Without weight-on-wheels the throttle's idle position is physically restricted. Compressor (N2) 1. The maximum rpm is 102%. 2. Ground idle is: F404-GE-400 F404-GE-402 61 to 72% 63 to 70% 3. Flight idle is 68 to 73%. 4. Maximum fluctuation at stabilized power is ±1%.

My instinct is that you're not correctly compensating for the fact that the carrier is effectively moving to your right. If your aircraft's nose is pointing directly at the centreline on approach, your course will actually be a subtle turn to the right, and it's possible you're having to make a last-minute correction which exacerbates this. I appreciate why people say to ignore the VV, but it should always be to the right of the centreline on approach. I had similar problems until I realised what was going on.

Might be wrong, but I thought the hook warning was the AOA lights flashing if the bypass switch is set to carrier and the hook isn't down.

My question is whether the behaviour of the flaps in DCS - which is described in the NATOPS as "scheduled as a function of airspeed" is the same as the real aircraft. The only reason I mention moving the flap switch from auto above 250 kts is to demonstrate that that's consistent with the behaviour described in the flight manual - i.e. it has no effect. The important thing is what happens between 250 kts and 'approach speed', which seems distinctly odd in that it's very abrupt. I'll try to get a track or video recorded, but it might not be before the weekend.

The infamous 'nose-up' when slowing to approach speed has been done to death, but I'm still not sure everything's as it should be. From the NATOPS (I-2-55): That's for the flaps switch set to HALF. It's similar for FULL but maximum extension is 45 deg (and 42 deg aileron drop). Annoyingly it doesn't specify what 'approach airspeeds' are, but you would expect some sort of proportionality as speed drops below 250 knots which is not at all what I experience in DCS. In level flight at just over 250 kts, setting the flaps to HALF or FULL does nothing - as expected. They behave as in AUTO, which results in 5-6 degree extension (presumably this is dependent on AOA and therefore aircraft weight - fuel was low in this case). However, when *slowly* reducing speed there is a dramatic change in configuration when passing below about 240 kts. The flaps extend very suddenly, which causes the pitching up which everyone is familiar with. If you combat the pitch-up using the stick - without touching trim - the required forward deflection slowly reduces with airspeed until the aircraft will maintain level flight again at 165-170 kts. A similar thing happens when accelerating with flaps down. They remain extended and suddenly retract at about 240 kts, which results in the nose dropping. I've also noticed that the rudders are commanded to maximum toe-in (30 deg) a lot of the time when the flaps are selected, and again their movement seems very sudden. I found some mention of it in the NATOPS, but haven't done enough testing to see whether they're behaving as described. I don't have the knowledge or experience to post this as a bug, which is why I'm posting it here. It may be the case that the aircraft actually does behave like this, but it seems very strange when it's so straightforward to fly in every other respect. Would be very appreciative of any insight from an actual pilot.

Can anyone explain the following. On starting VA I test it, and get this (reads from the bottom-up as it appears in the VA output): 18:56:21 - Listening suspended 18:56:21 - Joystick : 'Transmit TX1 release' 18:56:17 - Constructing message... 18:56:17 - TX1 | VHF AM: [ ATC ],[ ],[ ] Inbound [ ] [ ] 18:56:17 - Unspecified recipient called: using default unit for this category 18:56:17 - Have result, identified as command : Inbound 18:56:17 - Captured sentence: inbound 18:56:17 - Recognized : 'inbound' (Confidence 85) 18:56:15 - Listening resumed 18:56:15 - Joystick : 'Transmit TX1 press' Which confirms PTT and speech recognition are working absolutely fine. However with DCS running a simple mission in the Hornet I just get: 18:59:51 - Listening suspended 18:59:51 - Joystick : 'Transmit TX1 release' 18:59:47 - TX1 | COMM1: ARC-210: Radio 38 AM 251.000 MHz tuned to recipient KC135MPRS Texaco 18:59:47 - TX1 | COMM1: ARC-210: Radio 38 AM 251.000 MHz tuned to recipient Al Maktoum Intl OMDW 18:59:47 - Listening resumed 18:59:47 - Joystick : 'Transmit TX1 press' This seems to suggest my radio is tuned correctly, but I can't get anything recognised. Neither "Approaching for refuel" or "Texaco, approaching for refuel" get any response. It's nothing specific to this mission, which has worked fine in the past. Current nothing is working at all. Furthermore, after quitting DCS *and* restarting VA it still doesn't recognise commands as in the first example until I reboot the PC. I've reset VAICOM multiple times to no avail, and disabled AIRIO in case that was the cause. No idea what else to do.

The ones which say AOA is controlled by throttle are simply wrong.

Just restarted VA (again) and commands now *are* being recognised. Seems to justify my description of it as 'flaky'. Lets see how I get on in DCS... Edit: No joy in the Hornet. Quit DCS. Restart VA. Back to not working again. Mental.

Hate to say it, but I'm just completely f**ked off with this right now. Despite working ok previously it's been increasingly flaky over the last couple of weeks and is now not working at all. The annoyance is trying to work out where the failure is happening. If I run VA without launching DCS, should it recognise commands? At the moment it won't even do that. The PTT keys are fine, and I get the appropriate sounds when keying the mic and releasing it, but nothing else. Despite the rant I don't blame Hollywood for this at all. I appreciate it's complicated stuff and the constant DCS updates don't help. It's just incredibly frustrating to waste so much time getting it to work when I've no idea if it's user error (perfectly likely) or some bug.

That's something I've been wanting to have in DCS for years, had no idea VAICOM made it possible. Will check it out asap, thanks!

Think I acknowledged I didn't like the square push buttons shortly after I bought them. They're unnecessarily firm (for this application at least) and there's no tactile confirmation of when you've actually pressed them. It's annoying because they're the same manufacturer as (and have an almost identical product code to) the round switches which are fine. The round ones were slightly cheaper as well. Good to know a much better alternative exists, but I'm not sure even I can justify the £120 to replace all 20 of them.

I hope you don't think you're supposed to do both those at once.

4 position switch here, and others in the 'similar items'... https://www.ebay.co.uk/itm/Fan-4-Position-3-Way-Selector-Rotary-Switch-13A-120VAC-With-Knob-In-UK/163403530697? Edit: Mouser have hundreds of 4-position and 8-position switches listed. Googling the manufacturer part numbers will hopefully find you a local supplier.

For reference I'd prefer it if the Jester commands could be displayed in the same way as regular comms. Appreciate that's a HB thing rather than anything to do with VAICOM though.

This has unfortunately broken for me with the latest DCS update. I've recently been suffering the flashing comms menu but have been able to fix this by resetting VAICOM from the control panel (everything except the licence). DCS had updated on Sunday and everything was fine after doing that. DCS updated again last night, but despite another VAICOM reset I can't get any response to voice commands at all. PTT appears to be working fine, and I can see the mic levels at the bottom of the VA window. I just don't get any commands recognised, and I've no idea why. Brilliant when it works, but so frustrating trying to figure things out when it doesn't.

Would be a good thing to be able to ask Jester.

Yeah, the press function on mine has only worked intermittently for a couple of years. I got the same response when I inquired about a replacement and decided it wasn't worth it. I searched for info on an alternative replacement part but couldn't find anything.

My favourite bits are the tiny wires for the AOA and other stuff on the HUD frame. I keep leaning forward to look at them in VR, it's incredible.

Okay then, tell us how it *will* be done? Your suggestion seems to be aimed at people who potentially have a lot of money to spend on the 'DCS-PC', but aren't themselves PC enthusiasts. Have you considered how many customers there might be for this? I suspect the majority of people using DCS are either confident enough to put a PC together themselves or happy to buy one off the shelf. As for the DCS-PC itself, who creates the specification - ED? Who decides what is acceptable performance? What VR hardware are we talking about - original Rift or Pimax 5k? What happens when new hardware comes out? Entertaining as it is, the whole idea is a complete non-starter.