Search the Community

Up at 45000, full burner, I encountered some interesting autopilot behavior: 1) Coupled mode is fine until it hits the selected heading, where it oscillates, making corrections in roll back-and-forth for more than a minute before gradually settling into the heading. 2) This behavior does not exist for Heading Select, where the autopilot behaves predictably, steering to its heading accurately without oscillating in roll 3) Engaging BALT at 3 degrees nose down causes such a severe vertical oscillation, centered on the horizon, that the aircraft nearly departs. I have not tested to see the effects if left on, but I will. Structural failure seems likely. It's that violent. 1 and 3 are so extreme that, if the real aircraft were to behave in such a manner, there'd be an ops bulletin in the latter case (like, "don't engage BALT at high altitude within normal parameters") and likely a software update in the former. Ship was at half fuel, 6 AMRAAMS, 2 Sidewinders. Anyone else tried these things with the new FM? Thoughts? I'll repeat this tomorrow and attach some vids if necessary

This mod provides a basic autopilot for the Mossie - It passes IC but works in single player sessions only: https://www.digitalcombatsimulator.com/en/files/3330835/ Enjoy!

As the title says, this mod provides a basic autopilot for the Spitfire - It passes IC but works in single player sessions only: https://www.digitalcombatsimulator.com/en/files/3330835/ Enjoy!

When using the autopilot, e.g. attitude hold mode in the Flanker, shouldn't it give you a more or less trimmed aircraft when you deactivate the autopilot? In its current state, autopilot deactivation can cause radical attitude changes as the autopilot either doesn't use trim at all to maintain a certain flight regime, or it reverts to the trim settings before autopilot activation. My understanding from (western) real-world aircraft is that AP uses trim to maintain attitude and the a/c will therefore maintain a commanded attitude when you deactivate the AP.

patches 2.7.4.9632 and 2.7.4.9847 have introduced various fixes and tweaks to controls, trim and FM. And for the most part they seem to have been very sucessfull (fe the problem with "overtrim" are far less and the sound feedback is also very helpfull). The Shaitan-Arba is now also much more controllable at low speeds. Especially noteworty in a positive way - VRS does no longer suddenly and fatally happen, the soundmapping for RBS, VRS, max-envelope aso is now a completely suitable indicator. What seems to need further attention is the following though: the feel of weight and mass now seems reduced, and the Hind is too twitchy in various envelopes (to the point where one seems to "stir" the cyclic aka the joystick) while hover transitions are now far more controllable the hover itself seems to have become very twitchy even in low-weight and zero stress conditions the wheels now "soapglide" even more in almost all terrains, even with collective on zero, rpm throttle down, and wheel brakes locked I have included a track from the remastered-for-hind huey-campaign (ty for that excellent scenario to really control the Hind @Bailey) where this can be seen. I also could directly compare the asset behaviour to before the patch (as I had just flown that mission before both patches). Twitchy hover: during takeoff at final landing at "Madrid" at the end "soapgliding" of wheels at rolling landing and taxi at Senaki-Kholki on the pad at "Madrid", with various test of AP channels, locked wheel brakes, applied wheel brakes, idle rpm, zero collective, diverse trimstates "rudder" (tailrotor), "heading" AP channel on/off slights osciallations during flight in stable envelope with no input entire flight various attitudes, crabbing during transition during speed hook or forward reduction notice zero control input (control input indicator up entire track) notice "pulse" inducing oscillation with slightest inputs as if input signal is registering on/off For the problems describe above, also notice how for the most part non-pilot induced oscillations seem rock stable while any attemopt to correct them with minor cylic, minor collective or general slight(test) peripheral input seem to surge the oscialltions or the twitchy hover behaviour (especially noticeable at the end of the track, when I almost crash myself at "Madrid"). The widely reported "overtrim" or "input overshoot when pressing trim" is reduced but still noticeable. For the passer-in-glancing, please focus on the bug behaviour, my bad flying is a given having to be seen as "baseline" . Trackfile as google-drive link as filesize exceeds attachment limit: https://drive.google.com/file/d/1u71lvSaImScYA2f3zgynpGPhEwe5roFX/view?usp=sharing Dxdiag file attached for good measure. DxDiag.txt

Before I type my bug report - a positive note. The latest patches have introduced an enhanced fidelity if the collective blade pitch is changed either for the airframe reaction and orientation. Not only the nose or airframe vector but also the entire tilt and drift change in a very fidelic way. This is especially noticeable if the КРЕН and ТАНГАЖ dampener channels of the ВУАП-1 suite system are in use, and the НАПРАВЛЕНИЕ dampener channel and the высота maintain channel are turned off. This is a very positive sign and I hope this is a small symbol about the intent to have a fidelity gradient for this module this iconic rotary frame deserves, Now for the less positive - aka the bug report. Unfortunately the situation described in this bug report: and especially in its mysteriously vanished parts have worsened and are now clearly a more systemic issue that is a culmintation of various (in parts acknowledged and already being worked on in insularity) issues that cause cascading issues. The missing weight (mass) and inertia is leading to more oscillations, especially with a "light" configuration (less fuel, light munitions load) that is itself problematic during a terrain final (hover) on non-flat "terrain" surfaces. Clearly noticeable is now that the DCS trim settings ("control helper" or "special tab" options) of "default" and central position are NOT reliably working during any instance, even within the same DCS client session. Further the INGAME settings of "AP trim" (trim button setting) and "manual trim" (fe coolie hat) seem to cause cascading issues in the game code, resulting in more and more offsets to the point that even a full reset result in progressive input necessity and corrections (cyclic stirring). On top of this the constant exception catcher events of the DCS proprietary settings result in more and more input necessity during a longer flight (no reinit of airframe and or world load). Another sympton is the drift-gauge suddenly showing random indications, while the player can notice the airframe behaving completely differently. Sometimes this even results in mirror indications of what is going on or the gauge switching from random left/port-right/starboard indications with the airframe having a TVI in an entirely separate third orientation. On top of all of this there seemingly is a threshold where - again as reported before - VRS seems to suddenly occur like a trigger event (the attentive enough can even see the airframe frameblink before the VRS effect kick in as if an ingame event was triggered). Where before VRS might have been recoverable, it now is an unrecoverable disatrous quicktime event.. even if this even occurs already on the ground or at 1-2 m AGL. More disturbingly this event can occurr in a stable hover and a sinkrate of -1 or -2 on the VSI (radar alt on) and the Doppler-hover system working. So apart from the bug state in each part mentioned, there is a cascading interaction on a systemic level. If the results are caused by this cascading interaction cannot be judged by an enduser and it evenly shows the possibility of an unerlying fundematal source issue causing said interaction or even gradients of the insular bugs in each keylog submodule. Which could be the clearly hardmodified weight variables, the currently missing physicalized inertia, anything. That there IS a bug can not only be noticed by the osciallation issues, the VRS states, the inability to trim at a certain point (or the "trimlock bug) but also by clear exception catcher and outlier events. Example: if these bug in any subset have started occuring.. an RBS effect will result in the airframe rolling at 3-4 times the speed it would normally RBS roll to the right in a comparable, replicable scenario. Test scenario: Singleplayer and multiplayer with repeatable scenarios in direct comparison to prior bug notice x52 sets magnet modded, spring modded, zero signal stutter, controls cleaned (not double binding of active peripherals) trim setting (DCS proprietary) "central position" including "rudder" ingame settings as described above current workaround of constant "reset" and retrim from zero applied Dxdiag irrelevant but attached. Trackfiles: 2x singleplayer, direct comparison to prior scenarios, chosen because of drastic showcase and 8+ repetitions and chosen because of lean trackfile. https://drive.google.com/file/d/1ojlq_M56d2skyne8_9QmqmFvgFqcHZE2/view?usp=sharing https://drive.google.com/file/d/1ok5VXQnXas7UBmTQgEIrHr_4wcDA3e91/view?usp=sharing DxDiag.txt

Hi Tried flying a radial on a WP in F18 (with autopilot). I joined the radial about 60 miles out. All the way in, the AP keeps hunting the course. In the start it was about 3 degrees to each side. It never became steady, It was on a MP server, don't know if it matters. Should be easy to reproduce. Good work ED.

Concerning the problems that have occurred after the newest patch with the Autopilot not working, or not working correctly for users with a FFB stick, I was wondering whether there is any description of how the autopilot is supposed to work with FFB sticks. For Example, should the stick be centred to the neutral position for the AP to engage or should the stick be aligned with the trim indicator on the controls indicator? I think this could greatly help in reducing a lot of confusion that exist around this topic, and lead to more informed and concise description of the occurring problems.

I just got a VKB Modern Combat Grip (MCG) and I'm trying to figure out the difference between the button on the top left labeled "AP OFF", and the main trigger labeled "AP DISENGAGE" and how it relates in-game to the different autopilot commands in DCS. I've only flown the SU-25T and P-51D so I'm only somewhat familiar with the autopilot system for the Russian plane. 1. Is "AP OFF" intended to turn on and off the entire autopilot system? 2. Is "AP DISENGAGE" on the first stage of the trigger intended to be the temporary override only when held in? And upon release, the autopilot system is turned back on? Any clarification or recommendations on this would be very helpful. Thanks!

when in BALT, shouldn't the autopilot correct the aircraft's vertical path to maintain barometric altitude, in case the altimeter barometric setting is changed? at least below transition level? because it doesn't. e.g. if you fly at 1000ftMSL, engage AP-BALT and then increase your baro setting, the altitude indication will rise. my understanding is that the autopilot should start descending to catch the 1000ftMSL. but it seems the hornet's AP is currently set to a fixed reference qnh. is this correct?

Hi Everyone! I've looked but I couldn't find anything. Sorry if this is double post. SOMETIMES when i set up ALT HOLD the plane starts to dive and never recovers, even if the starting attitude was going UP. I tried many different ways but i can't understand what triggers this behavior. I saw it mainly in MP. By the way, i always press NWS when vertical velocity es almost 0. In many cases I trim the plane to 0 to check and then the nose diving start. Please let me know if this has being pointed out. Thank you

Good evening pilots, since i couldn´t find anything about this, can anybody tell me how to setup a mission inside the mission editor, so that my flight starts with the autopilot engaged? Is this even possible, with triggers or advanced waypoint actions? Couldn´t really find an answer, and i´m sure there are many experts here Thanks guys for your help, cheers Peter!

This as bothered me ever since the "Autopilot disconnect" master caution was implemented, not sure why its taken me so long to report, but here we are!! Basically if your using CPL or Attitude Hold (maybe others too, these are the two in the track), and you manually disconnect on the ufc, the AP actually stays ON even though theres no dots, and you can feel the plane fighting your inputs, as though its on AP, so you have to quickly yank the elevator in order for the autopilot to disconnect, you get the warning, then your controls are free and clear. Unless theres been a step added im unaware of, this doesnt seem right?? autopilot error.trk