Whisper

Wow, my bad!!! I wrote the wrong type of GPU, I'm on a 3070! Lack of VRAM, I step down settings because of this Edit : I edited my original post

Do you have any source for this claim? Because I find it very very doubtful that any 3rd party would sign such a predatory contract, or for ED to set up such system where they benefit from third parties work during the whole early access phase while not paying them. That would be the sure way to kill their 3rd party ecosystem, which is something I'm pretty sure they don't want. Would that be something specific to RB and the SE?

Definitely NOT fixed for me. 13600K, 32G RAM, 3070, VR on Rift S with very low settings. F10 means instant slideshow. How is that not fixed since February is beyond me.

There's no lock on target through the periscope, the DCS engine has no way to know what is your target, so I'd guess the "attack my target" can't work with sensor that have no lock on ability

And it's a preview, what did you expect .... Some pple really love complaining

Hu? I wonder what is presented from 2:50 to 7:40 then....

All airports do not have ILS set up in both directions, in DCS. It may well be that Larnaca only has antennas set up for the 04.

I stand corrected, then. Thks

AFAIK rockets are not intended to be fired from a hovering position

Because it's inevitable if you model the behaviour like the real life counterpart : pressing trim up release the trim brake on the stick, release the trim re-grips the brake on the stick at the place the stick was when you released. This is the way ED wished to model it, true to IRL behaviour. Since our joysticks cannot stay at the position we commanded but will always return to center, we're stuck with either one the 2 drawbacks you mention. If you want to get rid of it, you need to model trim button behaviour differently from the real thing. I think you propose that when pushing trim up button, we actually indicate to the system that our expected trim position is the stick position when trim is pressed (unlike current behaviour where expected trim position is the position when trim is released), and that the trim button pressed neutralize input, which are given back when we release the trim? That way we could press trim up when in target stick position, place the stick back to center without impact on attitude, and release trim button when our stick is back at center. Is that so, or do you have something else in mind?

It is the same but also kinda different because there's no delay after button release in the Apache, where we have like 0.5s to center back the stick in the other helos.

This looks kinda logical to me. Slave redirects your sensor (TADS) to your acquisition source , unslave gives you back control through the TEDAC . Your acquisition source is the laser seeker, so once the lasing is on, the seeker catches it, and slaving puts your TADS on point So that should work... provided the seeker finds the laser point, IE is looking in the general vincinity of it, that may be your issue Do you also have a 9 line from the JTAC? If so, maybe using a markpoint on coordinates and slaving to it would do the trick Edit : warning, many edits after initial post, I didn't properly read your post in the first place

Exactly this! Add to this the fact that the Apache is FAR more reactive than the other helos and it makes the difference really noticeable, actually, even though it's technically minimal. Working on this delay and if feasible, Apache twitchiness would help far more than a "trim reset" option

To each his own, no pb with that Central trimmer bugs on me (DCS often do not recognise that the stick is back at center, leaving me with a dead stick). I just don't understand the hyperbole behind describing the apache trim as totally alien to the other DCS helicopters. Technically, the diff isn't that much (there's very short delay in Mi8 before the trim kicks in in default mode, and afaik that is all that differs, and yes, I think they could easily put it in the Apache, but I'm no DCS dev, so... ) between the trim implementations. Like you say, add it to the general Apache twitchness and the result can appear violent, and thus I'm not sure how a trimmer reset will solve issues. It's going to be a very violent reset, actually, seeing how reactive the Apache is to input. Wouldn't working on a delay and a more dampened input be better?

It happens all the time if you don't go back to center fast enough. The only difference is the delay you have to do it