Swift.

So when you have invert on, and you press your left pedal, the in cockpit left pedal moves forward. And when you dont have invert on, you press the left pedal and the incockpit left pedal moves forwards?

The main problem I have with this kind of logic is it banks heavily on us being able to 'deal with it' whilst we wait for a mission planner. Being realistic, I'm not expecting a mission planner for another 2-3 years at least. I don't want to have to be deleting points for the next 2-3 years. So yes there are lots of cool ways that could be cool in very specific situations, but the bottom line is this: Either get rid of it, or let us choose to get rid of it.

Instead of forcing more stuff on people, why don't we just have an option in the special settings: Preload All Unit Locations Preload Consolidated Unit Locations Do Not Preload Unit Locations Problem solved

Instead of fiddling around trying to figure out if you should have it inverted or not, just look at what your rudder is doing compared to what the pedals in the cockpit model do...

Interestingly I've been flying CPG with a human crewmate since the update and had no such issue. Although everyone who's sat in the back has had the issue.

If you dig though the FM config lua, you can get an idea of how many variables there are controlling the various axis of the SCAS and the holds. Notably for the collective axis, there are a lot fewer variables than the other axis, and even those with more variables still don't have enough for this type of control system. I mean, think about all the different values that could dictate behaviour in just the collective alone: -How much motion you need to input for the SCAS to 'help' -How fast the SCAS will move from damping to helping -How far the SCAS will go when helping -At what point it will return to damping from helping -How quickly it returns from helping to damping -How quickly the SCAS responds to transients whilst damping rate -How quickly the SCAS moves whilst responding to rate damping -How quickly the SCAS sleeves accelerate whilst responding to rate damping -How far the SCAS can move whilst damping rate -How quickly the SCAS responds to transients whilst damping position -How quickly the SCAS moves whilst responding to position damping -How quickly the SCAS sleeves accelerate whilst responding to position damping -How far the SCAS can mover whilst damping position -How quickly the sleeves decelerate as they near the limit of their authority (to avoid slamming into the stops at great clip!) There are more variables, but tbh I got bored typing. Hopefully the point is clear, there are a lot of variables that control even this single axis (and that's assuming its symmetric). It's not surprising that we end up with coincidental oscillations when one part of this system it tuned, because with only 3 variables everything is linked!

Yeah I guess that's fair, I was thinking more as a feedback thing to the community so we can get an idea of how certain bits of it should feel. I will say that I very much hope there is an order of magnitude more variables dictating the SCAS that we users just cant see. Because the 3 or 4 per axis we see in FM config.lua aren't really enough for modelling a control system like this.

My main complaint with the vanilla SCAS modelling is the very sticky feeling in the pedals. The cyclic damping and assistance feels fantastic to me however. And then of course, the whole collective SCAS alt hold thing is obviously still WIP. IMO. The first iteration of the Yaw SCAS was the best, when the breakout value was closer to the values stated in EDs manual. Since the addition of the 'heading hold' the breakout value has been increased to a ridiculous value (some 20% from trim, it looks like). Which it would appear to be a result of the heading hold having to function without all of the SCAS variables being defined yet. I'd be curious what you think of Scaleys FM edit tbh, because the heading hold in that is more powerful than vanilla DCS (to match Brads feedback IIRC) and the breakout value is much closer to the 3% stated in the manual, so now its actually possible to add or subtract less than a degree of heading whilst still having it able to compensate for quite significant power changes.

Its a bug based around EDs initial implementation of tail rotor VRS...... Luckily you can fix it using Scaleys FM edit as posted above (make sure you have the most recent version)

I wonder what one should do if they have a button on their own headset for the hiding of the IHADSS? In that case, the motion of letting go of the cyclic and raising your arm is already accounted for by real life. Which means you'll have double the delay ingame! Obviously I'm deliberately picking a ridiculous point. But hopefully my meaning is clear: extra features like this are fantastic and very much appreciated, but the control over their implementation should be down to the user. If ED can't dictate everyone's physical cockpit set ups, then why should they dictate the way the physical setup interacts with the digital world. It would as if DCS didn't have a way to bind your controls other than the defaults, or if there was no way to tune an axis.

The breakout value for the yaw SAS should be greatly reduced from the standard DCS to better match what is described in EDs manual and the real manual (the 10-20% breakout we see in vanilla DCS is too sticky) ALT hold is the unfortunate casualty of this fix. Because the FM file doesn't include enough variables to properly tune the FM, you can't fix the collective SAS behaviour without severely impinging on the ALT holds power. What ED need to do, is add wayy more values to the FM lua, so that you can better control all the variables in this 4 axis system.

So I think I can see what's happening here. It would appear that as you slow down the wind being experienced by the aircraft is suddenly removed. You start with wind from the left, blowing the nose to the left. If you suddenly removed that wind, the nose would consequently veer to the right (for the same pedal position). Now look at the video, at 0:29 the TSD wind goes from 5 knots from the left to CALM. And in that instant, the nose snaps to the right.

In case you weren't already aware, the hellfire racks can already be loaded empty. But 100% agree on the rocket tubes.

I agree, I'm just wondering whether the logic is to remove the pilots direct inputs ie to prevent the a foot spasm from jogging the yaw, or whether the logic is to dampen secondary inputs (ie bobbing up causing the nose to drift). Both of those logics would 'provide a rock solidly stable firing platform' however one of them would fly like DCS: Sticky and sluggish. And the other would fly like DCS used to: responsive and nimble.

It's fortunately only 'sticky' with the stock FM values. If you tweak them yourself you can get a experience much closer to that described in the manual. Which is to say, rock solid, responsive, a pleasure to fly.

Is the idea that the hold will prevent unintentional yaw (ie, changing collective, sliding left/right), but should in theory not impede pilot input noticeably?

I'm just reading the ED manual I'd love to fly with you, but I really just fly on our squadron servers nowadays. Maybe I'll see you applying one day

The 'heading hold' should disengage if the pedal displacement exceeds 3% from the trimmed position, so in effect it should be more of a 'dampens out torque changes and turbulence' than 'stops you from using the pedals'. But in DCS this disengagement number seems closer to 15-20% from trimmed. Which adds to this 'sticky yaw' feel that people experience.

https://www.476vfightergroup.com/downloads.php?do=file&id=629 Here is a mod to replace it with just a short beep, which is much more pleasant.

Alright perfect, and was this MC or just single pilot?

Can you go over the steps to reproduce that drift? I'm trying now in a mission and it doesnt look like its drifting.

Now that is interesting, because that could well be what's causing this.

Can we get one of those handheld IR pointers that pilots would use before IR pointers in TPODs were more common? It's probably more of a DCS wide wish, but actioning it similar to the flashlight would be ideal. ie press LAlt+M or something and it shines an IR beam wherever your mouse points.

Adding this to the report, again no track because 3 hour mission, but its very very clear what's happening here. It almost seems like the TADS position fixing is from a different source to the aircrafts. Makes me wonder if that INU drift bug we used to see is still 'exhibiting' in the TADS, even though we have no indication of it.

Adding onto this bug report, CMs deleted by one crew member are not being deleted for the other. Additionally it looks like if the number of units exceeds the max number of control measures, it will backfill as you delete them. Meaning you might end up having to delete hundreds of CMs each! ED, please get rid of this feature