Galinette

Interesting, I wouldn't have thought the F-16C to be this heavy. We still need a F-16A/B in DCS. Much lighter, and somewhat more thrust . The only true We don't need those pesky MFDs and reliable engines

These charts don't do justice to the F-16, they stop before corner speed where the viper shines. Large deltas have a flatter turn rate curve as they need to take less AoA than small regular wings at low speed (especially with slats). On the other hand they have a significantly higher drag at high speed / low AoA than viper like wings. Check Mirage III and KFir charts : STR curve is very flat over a broad speed range. The Mirage 2000 performance chart from the Northrop symposium, that is shared in the forums, has low value. Turn rate is overall lower than a Mirage III which doesn't make sense with the latest M53P2 engine. It also has a wrong shape (slope is too high)

If any versions of the M-2000C releases have to be compared, it's pre engine upgrade (<=2.7.12) and post fm-rework (>=2.7.18). The state of intermediate versions has been communicated upon already : reworking the engine without updating the FM resulted in an overall too high performance, which was adjusted in the next version with a quick and dirty fix that wasn't validated. So, versions between 2.7.13 and 2.7.17 shouldn't be used as reference in any way. You should present better performance charts, that go beyond corner speed, are more precise on conditions (air temperature, max afterburner time, ...) Setting fuel quantities that give everyone the same afterburner time is a much better comparison. By using 100% for everyone you give a strong penalty to aircraft with large fuel capacity. Any time you give a judgment on "realism", please provide a comparison source, otherwise this has little informative value.

That's likely an effect of your rudder, not the nose wheel.

Recently, we removed a smallhard-coded deadzone in the M2000C controls, as this preventing doing micro corrections if you have a very precise stick. This may explain the change you have seen. Also, we made the auto-trimming more accurate, so a minimal stick input bias is more noticeable. Just add a small deadzone to the axis settings of the M-2000C, you will find back the old behavior. I don't know the Warthog, isn't there a calibration software? Calibrating the center carefully is always better than a deadzone, if possible.

This seems unreproducible. Are you sure your don't have a curve or calibration issue? If possible, please send a .trk showing the issue.

These two buttons have no lights according to our sources. This is not a bug but a feature

What do you mean by Tt7 rule of thumb? RPM increases to approximately 60% for the anti surge procedure, and this rule would lead to 1200°C Tt7. Tt7 may not be 100% accurate, but this is a simulated parameter (from full thermodynamic modelling of the engine) and is not "scripted", so we can't apply an average rule here. What I know is, it nearly touches the red zone at each startup and decreases. Same for Sec CARB RPM, it's in no way scripted and a pure simulation result. The default fuel flow is the parameter here. Maybe it's too low. Besides this, alarm panel is not accurate, and will be updated later on together with better failure modelling. Emergency LG handle too, this is an old thing that requires remodelling how the handle animates so fixing it is postponed, but will happen.

Yes, g lock effect is a core feature. Fighter pilots that comment DCS on youtube channels all say it's way too sensitive compared to real life, and disable it for playing.

Hi, I don't think anything changed. The line shows "unit_name / MGRS". In the first screenshot unit name was empty, while in the second one unit name is too long, the end is cropped with the MGRS. So as a first fix, if you have control over the mission, just use shorter unit names. What I can do then is truncate long unit names so that MGRS always shows, or put MGRS before the unit name.

Nice! Maybe the CG is more forward relative to the main landing gear on the viggen, and it is likely lower too. Also the Mirage 2000 has a pretty strong wing Cm moment coefficient linked to relaxed stability, a very strong ground effect from the flat, streamlined belly. It is known that it is prone to fall on its tail upon landing in some conditions. Last update, we had to do a quick fix to the FM as people complained about the increased turn rate from engine overhaul. We also updated the FBW laws from pilot feedback and this is what you feel the most in handling changes and aerobrake : with elevons allowed to max deflection on the ground, you have more control. And we noted a few things to improve when it comes to wing properties and performance, this is being adjusted carefully and will be part of a future update.

I know the situation before this latest update, I'm the developper. I can't fly a Mirage 2000 myself, but I'm in contact with pilots. I asked them, it's forbidden to hold aerobraking below 100kts. Why ? Because in some weight configurations the plane can topple back, even at 0kts. Yes, you can make a mirage standing still in equilibrium on its main gear in some fuel/loadout configurations (yes, I asked to mechanics, this is something important in some procedures). At this point, you need zero aerodynamic force to make it keep an angle. So if you hold aerobraking at too low speed, you can reach a point where you don't have enough elevon authority to pitch him down, topple back, and damage the aircraft. So actual mirage 2000 pilots have absolutely no idea of the minimum speed the aircraft can hold aerobraking. It's forbidden to try, they don't play with it. The FM is in a WIP state and has already evolved a lot since the latest update. I will check this carefully, it may be already fixed to your state as a side effect to changing other variables. But no, any change at the latest update is not necessarily wrong. What mainly changed here, is the ground elevon FBW law, we learned that with weight on wheels you get direct the full deflection range which wasn't the case before. And again, you can't say "I flew fighter aircraft, this isn't true". That kind of specific point is so much aircraft specific, you can't take a value from one and apply to another one. An aircraft that will topple back if you tilt it by more than 15-20° on the parking has theoritically, no minimum aerobraking speed. As a conclusion: - Don't tilt the aircraft at more than the inverted T cue in both take of and landing - Don't try to roll or aerobrake at less than 100kts. - Wait incoming updates, but the behavior won't change back to its exact state before last update.

The mirage center of mass is very close to its main landing gear. It can topple on its back if you refill the wing tank compartments on the wrong order. Couple this to an extreme ground effect when at its aerobraking pitch since the trailing edge is very close to the ground. And you can end up with a really different result from another aircraft. Now the landing procedure is clear : at 100kts you must land your nose gear and stop aerobraking. What you tried to do is forbidden. Stick to the procedure

I know the module behavior well! My point being : yes, it has changed a lot compared to previous version, but it could be in the right way.

Do you have a source for this? Actual M-2000C use aerobraking down to 100kts, at which point the procedure dictates to land the nose wheel for using wheel brakes. But pilots do land the nose wheel intentionally at that point, not because it doesn't hold anymore. Then regarding "not normal when land a Fighter", the M-2000C has the perfect configuration to hold aerobraking : the wing surface is huge and ends up very close to the runway on the rear, leading to a huge ground effect, air being trapped between the wing and the runway. Not something that happens on fighters with tails. Unless you have specific sources about the topic, the 80kts behavior is far from impossible.

Argument 369 is the RPM % needle

As said above, we know the low speed behavior issue very well. We also know this video by heart, have AdA feedback, testers that reproduce the airshow displays, analyze frame by frame, etc... Basically if you find something or know something there are 99.9% chances we know it. Why does it take time to correct then? Well because modifying a FM is really complex, every slight change you make affects not only the flight domain zone you want to correct but the whole (cruising speeds, approach speeds, turn rates, accelerations, transsonic times, FBW stability and oscillations, AP stability and oscillations, etc etc...) so yes, it takes time. We are releasing next week an update that will fixes things, without being 100% sure of having tested everything despite 15 testers each spent many hours finding issues and retesting after every change. So the update will be released to make the community happy, even if some new issues may be found afterwards. We are already planning another following FM update with more tuning. Thanks in advance for your understanding.

I just tried an empty aircraft (300kg fuel, clean) with unlimited fuel, and the temperature setting to the minimum allowed in Caucasus of -12.4°C, 21 december, midnight I managed to increase CAS by 3kts (from 86 to 89) then it decreased quickly to 60kts and I stopped the test. Any other trial with standard temperature (15°C) and at least 1T fuel and you immediately loose all your speed. TacView is attached. Tacview-20220713-164447-DCS.zip.acmi Conclusion That's currently not possible without cheating by modifying files. Reminder Cheating, for instance by modyfing aircraft mass, is feasible. You should only connect to servers with Integrity Check enabled. Even then, it may take some time (from a few seconds to one hour) for the server to detect it. That's why when it comes to claims about wrong performances, only a single player TRK file, that we can replay on our side, can be trusted. It's classified.

If you go full vertical, you will gain altitude... as with every aircraft in DCS or IRL. Now if you say you can go full vertical and gain speed, in a non-modded M-2000C version on DCS, you will need to bring some proof (a replayable single player .trk file) because otherwise that's likely defamation. We are not responsible for poor BFM skills and defeats in dogfight

It would be interesting to have the tacview, there is not enough information here. Especially the variation of Em (aka Ps). If aircrafts are descending and/or descelerating, this changes a lot. The M2000 is known to overperform at very low speeds, this will be adressed in an FM refresh. Now, the viper is doing a very bad job here. The mirage is on the deck and has no energy, if the viper goes vertical and dives the mirage is toast. He will never recover energy fast enough to avoid it. Side note I see a lot of debate about very low speed turn rate. At that altitude and low speed turn rate isn't depending much on drag anymore. It's mostly limited by turn authority which becomes lower. This is why a brick with a big engine and vectored thrust can achieve any low speed turn rate. In that specific mirage case the aerodynamic instability does all the turn work (and not the elevons). Very high turn rates can be achieved at constant speed, if you allow the aircraft to loose altitude. But that's not sustained turn rate (Ps<0)

You need to have the hotas CNM selector in N (neutral) in order to jettison. C (Cannon) or M (Magic) close combat modes override the jettison selector. A common mistake is going to M mode for jettisoning the Magic.

Hi, Do you know this mod? Its purpose is defining new binds in saved games, allowing full customization without having them erased at every update.

Could you guys avoid starting an argument from a video where a guy counts a full turn as 260° and count seconds in his head? Use the module by yourself, measure turn rates by accurate and scientifical means YOURSELVES, and we talk Errare humanum est, perseverare diabolicum

The Mirage is historically the first non FC DCS module. What is hasn't always been It is a matter of implementation. "Simply" is another story

Is your axis a springloaded axis or a stable axis? Yes, the encoder is a bad idea, you need continuous press while encoder send pulses. The thing is really designed to be used with a 3pos springloaded. Any 5way hat can do, and you still have two other directions for other tasks. Or a 3way hat.