Ahmed

Bumping this one as the recent changelog shows some fixes on AI launching issues fixed, but this particular one still remains and does break gameplay.

Together with this flares "bug" report, it is worth noting that the IFLOLS at the boat (the actual IFLOLS at the waist of the ship, not the overlay) is not lighting up now unless using CATCC. It used to work before, and it was how I guess most MP groups used it. Please restore the old behavior. Disregard, the actual IFLOLS at the waist of the ship si broken regardless of using CATCC or not. The meatball itself is not visible.

you know that the IFLOLS already has wave off lights intended for that effect, right? No need for made up flares

Enforcing the deck crew setting through the ME Mission Options setting doesn't work. After looking into the mission setting, the setting is being saved in forcedOptions under: when it likely should be saved (because it works if manually edited this way) under:

Posted in new thread, to cleanly report it, as this can now be easily reproduced. AI aircraft in multiplayer sessions are getting stuck in the catapult, if a player has launched off it before. Steps to reproduce: Launch off catapult Have AI (S-3B at least) try to launch off same catapult Dedicated server track attached. server-20241014-102904.trk

Same likely observation

Hi, When using the "SET ATC SILENT MODE" trigger on a supercarrier, ACLS won't work in the Hornet. Not even like it does in the Non-SC carriers. For any users NOT interested in using the AI CATCC (eg, 99.9% MP groups/users), can this be changed so that selecting "SET ATC SILENT MODE" reverts the logic to the Non-SC carrier one (lock on at 6nm)??

Hi, The SET_CARRIER_LIGHTING_MODE trigger is available in the ME but is not callable from mission scripts. Can this be added as a trigger function? Rgds

Exiting A/A mode with a STT lock results in the lock being broken if obtained from ACM submode In the attached track, the STT is dropped as soon as I exit A/A. This only seems to happen when the lock was made from ACM. It doesn't happen if the lock was obtained by other means (e.g., AACQ). acm.trk

can we get any update on this? Since a few months ago, AI aircraft (especially S-3) are getting constantly stuck on deck while hooking to the catapult. May be a more prominent issue in MP.

Noticed that I'm getting trackfiles on the SA for the Hawk missiles shot in the attached track, despite being in MAP (A/G) mode. hawk.trk

Reposting old unacknowledged report as the old thread is very outdated and messy. The yaw rate tone should begin beeping at 40º/s yaw rate, and the frequency of the beeping should increase with yaw rate until 60º/s where it becomes a steady tone. Observed outcome: currently in DCS the yaw rate tone is only beeping at constant frequency from 40º/s onwards Desired outcome: beeping starts at 40º/s, beeping frequency increases with yaw rate until 60º/s, steady tone past 60º/s Track attached. NOTE: do not confuse steady AOA tone (>35º AOA) in track with steady yaw rate tone. The steady tone in the track is due to AOA excursions above 35º, as I couldn't reproduce it while keeping AOA below 35º at all times. All yaw rate triggered tones in DCS are a constant frequency beeping that does not follow the description above. Source doc: NFM "Departure Warning Tone" (2.8.2.5) Video of expected outcome (1:35): yaw_rate.trk

Bumping this issue to see if it can get acknowledged

Most SLAM and SLAM-ER format options don't become available until selecting the unlabeled OSB 3 slam.trk

Let's try this again in an isolated thread... In the test conditions of the attached track, left rudder results in minor left yaw, right roll and heading increasing CW. No control surfaces other than rudder move in the FCS format, so this comes from a flight model issue. Expected results: left yaw (primary effect), left roll (secondary effect), heading decreasing CCW. rudder.trk

Didn't know about that paper, so that's definitely a great source of info for FCS related issues!. Regarding the quote, then that should be enough proof that yaw should aerodynamically induce roll, as in any other aircraft, and OP would be right (so, no "correct as is"). EDIT: just to see that this has been marked "correct as is" when OP has posted a video where he inputs right rudder and the aircraft ends up turning left makes me lose all faith in the DCS bug reporting process...

The issue here is that the control systems description goes into detail about several subsystems, such as the rudder limiter (that every fast aircraft has), or the mixing of rudder and aileron commands, but leaves a lot of blank areas as it does not specify the exact gains of each of these systems. Thus, any developer has to make educated guesses. There is however a misconception in the DCS community about rudder being a yaw control only. In any conventional aircraft, the rudder will induce roll. The rudder is even the most effective roll control at near-stall AOA. FBW aircraft are traditionally designed to fly like conventional aircraft (that is what every pilot is used to from day 1), so they normally won't just produce an isolated yaw reaction out of a rudder input (see example video of the real F-16 rudder test in the thread above). The only way that an isolated yaw would occur would be by applying opposite roll to stop the yaw from inducing a roll, and this doesn't happen in any DCS module that has ever exhibited this behavior (the old Mirage FM also coming to my mind). In the particular case of the Hornet, it is difficult to gather enough evidence to make a solid case about the rudder FCS implementation. It is, definitely, "odd" in several regimes, compared to conventional handling.

Hi, Prior to the FM update, the SRM was effective for most spins. Since the FM update, and particularly the last fixes, the SRM has become completely ineffective. See track: Entry to spin IAW viewcontent.cgi (tennessee.edu) (the 10.7 demo entry works better with the latest updates). Expected outcome is SRM spin recovery in 1.5 turns after OCF recovery actioned and stick with arrow (NFM "Spin Recovery"), quite close to what it was in DCS prior to the FM update. Observed outcome: the Black Sea. spin.trk

Not a Hornet but: Regardless of being FBW or not, aircraft are usually designed to fly like..... aircraft.

Not specifically ownship related, so it may not be the same issue that OP reports, but this happens all the time in MP with other humans. I haven't had time to reproduce into a short track:

Hi, 1. Set up a mission with me and a single group hostile 2. within 25nm head on, NCTR prints single group hostile as Su-27, trackfile gets a hostile HAFU, as expected. 3. Lost lock, separated North for a while to ensure that there are no trackfiles left 4. Turned South. As soon as I locked the previous group, it gets unexpectedly ID'd as hostile with print Su-27 while outside of the 25nm "NCTR range" Expected outcome: previous NCTR data is lost given that the trackfile has been dropped. The new trackfile needs to be within NCTR range/aspect to get a new print. Observed outcome: as per step 4 above, the new trackfile is still IDd I originally noticed this when reacquiring targets from a side aspect. The procedure above and the track are just a way of consistently reproducing it. nctr.trk

I don't think there is any clear definition of "flared landing" other than a landing in which descent rate is arrested prior to touchdown. There is a semi-relevant note about 500 fpm with asymmetrical stores, that could be a reasonable threshold to call something flared (although 500 is definitely on the "positive" side). Not to be confused with aerobraking, as mentioned above.

Hi, Running a test to investigate the issues trying to maintain on-speed during turns in not-auto flaps up operation, I noticed the following: 1. Started test by setting on-speed (~152 KCAS) 2. Entered turn, applied aft stick input up to maximum (limited to 3.55 inches aft in not auto flaps up logic, and also to a ~70% of travel in DCS) 3. Noted that pitch stick command and pitch trim bias allow to pull up to ~14º AOA (stab deflection up to 24º teu). All within expectation. 4. Accelerated to ~230 KCAS, trim untouched, entered turn attempting to capture on-speed. 5. Max pitch stick command won't achieve the previously trimmed 8º AOA, max resulting stab deflection is now only 6º teu. 6. Finally, accelerated to ~243 KCAS to force transition to auto flaps up logic. On transition, noted big AOA and pitch rate spikes as the FCS command transitions between 6º teu and up-to-24. (Note that these spikes will also happen in case of only applying the ~70%/3.55" stick limit mentioned above, and smaller deflections too -- this is not in the attached track, where I used full deflection, but the result will be similar) I'm unsure of what exactly is wrong here. The pitch stick command, trim bias, and aircraft sensor feedbacks are scheduled by airspeed in not-auto flaps up operation, and the gains and limits may benefit from some tuning. I couldn't find a reference to the 6º teu limit observed above at higher speeds anywhere. The aircraft seems to have very little pitch authority in the above test conditions with the current gains. I'd appreciate if you can run this report by your dev team FCS expert, as this particular test case may have slipped through them. FCS_PA.trk

Edited the title as this is not related to crossing from one elevation hemisphere to the other, it has some other cause. In response to your question: it is not, as evident in the track. It can be reproduced at near zero az/el from the emitter.

As per the thread tittle. It seems to randomly lose handed off target. EDIT: it is not related to hemisphere change, thus the edit. Added second non-maneuvering track where it also happens. Hornet_TOO.trk harm-nonmaneuvering.trk