fat creason

I use the same stick to develop and test the FFB model and have never seen this. It's most likely a local hardware issue or possibly a DCS control input/FFB handling issue, which we have no control over.

The entire situation is awkward because I'm pretty sure the RIO can't even reach the CB without really loosening all the straps on his seat, or at all. It's unfortunate that this embellished story was told in the first place. The whole story behind this CB is probably BS, hence it being a total waste of time to even discuss it.

We have no plans to further expand upon the current MCB mechanics or functionality. The practice of pulling the CB itself IRL is questionable to point that I have considered removing the feature entirely. It's just not worth wasting my time on. Thrust loss can vary from 20-30% when it's active. Hope that answers all your questions.

We already have the equivalent of that on the aerodynamics side. I was mostly referring to removal of other individual surfaces like the flaps/spoilers. Currently the visual representation of damage may not fully represent what's happening on the code/physics side.

Unless ED's new damage system provides easier or better ways of doing things and requires minimal work to implement, I don't plan on adding many more aerodynamic damage effects beyond removal of specific flight surfaces. Not sure what else is planned on the visual side of things.

Behold: https://en.wikipedia.org/wiki/Dunning–Kruger_effect in action!

Yes it should be in this update. It's in the changelog but not worded very clearly, I think my editing of the changelog didn't make it in time. I didn't have time to test the aero effects of the change, however. Hopefully it improved things a little bit.

This is likely a DCS bug. All we do is send the FFB interface a couple parameters if a FFB device is detected by the DCS controls interface and that's it.

This one should be fixed in the next patch.

This was a strange one, but it should be fixed in the next patch.

Found the potential bug in this logic (was mostly a bad value in the deploy scheduler table), it appears to be working based on the limited testing time I had before our cutoff time for the next patch.

Essentially this. Just because the cat was turning close to the charts in a small mach range does not mean it was perfect everywhere else. Once we had the F-14A, our SME (who only flew the A) determined there were other issues with airframe drag in general, especially in the transonic and supersonic regions. This is half expected because the primary wind tunnel data source only contains data at wind tunnel (read: very low) speeds. On top of that, we have been taking a closer look at stores drag in the tunnel since we believe there are issues with that, too. The amount of data in the performance manual is only enough to spot-check particular things and give an idea of "being on the right track", and is not enough to build or fully verify a FM with. That's why we have a SME to fly it. I typically don't divulge a ton info about the FM issues here since it tends to lead to a lot of armchair "experts" and Dunning-Kruger effect responses.

I am planning to look at the slat schedule in the subsonic region for this coming patch, that maybe help a bit, but all the other work that affects turn rate (and a ton of other stuff) is being done in its own branch and being tested by our SME. It will only release once it's 100% finished.

I agree with you and no offense taken. Up to this point a large majority of the time spent on the FM has been working on the handling aspects and not as much on the performance, since handling in this case is somewhat subjective (no handling data/tests available) and we wanted to focus on that with our SME. Performance numbers are a bit more objective and don't require as much SME input. ED does not provide any FM tools so any type of automated testing needs to be developed by each 3rd party individually. Testing via test pilots is also possible, but everyone is on a volunteer basis and testing these specific maneuvers takes large amounts of time and skill, so it's easy to have test coverage gaps.

Now does everyone believe me when I say that working on this type of stuff takes forever? 4 hours to test only up to Mach 0.8 at ONE altitude. Then one has to re-test AGAIN after making changes, analyze test results, make changes, then test AGAIN. Changes can take a long time. These changes are still WIP, do not assume they will show up in the next patch unless I specifically say the changes are ready.

Not that I am questioning your statements in any way, but I assume you're hand flying these tests. The only spots you can check on the chart while hand flying is along the Ps=0 line. If you are, are you reporting results after doing all of the following: hold constant speed +- 2 knots roughly hold +-100 ft/min on rate climb (hence the Ps=0 curve) maintain altitude within 200-300 ft of target altitude have the correct loadout/weight have unlimited fuel be at the correct altitude MSL have standard day conditions (15°C at sea level) have the correct flap setting stabilize this flight condition for at least 10 seconds before you take any G or turn rate measurement have it stabilized at least 4 (or more) times like that and take an average Hand flying this test while adhering to the above requirements for a valid test is extremely difficult (I have to admit I'm not a good enough stick to fly this!). Just want to make sure that everyone is testing in the same manner so a worthwhile discussion can be had. I know there are issues and they're being worked on, but this unfortunately the last in line for the changes since it's the last thing tuned.

Can you afford to pay competitive western salaries for 6 experienced full time engineers? In the US this would be in the $90,000-120,000+/year range. We do get paid, but it's not enough to make a living from (in the West at least), hence the reason we can't all do Heatblur full time. The only reason the Tomcat exists is because we traded large amounts of our free time and experience/expertise for an extremely non-equivalent amount of money. I think something that is lost on many people in the DCS community is lack of awareness of the skillsets required to make these simulations. Experienced engineers and programmers with these skillsets are very hard to find and tend to be very expensive. If 3rd party DCS modules were about the money, there would be far fewer of them and they would be of lower quality.

No, Heatblur has always been like this, at least on the engineering/programming side. I believe many other 3rd parties operate like this as well. All of the Tomcat code was developed by 5-6 guys in our free time.

Everyone should be very appreciative of the presence of @Victory205 here, we are lucky to have him. He has spent of hundreds hours flying the DCS Tomcat to not only make our jobs easier (thank you!), but to make sure the DCS Cat flies as close to the real thing as possible in a consumer simulation.

Not sure if you're aware of this; at Heatblur we have some full time employees, but none of the programmers at Heatblur work for Heatblur full time. We all have day jobs which means work on the F-14 can only happen in our free time. I believe the majority of 3rd parties operate this way (I could be wrong). It's one of the reasons things can take so long. The reason we choose to make products like the Tomcat is only because we are as passionate about flight simulation as you are.

There are updates coming but I can't promise a date as these types of changes are extremely time consuming and I work on this project in my free time. Unfortunately the turn rate and performance tuning is the last item in a very long process. We are currently investigating drag for fuel tanks and stores mounted in the tunnel, supersonic airframe drag, and AB thrust in the supersonic region. Turn rate performance can be evaluated and tuned after all these other issues have been resolved and set in stone, and the process takes almost twice as long as we now have 2 airframes/engines. Releasing these updates piecemeal will probably not end well so I plan to fix all these issues in another branch and it will show up when it shows up. Sorry I can't give a more concrete answer for the time being.

Yes, with the FM we can only worry about things we have control over, and that's clean performance and ext fuel tank or pod drag. We're going to look at the stores drag we can control, but any missile or bomb drag we have no control over so for any missile or bomb-heavy loadouts, all bets are off, unfortunately. I only test with clean loadouts or the lowest stores drag loadouts that we have data for, other loadouts are just not worth the time they would take to test. Drag and thrust tuning is still WIP now that our SME has had more time in the F-14A which he's more familiar with as opposed to the B which he never flew. We are working on airframe drag changes for both A and B, but tuning is very time consuming as airframe drag changes require a re-tune of both engine's thrust models in order to restore level flight acceleration tests (and therefore specific excess power, etc). Then once you've done that, you have to go back and check airframe drag again, then re-tune engine, etc, etc... That's what takes so long. FWIW, the F-14B level flight acceleration tests are spot-on more or less across the board with a 4SW/4SP loadout, no tanks. The slow transonic acceleration people are noting here is most likely from stores, the F-14A needs to be unloaded slightly to about 0.5G to help push through the transonic region, especially if you have stores. A clean F-14A will hit a wall around 0.92 at MIL power, even in a slight dive. Once you get through about 1.2, acceleration will increase and you can go back to level flight. This drag is still be adjusted as noted above, but we can really only tune against clean airframe performance since it's what we have control over.

This is probably a DCS bug, we have no control over that.

I tested this extensively and never got engine fires in level flight at any speed. Is there a consistent way to reproduce this? F-14A only, right? What's your loadout?

That's nice to hear. We didn't change anything on our end at least.