Akiazusa

Hi, in a night mission,I noticed the backlights for the rear panel seems not working. (I mean this switch and knob by the way) No matter how I adjust the knob or turn the switch,it always looks like this,only the WCS BIT lights up in the dark. I searched some videos online and I think maybe it should look like this when it's turned on?(pic from old BS2 video) Here is a short track.Ka50 back panel lights.trk Also here are my graphics settings in case if they are useful. This one may cause some headaches for cold start during night,hope for a fix. Thank you.

I guess I'm not the only one who got confused a lot when trying to use vertical navigation VNAV on the shark. It seems that the VNAV cue which is circled in the pic above,only wokrs when the waypoints are created using mission editor. If the waypoints are created in game using ABRIS itself,the VNAV cue will never follow the VNAV plan u created,it will just stay(guide u) to the aircraft spawn altitude. Or if u use the ABRIS in game to change the VNAV altitude of waypoints which u created using mission editor,the VNAV cue will still follow the plan created by ME and will not affect by the changes u made on ABRIS. 2 tracks: The first one,waypoint is created using ME at 500m,and the VNAV cue guided the aircraft passing it at 500m as expected. Ka50 VNAV using Mission editor.trk The second one,waypoint is created using ABRIS at 500m,and a VNAV plan is created using ABRIS,but the VNAV cue didn't follow the VNAV plan,and keep guiding the aircraft to the ground. Ka50 VNAV without using Mission editor.trk Not really a big deal,but since all other functions of VNAV pages and supages are all working as expected,only this VNAV cue on NAV page/ARC page/HSI page is not working.so anychance for a fix when there are free time? Thanks. Ka50 VNAV without using Mission editor.trk

It's known,and the fix file should be already on ed's hand 2 month ago,it's actually a new feature,which should show a red PCM on radar screen when ECM is working ,but sadly ed only pushed parts of the new files in the last update,causing the problem,according to the discord.

It's known,and the fix file should be already on ed's hand 2 month ago,it's actually a new feature,which should show a red PCM on radar screen when ECM is working ,but sadly ed only pushed parts of the new files in the last update,causing the problem,according to the discord.

The patch should including a fix for the alarm panel lights test switch,and a new feature which will show a Red "PCM" on the radar screen when the ECM system is working. Now only parts of the patch files made their way into the game,causing a Green "PCM" shows on the radar screen and is always there no matter if the ECM is working.

Clearly the Mirage 2000 dev is still working on the module,according to the discord,one patch including some fixes and new functions to the M2000 was submitted one month before the September update,but u guys didn't include it in the September update.So that's an accident,okay,and we wait another 6 weeks to see if it's in the October update,and in this update,u guys did includes their patch,but only parts of it,and break the module. WHY? So we have to wait another 6 weeks? come on

IIRC that might be some leftover things from the old version of the Mirage,where due to lack of classified info,something was implemented not as accurately as the current version,and they got updated/fixed/reworked after the collaboration between the Razbam and the French Airforce As razo said,binding the MICRoB trigger second stage is already enough. you can also bind the first stage if you what to use the virtual gun tracers. Other triggers are not used,just leftover bindings,they don't have functions.

Might because of the cold weather in the CAMPAIGN mission,try turning on the pitot heat,giving it sometime to warm up,finally resetting the FBW by the reset switch,it should fix the problem. (If you set up a cold weather in the free flight mode,you will most likely end up in the same situation.) Also check whether your dcs world is up-to-date,there was a bug in the previous version of the mirage causing problem during crosswind take off,but it should be fixed already.

I think this bug has already been fixed in the last update...... I can take off with 25kts(the crosswind limit of m-2000c) crosswind now with no problem. It has already been fixed,but just not mentioned in the game change log. Also I think the reason of Mirage 2000 is still getting update after the mess is because

Have you checked these in your Axis Assign settings? Make sure they are assigned correctly. Or maybe you can try deleting the M-2000C folder in C:\Users\username\Saved Games\DCS.openbeta\Config\Input then run the game,let the game recreate one(which should reset all input settings related to Mirage back to default),and see if it fix the problem.

Maybe try doing a repair? I'm playing the Mirage on 2.9.7.59263 and TrackIR works fine on my computer.

If the GPU is connected,some systems which are powered by the QRA bus will still be powered after after you clicking this switch(like the INS system for example). Since it's a new feature been added recently,there is little info about it in the game manual,I'm not sure if it's normal for the can't clicking it back part,maybe there is a safety lock or something,but if you start the engine then(QRA style start up),that switch will jump back automatically and your electric power will be restored,the INS will be ready since there is no need to realignment, and you are good to go.

This is because when the radar of the Mirage is scanning with 2 bars and 4 bars selected,those bars are actually overlapping each other a bit,the overlap of different bars can lead to duplicated contacts. You can use 1 bar search to avoid this.

IIRC there is no HUD display of that aside from the circle around the G and D telling you the missile is locked or not. But a continuous 650 Hz tone will sound if the missile autodirector is locked,otherwise the tone will be a 650 Hz chopped at 1 Hz. Usually you need to point the aircraft nose to the general location around the radar lock before firing the missile.

Hi, I've updated OP to reflect the data checking done for Cl-δA and Cn-δA, and listed the remaining issues that could contribute to each other.

All I see is unexciting things with super stable nose, and no sign of nose slice or sideslip excursions. That's why I filed a bug report about the absence of adverse yaw at high AOA. Rudder deflection limits and toe-in/out are completely irrelevant in my testing, since MSRM is activated and all the feedbacks in the control loop are removed. You basically have direct and maximum control of the aileron and the rudder. Those are called Departure Training Flight, and you can find the instruction cards from https://trace.tennessee.edu/utk_gradthes/2312/ NATOPS only have a shallow description of the FBW system. For a more thorough and deep reading I would suggest the following reading list: https://ntrs.nasa.gov/api/citations/19920024293/downloads/19920024293.pdf from page 83 https://trace.tennessee.edu/utk_gradthes/2312/ https://trace.tennessee.edu/utk_gradthes/2372/ This is an example of over-comprehension. The FCS do have a Rudder Pedal to Rolling Surface interconnect function, or rudder to roll crossfeed, similar to the Rolling Surface to Rudder Interconnect (RSRI), only that the logic runs backwards. This is to deflect the aileron in the same direction as the rudder input, and is only active above 13 deg AOA (Roll Function 39). Since it has a positive gain (RK10), it will never cause a negative roll as you described. The block diagram at page 101 of the NASA document listed above explains that in detail.

Hi, Just tested, if you try activating the MSRM at 40-50 AOA, you'll also get an opposite roll by the rudder input, while bypassing the flight computer.

If talking about spin recovery, this would be another issue. Acccording to yet another reference document https://trace.tennessee.edu/utk_gradthes/2312/ , the upgraded flight computer (which we have by the hornet version in DCS), is capable of killing yaw motion, even a slow rate spin. Since the computer is actually using the above mentioned adverse yaw, to actively drive the aileron and the differential stabs to oppose the yaw rate. If there weren't any adverse yaw available, I can't imagine how this mechanic can work. But anyways, this thread is about pure aerodynamics, so I chose to activate MSRM to bypass the computer.

Hello, I was talking about intentional falling leaf entry. A falling leaf is not the same as a spin. The entry procedure is described in the tennessee paper: MSRM Falling Leaf Entry: 1. Stabilize at wings level, 0.5 IMN /40K (145 KCAS). 2. Select spin recovery switch to RCVY to enter MSRM and reduce power to IDLE. 3. Establish dive angle of approximately 20 degrees. 4. Smoothly apply full aft stick and hold. 5. Apply lateral stick to generate sideslip (some side-to-side cycling may be necessary to generate largest sideslip). 6. Neutralize controls. Falling leaf motion is characterized by large sustained oscillatory yaw rate motion with approximate 5 second period. Allow motion to persist for two cycles or until 25,000 feet altitude. 7. Recover by selecting spin recovery switch to NORM and neutralizing controls. Falling leaf motion should be damped promptly after CAS is enabled due to the sideslip rate feedback and other control law features incorporated in the upgraded flight control system. See if you can generate enough sideslip to initiate an in-phase yaw and roll oscillation, just like the one in the video.

In addition to the control surface effectiveness discussed earlier, the yaw static stability, also known as the Cnβ parameter, likely plays a significant role in the insufficient sideslip excursion experienced in the track file. As Cnβ is expected to become negative above 30 degrees AOA, the aircraft would naturally tend to diverge from its original zero-sideslip state once sideslip is initiated. This characteristic should be contributing to the difficulty in establishing and maintaining sideslip during maneuvers at high AOA when MSRM is engaged, that all the feedbacks are removed from control loop. Still from NASA: Another track of attempting to generate large sideslip, but any sideslip excursions will soon reduce to zero, as if it's statically stable: F18 MSRM sideslip generation prolonged.trk

If anyone succeeded by using the MSRM falling leaf entry procedure please tell me:

Hello, But I'm not seeing much adverse yaw in the track file. While I appreciate the confirmation that the underlying aerodynamic data is correct, there seems to be a disconnect between this data and how it is actually translated to roll rate and yaw rate in game. In the track, when I'm testing with a full right stick at 40-50 AOA with MSRM activated, I'm expecting the nose to slice to the left, but all I got is a roll to the right, and there's not any perceivable yaw motion. If you consider how the spin arrow works, it directs the pilot to move the stick into the spin direction. This is using adverse yaw to stop a yaw motion. But how can it stop a spin if adverse yaw is very weak like what is shown in my track? From another reference document https://trace.tennessee.edu/utk_gradthes/2372, it says in the MSRM falling leaf entry procedure that: "Apply lateral stick to generate sideslip (some side-to-side cycling may be necessary to generate largest sideslip)." This is what I actually did in the track. But as you can see there's not much sideslip generated that can throw me into a falling leaf.

This report details inconsistencies in the DCS F/A-18C Hornet's flight model behavior at high Angles of Attack (AOA), especially the stability and controllability derivatives, comparing public wind tunnel data by NASA, and other papers. Issues: 1. Minimal Adverse Yaw: At high AOA (around 40-50 degrees), the aircraft exhibits minimal adverse yaw during aileron deflection rolling maneuvers with MSRM activated. This is unrealistic, as real Hornets experience significant adverse yaw at these AOA due to asymmetric induced-drag generated by both the aileron and the differiential stabs. 2. Excessive Roll Control Authority: At high AOA, the ailerons & differiential stabs appear to retain an unrealistic amount of roll control authority. Real F/A-18C Hornets experience a reduction by more than a half in roll control effectiveness at high AOA compared to those at 0 AOA, according the Cl-δA chart from NASA. Note that this also doesn't include the contribution by the differiential stabs. 3. Excessive Yaw Stability: Check post below. 4. Lack of departure quality: There's a lack of nose-slice and sideslip excursions that can result in a falling leaf OCF. Supporting Evidence: The report "AERODYNAMIC PARAMETERS OF HIGH-ANGLE-OF-ATTACK RESEARCH VEHICLE (HARV) ESTIMATED FROM FLIGHT DATA" (NASA TM 202692 with a link https://ntrs.nasa.gov/api/citations/19900019262/downloads/19900019262.pdf) provides real-world aerodynamic coefficient data relevant to the F/A-18C. Specifically, the following parameters are crucial: Cl-δA: This coefficient represents the rolling moment generated by the aileron deflection. A decrease in this value at high AOA signifies reduced roll control effectiveness. Checked by ED. Cl due to differential stabs: Not included in the NASA document. But worth checking. Cn-δA: This coefficient represents the yawing moment generated by the aileron deflection. A positive value at high AOA signifies adverse yaw. Checked by ED. Cn due to differential stabs: Not included in the NASA document, so the total amount of adverse yaw moement should be higher than a single Cn-δA. Cn-β: Check post below. The data from this report can be used to compare with the current flight model's behavior and identify discrepancies. Testing Information: MSRM (manual spin recovery mode) is used for separate control surface manipulation. Turn on the MSRM switch to the rightside of the right DDI before testing. Thank you for your time and consideration. Video link: https://packaged-media.redd.it/uk23tvykr6uc1/pb/m2-res_480p.mp4?m=DASHPlaylist.mpd&v=1&e=1713337200&s=f9d5e02a332e95290ab60fe357a05fb884d866ab#t=0 F18 no adverse yaw at high AOA.trk

When interrogating modules like Mirage F1,they can for example,only using IFF responds from mode 1,2 or 3,to find a specific aircraft ahead of them if the mode 1,2,3 code is known,or even an enemy one who left the code on their transponder to the default number and forget to turn off mode 1,2,3 on his IFF transponder before entering the combat zone since mode 1,2,3 is not encrypted. For the IFF mode 4 equipped aircraft,you have to set the correct encrypted A/B code and turn the mode4 to on,or people flying M2000/F15E can't using their iff mode 4 to tell if you are a friendly.( the one who is being interrogated will get a waning light/tone from the IFF transponder when this happens)(if your aircraft don't have iff mode 4, they can still use mode 1,2,3 to find you if you tell them your iff code) For F-15E/M2000C interrogating modules like FC3 planes,or even F-16/F-18 interrogating others,it works like a magic IFF mode 4,this IFF mode 4 is always on and it's A/B code is always correct,you will always get a possible return as long as the plane being interrogated is on your side,no matter what code is set in the virtual cockpit panel.The only thing you need to worry is to turn on the transponder and the interrogator during the cold start. And of course the mode 1,2,3 is unavailable.

They are here, but some of them don't have the "3rd Party Developers" tag under their forum id.