Sideburns

When the Phoenix no RWR warning issue was apparent it was taken seriously by HB and most server owners. In the latter case many missions removed the Phoenix until it could be fixed. Unfortunately given ED's monthly update cycle this did take some time to arrive, during which time most F14's were relegated to fox1/fox2 situation with sparrows and sidewinders. It was a fun time to explore these missiles for many. I also generally find the F14 community one of the most honest w.r.t not exploiting bugs, reporting bugs and striving for accuracy. As well as finding HB one of the most respectful module developers when responding to legitimate and illegitimate bug and issues in their modules, as you may note by their responses to you on this topic. While DCS is not perfect, it is highly enjoyable in multiplayer because of the general accuracy, strengths and weaknesses of each module. If you don't enjoy multiplayer fine, but stating it is not a multiplayer game/simulator when many enjoy DCS this way just serves to make you look foolish, as does your focus on pay to win. As per Naquaii's response, what do you hope to achieve here? Would you like some tuition on how to beat the F14 in MP?

So holding M1.1 in a slow climb, zone 5 AB, from 32kft to 37kft will result in TIT overtemp and twin engine fire fairly reliably for me, issues becoming evident around 34/35kft as the TIT rises rapidly. Speed has to be M.1.10-M1.12 Sometimes happens with compressor stall warnings, sometimes not. In tests I did this with an unloaded / naked F14a, but I imagine as per prior comments having a loadout may more easily hold the plane at the "magic" M1.10-M1.12 speed as you pass through 34/35kft. Edit: Caucasus map, default weather / pressure conditions. Suspect the variation in this issue might be down to "engine condition variation" between spawns.

A quick test of this issue over lunch break indicates to me it may be linked to the ramp scheduling under certain conditions. On a flight to angels 30-35k, going supersonic there were no unsolicited compressor stalls this time but stowing one engine's ramp created issues starting at M1.1, a very similar speed to where most are having issues. I will keep testing tonight to see if I can get a unsolicited compressor stall and observe for ramp issues / activity. Edit: To be clear, prior to M1.1 the ramps don't seem to move much (full open / stow doesn't cause an issue), inlet ramp activity appears to start at M1.0+ in a minor inlet ramp adjustment and begins to be significant at about M1.1. Perhaps the inlet ramps are not opening enough?

I was having multiple compressor stall events trying to get through M1.1 last night and I did think it could be a inlet/ramps issues, also read an article last night saying that ramp issues were not uncommon but I thought it would be incredible, perhaps too incredible, for HB to model this. https://www.thedrive.com/the-war-zone/9599/a-tomcat-pilots-early-struggles-to-tame-the-mighty-f-14 "The F-14 had ramps in each engine intake that were hydraulically driven down at high mach numbers to reduce the area of the intake. It turned out that the left ramp intake had incorrectly deployed as we were on our takeoff roll, causing the left engine to enter into a compressor stall and lose thrust. Sucking a ramp down was not a common occurrence with the F-14, and with over 1100 hours in the Tomcat, it only happened to me one time…on my first takeoff roll!" I didn't feel like playing around with ramp switches last night (MP with RIO, didn't want to self destruct) but will give it a try tonight.

I've also had this issue a few times tonight, around mach 1.0-1.15, 30,000-35,000ft. Worse in level flight (as stated earlier a dive through this speed region seems to get through the dangerpoint before it is an issue. If I was to guess the problem speed range it would be M1.05-M1.13). At some point the engine can enter a dangerous state with fuel flow and temperature for both engines oscillating rapidly. Stall light flash. Sometimes if you are quick enough and throttle to idle it avoids the dual engine fire, temperatures settle and stall lights go out. Sometimes you get two stall light flashes and it is over. Edit: To be clear fairly sure I can reproduce this if you want a track or video.

Have you have seen the DCS source code or otherwise know the inner workings of DCS to make such a statement?

I guess a quick fix would just be to at least universally disable ECM for now until this can be resolved. Not ideal but would at least mean the bug is removed. Edit: I guess mission makers could create a fault for the ECM on jets, but this would be quite labour intensive and could then be resolved with a repair.

Where to start with this, unsure if troll or serious.... "It's fine for single player but the range difference is kind of bad for multiplayer because it's hell to balance a mission around that range difference" This is a flight simulator not Warthunder, while some servers may try to balance the sides each aircraft is intended to be an accurate simulation of the real life aircraft. For what it is worth the Phoenix despite it's range does need to be supported by a valid TWS track, which are easy to lose, to have a good chance of hitting otherwise it is likely to miss. It is also a large missile and loses energy quickly at low altitudes. It is not a silver bullet but when used correctly under the right conditions it's capabilities are awesome and should be respected. A fast and high AMRAAM launcher can be a credible threat to the F14 with Phoenix. "Various past and current issues described" Module is in early access and as stated the DCS core is in a constant state of flux, it has been difficult for HB to get things perfectly right when the foundations are changing without notice. Also the F14 is not the only module to have weapons or damage model issues, most modules have had these issues at some point. To HB's credit they are typically fairly rapid with fixes. "I also don't like that clown in the back auto-doing everything (auto chaff, auto flares, auto radar)" If you are complaining about Jester, while Jester is an amazing achievement he is not perfect and a real human RIO is better. It can be tricky to guide him in the middle of a fight for actions a human RIO would do automatically. The biggest complaint you can realistically make against Jester atm is that he calls out missile launces from far away (both enemy and friendly missile launches I believe!) In time these issues will hopefully be fixed. If you are complaining about having two crew members in the F14 this was a deliberate design choice based on Vietnam combat experience and lack of systems automation to enable a suitable workload for one pilot/crew member. You might as well complain to the US Navy and 1960s radar technology for this.

Man, I'm glad I'm not the only one. My refuelling checklist includes setting Jester to STFU. Otherwise its like a tommy gun of star wars jokes.

Improved finding, locking and IFF of targets I think, but no hard analysis or numbers. Just my opinion after a few solo MP sorties.

I'd rather the F14 was modelled accurately and the issues of lag and rubberbanding are dealt with separately. If I play a server and it has these issues I tend to just leave anyway (For the F14 or other modules) as it is not fun to play against UFOs. These issues do seem better in the latest patch.

Yeah, I've never done that to a human RIO, we usually have a good comms including clearly demarcating who has control of the radar / radar handover around 15nm from target.

I have commented elsewhere but I think I had this bug and using either PLM / PAL or VSL can knock things back in order as a work around to get Jester transitioning again.

In TWS modes the AWG-9 radar is maintaining a track file for each target, and depending on the classification of the targets by the RIO (hostile, friendly, unknown, don't attack, next target) orders the targets around automatically. TWS-Manual means the RIO controls the pointing of the radar whereas TWS-Auto means the AWG-9 controls it's own direction. You can use ctrl+enter to check which mode the radar is in (as well as your own control inputs). Hence it is not locking the targets persay but maintaining a rough position of them updated at a regular interval (2s I believe for the AWG-9, hence why it only works with two scan patterns). These track files are then used to guide the Aim54 to a rough position and tell it to engage its own active radar to search. There is no lock diamond or hud indication other than the "T" steering pointer in TWS-A to give a rough direction where you should be pointing. As you fire each missile the firing order will be replaced by a TTI (time to impact) estimate and the next target, previously target 2, now becomes target 1 in the firing order. The AWG-9 will also automatically change to TWS-A to try and best maintain TWS track of targets fired upon. Note also it can be a bit tense ripple firing all 6 at once as each Phoenix usually takes 3s to get off the rail from pressing fire. So around if a little over 18s for the whole lot.

Yeah, probably not realistic and I basically use it to work around Jester. Not needed so much with a human RIO. A quick tap of PLM resets things.

I use the PLM, pilot lock mode, to "reset" the radar. It is bound to my HOTAS. It is quite handy to reset TWS-A when it looks in the wrong direction pre-TWS launch when you are flying with Jester.

Getting below your targets can really help the awg-9 gather and hold it's tracks, it also seems to work better over sea and over land look down is not its strongest game.

I was about to comment on player latency / connection quality as a contributing factor to this perceived issue, I suspect other modules with high fidelity radar modelling also suffer to some extent from player rubber banding / warping around. It would be handy if ED could introduce "connection quality" tools for server operators to allow warning and kicking of clients that drop many packets or have poor latency.

I also noticed this, I think I used a PLM to break out of this situation and return back to normal P-STT / PD-STT selection.

I tend to just use the manoeuvre flaps (DLC back/forward) for carrier take off rather than the full flaps, and full MIL power on the F14b only. The F14a does need AB though I try to cut it as soon as possible to conserve fuel. Edit the new update does improve non-AB TF30 / F14a performance, I still like to run a bit of AB after clearing the cat to keep it safe though.

A real issue for competitions, FC3 planes can be incredibly strong compared to their full fidelity counterparts and sometimes the 3rd party modules can be wonky (looking at you MiG21). I hope as part of the enhanced damage modelling there is a universal balancing of all ED and 3rd party planes.

This situation can be due to where the targets don't correlate due to INS drift. If you have pulled a lot of G's or been flying for a while the INS can drift and this can result in AWACs reported co-ords for the target being off from your own ship INS and radar detected target. In this situation you will want the RIO to refix the INS, but afaik you can only do this with a human RIO atm, for reference on INS fixing https://www.youtube.com/watch?v=YqQz9YrEi6A

As much as I love the F14 and AWG9, and also HB's attention to detail and quite realistic radar modelling, it is primarily a "fleet defender" radar design for interception of high closure targets over the sea. The F14a/F14b AWG9 radar does have sheer power, but suffers from having relatively, compared to modern radars, large filters and a lack of programmable digital signal processing. The F15 did receive a DSP shortly after release which transformed its capabilities, allowing it to remain dynamic to new techniques and threats. When you get into the reality of dynamic, manoeuvring targets over land the AWG9 suffers and you need a skilled RIO to compensate, even then I feel uneasy at engagements between 30-10miles in the F14. Also, the "ground mode" of the AWG9 is quite austere. TLDR: The F18 and F14 radars are each good at supporting the specific purposes of their host platform. They are each better at different things.

Sorry, in response to your original query the pilot does start heavy breathing at around 4-5g usually so that can be a helpful hint. Pilots indicated they did go over this IRL "accidently", you're probably fine up to 8-9g unless you want to follow strict realism NATOPS.

Cheers for the detailed response, wasn't disagreeing with that limit just curious where he had picked it up from. Suspect the original point today was made on the ED Discord. I tend not to go too far with the G's myself being a survivor of the weak wings patches and also that INS.