Galinette

You can right now switch to OpenBeta and have it working. Stable is discontinued at next update, and there will be a single version from now on (which will be similar to OpenBeta without the name)

Being skeptical is a good thing. We have the duty to be skeptical on any non sourced anonymous user input on a forum (that's why I am now), especially given how DCS users are emotional about things. Mirage 2000 data is classified, so you will not get any figures on this forum. Then please give the same attention to the following statement by someone from RAZBAM (me) "The M-2000C FM is good enough to be used in current FF module" If both FMs are good, the +30% afterburner thrust increase between M53-5 and M53-P2 might explain a lot of things. Thanks...

Could you cite your sources please? There is as far as I know a single source telling this, the 1988 IAF tests that are story-told by a MiG-29 IAF pilot. If that's your only source, "plenty of comparisons" and "plenty of pilots" is dishonnest, so I'm interested if you have more (but I doubt as this kind of exercises has been extremely rare). That story is told by a MiG-29 expert, so maybe it's biased? Pilots are sometimes very biased (and this includes Mirage pilots). Then, it's also known that in 1988 the Mirages 2000 had the old M53-5 engine which has very large thrust difference (-15% dry, -30% AB, from memory, to be confirmed) with our own M53-P2. And finally, if this was true (Citing the articles : "The MiG-29 outperforms any 4th gen aircraft in instantaneous turn rate"), the MiG-29 DCS flight model, from the FC3 era, is maybe not 100% accurate, if we do the same comparison between the DCS MiG-29 and other DCS 4th gens. We don't do flight models by reading stories and trying to reproduce them against other DCS modules, but by focusing on the aircraft we model, and only this one.

Additional keywords : "td" for the TD/TOP feature (acceleration cues to achieve time to target) "rho", "theta", "dnorth", "deast" for direct BAD delta coordinates instead of using a marker BAD

The front seat light was fixed for next update.

Thanks, I will ask about that light to SMEs. I was not aware about a light in the front seat, but only the back one. So remember : OBSTACLE AHEAD is an alarm. Danger in the aircraft path. This requires a flyup. OBST right/left is a caution signalling an obstacle not directly in the aircraft path. This advises you to avoid turning on that side.

I will recheck the INS and UPDATE sync part more closely.

I'm sorry, INS and MN drift are synchronized. Updates too. I'm the developer and I tested again (Using a HRM map cursor UPDATE) There might be some issues, and if you find some, please document them using a video from both seats.

OBST Warning light and OBSTACLE AHEAD are for an obstacle ahead, ie a close danger in the direct aircraft trajectory OBST HUD cues mean there is an obstacle to the right or left of the aircraft trajectory. Not ahead. It's a cue to avoid turning right or left, if you still do so it could turn to an OBSTACLE AHEAD warning. In Auto TF, it will generally not put the aircraft in an OBSTACLE AHEAD situation unless with late detection. And it does reduce the turn rate automatically for left and right OBST cues. Please ask in the general forum first, that's likely not a bug that you are encountering.

That's not correct. INS and MN drift/update are synced. Unless there is a recent bug

Hey, you are right, the change did not make it to the patch notes. Thanks for notifying!

Could you provide a log file?

Switching between INS and EGI don't change anything to altitude. Doing INS fixes don't change either the waypoint or the known aircraft altitude. There is something misunderstood here I think, yes a track would be helpful

No, it's even sometimes even worse. I've seen three digits dead one month ago on an aircraft which was leaving.

Yes. Then, the effect of ECM is actually modeled in the radar itself, not the jamming module, which only tells to the game if he is emitting or not (with a power value) What may happen in the Mirage 2000 is it's an auto jammer, which means it will decide if the jammer emits or not based on threat properties (type, range, etc...). Some radar models have trouble with jammers that switch often. That's the only thing which could explain why the Su27 and Mirage 2000 jam differently, because their powers in game are exactly the same. If this is the case, then you should not see a difference on other radars. Also try on the mirage side using the panic PCM jam mode which is continuous and will behave exactly as a Su27 then. Also, the above only applies for human players. An AI will have the exact same jamming effect whether it's a Su27 and a M2K

That's a misconception on your end and most likely an observer bias. What is "stable" is the version number. By being on stable, you get updates less often, which can be a good thing, for instance if you are a tournament organizer, a server admin, use DCS in a professional environment, have a slow connection and updating is difficult, etc... The program itself, is not more "unstable" (aka bugs) in openbeta, it's even often the opposite as patches come faster. using stable means : I update DCS every about 6 months. openbeta means : I update DCS once a month or more. Nothing else. The "stable" labelling is a bit misleading. If you don't have strong restrictions to run on 2.9.1 (such as relying on a specific server only on stable), there is a strong incentive to go openbeta now.

OB (2.9.2) is currently significantly more stable than stable (2.9.1) 2.9.1 had a lot of new features introduced

Confirmed, the stable version has a bug related to DLL version check happening with the new year. It has been fixed already so OpenBeta is not impacted. We will ask ED to release a patch ASAP, in the mean time you might switch to OB which is more stable overall than 2.9.2 AFAIK

The graph starts at M1.13, which corresponds to the VNE of the real aircraft as far as we know (750kts at sea level)

The ECM power of the M-2000C is exactly the same as a Su-27, I just checked inside the API reported values.

@Miro You are writing in your first post that you have constant 60fps, but "feel" 30fps. And in your last video, TFR definitely has a visible impact on CPU use, but barely any effect on frame rate (it only jumps to ~55fps a couple of times). If you are worried by the CPU use chart increase, it's perfectly normal, TFR has to do a lot of terrain & object analysis to function. There really is no issue. Using 16 radar threads is definitely not a good idea unless you have much more cores. Using a value of 4 on a recent CPU (12 cores or more) is definitely a good start. @truebrit in your case, a FPS drop from 60 to 15 with TFR is really an issue. I will investigate, could you send a very short track file showing the problem? What is your CPU? How many radar threads do you have in F15E special options?

It's a feature Dead segments are actually very common as they are old filament bulbs. You can test it with by pushing the brightness knob You can adjust the occurence in special options. More effects like this to come

Need to check what actually happens. But having two aircraft at the same distance, and with little angular separation, will cause wrong IFF correlations, and that's a feature. IFF is only able to sort contacts by range, there is a very very poor angular resolution (several degrees) To make a TRK, just quit the mission and save track from the debriefing window. In order for it to be useable for development, the shorter the better, so best is air spawning in the desired situation and do the radar/iff test immediately. It's also possible that TWS chose to make a subtrack as both contacts where basically formation flying.

What's the targets separation? Could you provide a short trk?

Yes, it seems like the grass zones of the airport are tagged as runway ground, and this is how we compute the ground reflectivity. Will be investigated, but might be tricky to solve on the radar side, it would be easier to have ground type flagging more standard across maps