Swift.

It's also possible it's random. It looks like they e already modelled the INUs drifting and having them drift independently from each other. Also looks like the GPS satellites it detects aren't always the same.

Perhaps we've misunderstood each other. I'm not saying for there to be fewer trimming options, Im saying the current available options do a poor job of achieving the same effect that the real stick can. And have proposed a solution that works around the issues. So the end goal is that we have the same two options we have now in addition to another option as I proposed.

So I'm not allowed to want a better method of trimming? I guess I'll have to figure out how to code it myself the

I think the next step up from what I have is a $1200 force feedback system, so maybe you're right. Edit: and FWIW guys, I've yet to hear a reason why ED shouldn't add this new system. Everything said so far has been 'I'm alright jack' or 'get good'.

Its a shame that you cant set a deadzone for the controls reactivation separate to the deadzone for the controls itself, because I really really hate having deadzones on my controls, but it is as you said a necessity for the trim to work in anything approaching an acceptable manner. Its a shame that we only have the two trim options currently present in the game and not an additional one that allows the benefit of the instant trim mode with none of the drawbacks in terms of jumpy flight. But it's true, a few people having no issue with the current setup is a perfectly valid reason to not add an additional superior option. Because as we know, the indifference of the few outweighs the needs of the many.

To add onto this, I was going to ask if anyone could think of a reason to not have this new trimmer option added. But then I realised that holding down the trimmer button is the SAS desaturate thingy that Bradmick described in the other thread. So I propose an additional binding that can be made for use with the central trimmer option, this binding will reactivate the controls regardless of their position. In effect achieving the same result as the first option I described, but without interfering with the SAS desaturate.

When you say 'release' are you describing the action of actually letting your control go and sticking your hands in the air, or just easing pressure? Because when you have a joystick that doesn't have a centre detent then simply having your hands on the controls is enough for it to 'not reach centre'. Obviously I could do my best rollercoaster impression and sling my hands to the heavens but then the stick flies through the centre and out the other side, creating an undesired wobble in flight and isnt exactly what I'd describe as 'controlled'. The way I see it, there are some people who have no issue with the current techniques which is cool. But there are lots of people who do have issues, and the new trimmer option I proposed is a suitable solution to alleviate the problems people have with the other two options.

As I said above, you've got two different methods for trimming, both have drawbacks. The way I suggested should aim to alleviate the drawbacks of both without introducing any additional negatives. The technique I suggested could replicate the behaviour of the Instant mode if the user were to just tap the trim button and not hold it down. Similarly it can replicate the motion of the central mode by the user holding the button down until their stick is at the centre. The best of both worlds, the smoothness of the central with the control of the instant.

I take it you havent seen the countless clips of people careening into the ground because the controls have locked up. Those same people who now use the trimmer mode designed for FFB sticks just because the one designed for sprung sticks is so undesirable?

I mean how there is no way to forcefully regain control of the stick with the central trimmer mode. So if you are having trouble finding the centre of your controls and need to instantly make a manoeuvre, then you are screwed. With the way I just proposed, if you need instant access to the controls again, you just release the button.

Daily pressing of ED: To add an option where depress of the trim button sets the trim centre and freezes the user controls, and releasing the trim button reactivates the controls. So the trim process is move to new position, press and hold the trim button, move stick to centre or 'neutral', release trim button. And experience the new trim position without the 'jump' we see with the instant mode and without the inability to regain control of the central mode.

Im saying that IRL it has to actually figure it out because its not just spoon fed on a little bundle of EDs lua code somewhere. And sometimes things are ambiguous. IDK how the RWR is set up IRL, idk what alphanumerics relate to what emitter, idk if different aspects, closures, etc etc influence the ID. All I know is that RWRs in DCS are wayyyyyyyyyyyy too good.

Speaking with folks who know this kit

That just looks like mippling, where the RWR can't properly resolve the ID of the emitter so it changes like that. An effect of real life being less perfect than the game environment.

If the threat profile dictates you flying low level, then you might consider a pop up attack. So you gain the benefit of the low level whilst allowing proper weapon employment. Side note, I can imagine you being at a much greater risk of AAA fire at a few hundred feet than simply flying above them.

Modern MBTs aren't exactly inaccurate whilst targeting slow moving targets either.

Oh how I hope ED can implement something like that, best of all worlds.

So I just tested this because I was curious about this assertation, compared UH-1H with AH-64D behaviour. What I saw was as you described: pretty much the same behaviour. However the big and critical difference between these two aircraft is the delay between button release and 'trim set' so to say. In the Apache you have microseconds to centre the stick before it adds the input onto the new trim. In Huey on the other hand there is a noticeable delay where the control freezes, which is key to allowing the pilot to recenter the stick before it comes alive again. So in summary, if we want the same trimming technique in apache as we have in huey, we need a slightly longer delay between button press and reactivation of the controls. Or even better, a slider option in the special menu. Edit: Along a similar note, IMO it would also be manageable if the change of trim centres was smooth. So you are trimmed half back, then move the input to half forward and retrim, then instead of it instantly snapping, it will smoothly glide forward. This glide of course being at a rate that a human can match on the way back, ie 1-2 seconds. Same applies to the eventual trimmer reset.

Are you landing and then checking?

Seems like a lot of people want this, maybe a hint for ED

Only GBU-38 specifically last I checked?

I think I've been seeing a similar thing, where you press the button and it will flash the cursor on the new screen and then return it to the old one.

Ah yeah good idea, I had forgotten about that, but having both trigger stages as 33% and 66% of an axis or something would be cool.

I assume the LOST cue shows if the missile is below a certain energy level? Would you be able to share what that level is so we can better understand this indication?

The Apache CPG has foot buttons to operate the PTT for the ICS and Radios. This is similar to the F14 RIO, where we see in DCS a great solution by Heatblur to be able to bind the players toebrake axis as a button for these PTTs. Would we be able to have a similar 'Axis as Button' binding for the Apache CPG aswell?