@SOBO-87:

I don’t think many ppl use that overlay.

Yes, it is not that common. I wasn’t even aware it is still there. So yes, only a few people will notice, even if it might be easy to reproduce. Put it to the bugtracker like Bluewolf mentioned.

Soooo… I have about 3/4th of a year to save for a new GPU, my R9 270X OC will probably not be enough then… Hope the best wife of all doesn’t notice :lol:

I have mine set to borderless window, but have the same resolution as the native resolution of my monitor.

I can now alt-tab and stream on Discord without crashing the application, which didn’t work before.

Try giving the argument -nomovie to the launcher by right clicking on the icon and adding it behind the exe path.
If it loads, it’s the video codec.

@drtbkj:

This raises an interesting question, How much bandit/friendly separation do you need to prevent Victor’s problem?

The more the better. I don’t fire into furballs, and I don’t fire “over the head of friendlies” or if they are directly behind an enemy group. It’s hard to guess sometimes though.
It won’t pick up a friendly 20° off your nose, but it might pick up anyone that happens to be where that furball is or was at the time you fired.
Most of these blue on blue situations happen when you lose lock before the missile is active. I have not seen one with an active missile yet, but I’m not sure how they act if the target explodes mid-air (which was pretty common before 4.35).
It’s all a risk calculation. If you can support your missile, the risk is low- if you can’t it is pretty high. If you have a Flanker following your SEAD flight, you might take the risk and support your missile. There is no generic rule of thumb.

If the lock breaks or you fire into a furball, the AIM-120 can catch friendly aircrafts and lock onto them.
Reasons for this:

• You lose lock -> AMRAAM locks onto next available target
• Friendly contact is real close, missile locks wrong target
• Enemy gets destroyed before the missile goes active -> AMRAAM locks onto next available target

You should not use active radar homing missiles if friendlies are nearby until you are so close that you can be sure they home onto the right target. It happens though, and such a situation can even develop while the missile is in the air.

Hmm… If it only happened online, maybe it does interfere with Comm switch up/down or one of the modifiers for the comm switch + the keys for trim or vice versa?

Can you map trim directly? I have it mapped with DirectX, no macros or stuff and it works fine. On my Saitek X52, I had “stuck” keys with specific macros.

@pvi_pantest:

Hello everybody,
just installed the 4.35 and experienced the same trim issue, so i assume it might be some callback related to mp flights like comm switch as suggested. I’ll go for more tests.

One more problem came out and i do not know if it’s only mine. During flight, pressing “0” to use ext view, i am not able any longer to move the view around the plane. 4.34 was set tu use hat switch of Joy calling NKPD 2,4,6,8 for rotating views, i cheked 4.35 keyfile and seen it calls shift 2,4,6,8, but changing the callbacks does not help. Also, if i use my keyboard with either 4.34 and 4.35 callbacks, i have no effect on moving external views. Any idea?

Go to setup -> controllers -> advanced and uncheck “Enable external mouselook”.

Putting both tracks (A/B) into the computer and letting the computer decide the direction and count will begin to fail when CPU load is high or the input frequency is higher than the detection frequency (input scanning frequency)- and the scanning frequency will go down if your CPU load goes up.

How are your encoders connected to the PC?