bfr

Its the same as every other jet in DCS. Win+Home to auto-start.

I hope they backfill that configuration option onto the F-14 eventually. Its the only fast jet I own where I have to apply curves to tune where the AB kicks on relative to the detent on my throttle. Whilst the ED F18 and F16 don't have that option either, they do both seem to kick the burners in at about the 75% mark with no curve required.

Yes, the -J would be the logical choice if HB follow through with a module/expansion for a naval version and that is the model from which all the British Phantoms were derived (and the last lot bought were literally low mileage -J models from US inventory).

Ah OK, I think I also have some dead zone for the detent dialled in at controller level too (Virpil TM3) so not sure how the in-game setting ties in with that.

Might be a case of double-checking mappings and options? Mine was off at first but fine after setting detent to 75 and deadzone to 10 in Options > Special (which is consistent with what I have set to for F-15E, also with independent axes for each engine).

Interesting, as i'm still working through setting up HOTAS and have not yet mapped the pinky (selected gun by mouse interaction purely off the station select switch). I did do an automated cold start on that flight though so perhaps that sets the pinky? Cheers for the clarification though and i'll mark it as solved if it is indeed expected behaviour.

GUN selected on station select, master arm to ARM. Head Up Display Indicator shows GUN and ARM illuminated. All good. Deselect GUN on station select, master arm to SAFE. GUN remains lit on Head Up Display Indicator light panel. Is this a quirk/by design or a bug? I would've expected it to be extinguished when not a selected weapon?

The RAF & FAA never flew the F-4E. All the UK ones were based on the F-4J.

Can you enlighten us all to what problems you believe exist between Heatblur and ED?

What on earth are you on about? It reads like you're confusing Heatblur and Razbam.

Have a grown up conversation about the issue and decide if it's a forward fix or a brief delay required usually.

Your sacrifice will be noted.

Be grateful of the extra time to cultivate it.

Are you planning on pulling an all-nighter for these 'updates' or something?

I imagine testing is a lot more difficult than your average software development project because the number of interactions and paths to explore is so huge, so much of what you are evaluating is subjective and not to mention the variety of hardware your product is going to eventually run on (which I think was at the heart of the case for the initial HB delay where something broke things badly on certain levels of hardware). The recent shift in release cadence I wonder whether is a double-edged sword or not. On one hand it should mean things don't need to be rushed but there is also an obvious temptation to squeeze 'one last thing' into a build when the next release window is six weeks away rather than a couple.

People complain if you don't give dates and you literally cannot win unless everything goes 100% on time and without incident (and for the required contingency to even begin to hit that then people would complain instead that updates take too long to come out).

Delayed because you can't necessarily just disentangle the two things at the drop of a hat, and especially as it sounds like the module has dependency on the thing that is in need of some attention.

Chances are the preview build they were given isn't exactly the same as the one that is due to be released (that will include other changes to DCS/other modules). Also you don't know if that preview build came with "its mostly fine but this bit is still not quite right so don't do this/that" caveats attached.

Outlook on delays depends completely on the overall situation. If something absolutely definitely has to go on a given day at a given time then you probably stack your deck so everything going out is frozen with plenty of time to go. If the need arises and a minor delay isn't going to be the end of the world (and lets be honest, it isn't in this case) you cut things a little finer. And even with the best will in the world, stuff still comes out of the woodwork from time to time. As for 'how do you know it will take exactly one day', it may well take a lot less than that. Bumping it a whole day when you don't need the whole day means you aren't rushing it and also all your support/contingency arrangements in terms of peoples working hours are likely exactly the same as if they'd hit the original deadline (rather than delaying by a few hours but possibly then hitting 'release' and everyone signs off for the day straight after).

That assumes they can just knock out another build with any flaky stuff rolled back, and also assumes the flaky stuff isn't also a dependency of something else left in the build. As others have said, these things happen from time to time and its generally wiser to take your time fixing the underlying issue properly as well-meaning rushing of things often ends up risking making matters worse.

And the penguins. Don't forget them.

Usually updates seem to drop from around 1300-1400 GMT onwards.

I guess it becomes irrelevant once HB eventually do a carrier-capable variant but there isn't a firm timescale on that yet.

Fair enough, didn't realise such a mod existed.