Sarix

Hi BN, I am aware of the correct take-off procedure - I was told in the forum post linked above that trim reset logic happens when the gear handle is placed up, which is not the case here (trim reset happens when flaps are put from non-AUTO to AUTO after weight-off-wheels), hence the post. Seeing that it is marked correct as-is I'll take the team's word for it. Cheers.

Moved my extension on "weird stuff" to a separate thread. Cheers.

This could be tangentially related to https://forum.dcs.world/topic/345045-fcs-wow-mode-after-fm-update For the Hornet, when taking off, 22 degrees of ANU is commanded mid-takeoff roll, and after weight-off-wheels one can find the stabs being commanded to 19 degrees NU well into 30 degrees of AoA. I did not include further moments of the track, but after 19 degrees of NU STABs is seen, the STABs would be "eased off" to ~11 degrees NU, and is immediately fixed or at least alleviated by (via keybinds) cycling the flaps from AUTO to HALF/FULL and back into AUTO, with a different resulting STAB position. I have the FCS page on my right DDI - those of you watching the track should be able to see it as well. Hornet AUTO takeoff flaps cycled.trk One should find the stabilators returning to approximately 3 degs NU upon cycling the flaps in the track attached. Throughout the process the gear is not raised nor did the airspeed exceed 250 kts. To test the reset logic itself: I have attempted a normal takeoff, STABs are commanded to ~14-15 degs ANU. After WoW I put flaps to AUTO, gear handle up, and then put the gear handle down again. At ~180kts IAS, STAB is at 2-3 degs NU. Hornet normal takeoff 180kts.trk The same occurs without putting the gear handle up in the first place. Hornet normal takeoff no gear-up 180kts.trk Then - a second takeoff with flaps in AUTO. The aforementioned 22 degrees ANU STABs is observed with aggressive pitch-up tendencies. I used full stick forward to try to counter this tendency but there is not enough authority to counteract this. Cycled flaps from AUTO to FULL and back to AUTO. No gear up, ~180kts, STAB is also at 2-3 degs NU. Hornet AUTO takeoff 180kts.trk A third takeoff with flaps set to FULL would still have the STABs on 22 degrees ANU, but when flaps is put back into AUTO without gear up, STAB is observed at 2-3 degs NU at ~180kts. Hornet FULL takeoff 180kts.trk The gear handle appears to have no influence on the trim reset logic. Putting flaps from non-AUTO to AUTO does. Cheers.

Thanks for the investigation Ahmed! I'd like to extend on the "weird things" part, specifically taking off with AUTO flaps. The Hornet would aggressively command 22-degrees ANU for the stabilators starting at approximately 100kts and does not attempt to correct itself after weights are off wheels, leading to... amusing behaviors (continued pitch-up). However the FCS will correct itself and gradually revert stabs to 0 degrees if flaps are put to either HALF or FULL and then put back into AUTO. Tracks attached - hopefully it would be of use. Cheers. Hornet flapsup takeoff then flapsdown.trk Hornet flapsup takeoff.trk

Here's a track just in case. overlap.trk

As titled. When making a designation on the A/G RDR page for weapons delivery with the display frozen, when flying to the release with AGR as the ranging source the range number would show at the top of the display, overlapping the "FREEZE" text. Screenshot attached. Currently away from computer sadly so tracks will have to wait. Cheers

Reopening the thread. It appears that the HAS timer would reset itself after some seconds (in the tracks attached sometimes as long as 18 seconds sometimes as short as 4). Scanned targets appear to "jump around" the HAS page when scanning resets and there are multiple targets in seeker FoV. First track (HAS timer) shows the timer resetting itself. Second track (HAS jump) - I apologize for the length, it's a bit of a flight (~3 minutes?) - shows scanned targets jumping around the HAS page. Third track (HAS multiple) shows the HAS having issues scanning targets every reset - I had three or four SA-11 sites spread across 5nm firing at me and HAS could only detect the first two. Cheers. HAS timer.trk HAS jump.trk HAS multiple.trk

Much appreciate the insight. I did not "test" per se I just loaded the Mi-24 with some armaments (for weight) and tried to go full stick aft at ~200kph IAS and around 500m, at around 9-11 degs of rotor pitch to see if I could send myself into a deep stall. My impression prior to the patch was that if I go stick aft too quickly it sends the helo into a deep stall which is different from what I was seeing in this patch. Hence the confusion and the post. It seems that the helo is now much more "lenient" in the stall department.

It seems pretty hard now to push the Mi-24 into a deep stall. In my recent flights I can go full aft on the stick without much issue. How accurate is this compared to pre-update stall behaviors where you'd be "stuck" in a nose-up deep stall for a while? Cheers

Here is a track, hopefully it helps. It appears that when clicking on MSN XFER with XFER ALL, the jet would change to XFR WPN and transfer instead. XFER ALL.trk

It was indeed about the rotor disk proper. But the answer is appreciated too! Do you think the rearwards tilt of the rotor disk (relative to the ground) is related to this?

Attached is the Ka-50 hovering on a calm, no-wind day and the rotor blade disk seems to be tilting at approximately 3-5 degrees. What could be causing this *much* tilt?

Hello all! The F1's engine is scheduled to go to overspeed mode (~8,900 RPM) once it hits Mach 1.4 and afterburner should not be disengaged above this mach number. What is the technical reason behind both the overspeed mode and the A/B limit?

As titled. When two players are in the same aircraft, either player in either cockpit using HRM would cause the player in the other cockpit to see their game performance drop rapidly, eventually leading to a freeze or a DCS crash. The player using HRM however appears to not suffer from any performance issues (unless, of course, their pilot's client crashes and they are forcibly returned to spectators). This happened to me when I was using the multithreaded client. Exiting HRM mode before the other client crashes would restore performance for the other client. Freezing the HRM image however does not help. Logs zip is attached but it appears to be corrupted. dcs.log-20230702-073444.zip

Awesome. Are there plans to include this (the orange tape being the time-of-flight indicator) into the manual in the future?