fat creason

We'll take a look eventually but there are higher priority things that need to happen first. Have to prioritize resources in areas where people spend the most time, which is in-air, up and away from the airfield. Same reason that it doesn't make sense to spend a ton of resources on FM damage since flight with a missing wing constitutes <0.1% of your total time in the aircraft. Because we're so limited, we have to allocate our resources accordingly. Hope that makes sense.

Yeah I'm skeptical on this unless there's hard evidence to back it up. I recall some atmosphere model changes happening several years ago but never did any testing before or after to see what changed. If ED changes the atmosphere again it would cause all kinds of mayhem.

Yep. Would be nice if ED created an option for which type of track file you want to record. I can't imagine a lot of people use the "jump back into the cockpit" feature during track playback, which is the only real reason to use the current SP track recording method other than for debugging.

Best if you just read these posts/threads: TLDR: We're not 100% sure it's caused by anything we're doing after spending a good amount of time looking into it, it happens in other modules, and don't expect a fix anytime soon. If you need perfect replay tracks use server tracks instead, that's what all the trailer/movie makers use.

Here's a high level drag "cheat sheet" for A2A loadouts based on data in the F-14 performance manual. All adjustments were done relative to the default DCS drag values for each missile, correlated to drag index integer values for stores + their adapters at each station: Shoulder AIM-54 adapter: adds 25% additional drag compared to AIM-54 fully outside the boundary layer (missile + adapter = 2.2x drag of a tunnel AIM-54 and 2.1x shoulder AIM-7 drag) Tunnel AIM-54: 57% of the drag compared to AIM-54 fully outside the boundary layer (~10x tunnel AIM-7 drag!) AIM-54 has more than twice the drag of an AIM-7 outside the boundary layer Shoulder AIM-7 adapter: add 33% additional drag compared to AIM-7 fully outside the boundary layer (missile + adapter = ~10x drag of a tunnel AIM-7!) Tunnel AIM-7: 12.5% of the drag compared to AIM-7 fully outside the boundary layer Fuel tanks have slightly less drag than an AIM-54 + adapter on the shoulder AIM-9: highest drag shoulder option when summing all 4 missiles + adapters/launchers, but this changes quickly as number of missiles is reduced. Each AIM-9 is roughly equivalent to a shoulder mounted AIM-7 + adapter. In short, bring tunnel mounted Sparrows if you like going fast. The F-14's tunnel provides a place to mount stores well inside the boundary layer, allowing significant drag reductions particularly for the AIM-7 which is recessed even further into the fuselage of the Tomcat.

Tank drag was already pretty close, it's similar to the drag generated by an AIM-54 outside the boundary layer. The thrust change should fix acceleration.

That's why this FM update may feel like it's taking a long time to some people; it can only really be released all at once, not piecemeal. It's a multi-step process where each step blocks the next, and each step is massively time consuming. Add on the fact that it's being done for both airframes at the same time. Turn rate (aka excess power/EM chart tuning) is the very last step in this process because changes in previous steps will affect it. That's why I can't just immediately fix turn rate that has "tanked". After the performance update comes out, we'll go back to handling adjustments that are more "subjective" (be thankful that @Victory205is willing and able to help us in this, it wouldn't be possible without him!)

Yeah, the tunnel AIM-7s used to have about half the drag of an AIM-7 fully out in the slipstream/outside of any boundary layer effects, but according to the drag index data we have, it should be closer to about 1/8. Tunnel AIM-54s went from about 0.7 to 0.57 of the drag of a Phoenix in the slipstream. When you sum that across 4 missiles, it adds up.

I fully understand where you're coming from with this comment and partially agree. Certain metrics of FM performance can be measured so I feel I have an obligation to match them (at least to what the manuals say, which is all extrapolated/estimated data anyway), a process which is ongoing. That being said, I have yet to see anyone on these forums provide definitive and quantitative proof of turn performance issues, besides just saying they think it's currently "wrong", without providing numbers along with proof of how those numbers were obtained. I'm not saying it's perfectly correct at the moment, but it's funny to see some people get so up in arms about something they can't even quantify or define. Regardless, in terms of the "gamified" BFM scenarios that play out on MP servers, the validity of a "dogfight" outcome is only as good as the worst FM in DCS. At the end of the day it doesn't really matter if the F-14 has the mostest bestest FM ever and perfectly matches accelerations, turn rates, EM charts, etc because it's likely that very few other aircraft match their respective performance metrics throughout the envelope. Did you lose your fight with a F-18 or Su-27 because the F-14's underperforming or because your opponent's plane is overperforming in a certain area? Are you a bad pilot? Was the other guy a better pilot? Maybe you just got unlucky? There are many knowledge gaps in DCS that have to be filled by educated guessing, perhaps you got taken out by a weapon that's somewhat fictitious? Maybe a combo of all the above? Does anyone go and blame a FM when they win? I doubt it. That mentality is similar to questioning the legitimacy of an election only if you lose. Obsessing over in-game performance numbers for a particular airframe down to the last ft/sec of excess power is silly to me. Losing a fight and immediately blaming it on the FM is silly to me. People just need to get out there and enjoy the experience of these planes and be thankful they didn't have to join the military to do so. End of rant.

On a semi-related note, I have reviewed all the stores drag data (primarily for AIM-9/AIM-7/AIM-54 and their launchers/adapters) and correlated it to drag index data in the performance manual. You can expect significantly reduced drag for all tunnel mounted missiles and slight drag reductions for shoulder mounted AIM-7s and AIM-9s when the FM update comes out. @Victory205and I are making good progress on tuning airframe drag primarily in the transonic and supersonic regions (the magnitude of deceleration is too small on power chops). Thrust re-tune comes next once we've decided on the drag changes. A fixed bug that was preventing partial deployments in the automatic maneuvering slat/flap schedule will help turns and maneuvering above ~10 units AOA in the 0.5-0.85 mach range depending on altitude. Obviously, more tuning will be done to dial in excess power throughout the EM charts once thrust has been tuned to match level flight accelerations and max mach, but the above items needed to be correct before this can be done.

Last night I found yet another bug in the scheduler, it's now verified to be 100% fixed. This fix will come out with the rest of the FM update when it's ready.

Yeah, we simply have no insight regarding what could cause this problem. Even if I could reproduce it, there's nothing I could look at in the F-14 code that would tell me what the cause is, as well as no way to fix it. I would just get the same delays you're experiencing and that's about it. We merely set a couple values for FFB devices that DCS queries whenever it wants them (again, we have no control over when they're queried or sent). We're not overloading a controls buffer or anything like that. That's why you should post this problem on the ED side of the forums, they're the only ones who have the ability to see what the cause might be.

If you "really like BFM", there is nothing currently stopping you from doing so, only your personal choice. The current FM is not that far off and it certainly isn't causing you lose fights, especially at BFM speeds. Please read this post if you haven't already. If anyone is personally choosing to not fly the Tomcat right now, I'm not losing sleep over it and it isn't going to make work on the FM go any faster. I'll give an update on the FM when there is appropriate information to share. Just know that most of us work in our free time (this is a passion project, not a full time job) and we're committed to bringing you the most accurate public F-14 simulation that's ever been created; it will be done when it's done. That's the best answer I can give at this time, I apologize if that's not the answer you wanted to hear.

Has anyone tried the above fix? This topic should really be posted on the general DCS part of the forums, if anyone is going to have enough insight into the controls layer to see what's going on, it's ED and not us. We have no control over how or when inputs are read from hardware. Since it seems to be caused while the stick is shaking maybe we could remove all shaking effects from FFB, but I have no idea why that would cause DCS to have issues reading control inputs or have an impact on FPS. The same code is running all the time, only thing changing is the magnitude of shaking we ask the stick to do. As far as we know, all commands being sent to FFB are valid. To reiterate: we have no insight into this area at all.

We're working hard on it and have been for a while, best answer I can give you at this time. I'll provide more info when the time is appropriate.

I'll take a look at some point but understand this is very low priority compared to other things I've got going on.

This is not an issue with the F-14 itself in any way. Learn your stick and tame its mighty power!

I could never reproduce this issue; this apparent solution further confirms this is not F-14 specific and is more likely a DCS or hardware problem. All we do is read control inputs coming in via DCS's control input system and then tell the FFB stick how much force and rumble to apply via a very simple API provided by ED. This fix via an option you added in autoexec.cfg suggests the issue lies somewhere within the DCS control layer and/or FFB interface, neither of which we have any control over. Glad you could find a fix!

Was 100% sure this was fixed? I'll look at it again but no idea how that could break.

Assumptions get passed around on this forum as fact quite frequently. You're aware of the saying about assumptions, no?

Well this is news to me, the fact that I'm working on it (and have been) as I write this post says otherwise. Just because a fix is not immediate does not mean it's not a priority. If you've read any of my posts regarding the FM updates you would already know it's going to take time to fix.

There's a performance manual for the F-14A and B you can find fairly easily if you look. Aspects of the performance are being tuned so it may be better to hold off until the update is released.

Every word in this post is true, listen to this guy.

No FM or F-14A updates in this next patch. There will definitely be F-14 updates, just not those particular items. The team has been focusing on other things for this patch, but work is ongoing on these items. Like I've several times here, I will let you know when the FM update is ready.