XCNuse

I think I may have figured out what's happening. deleted the fxo and metashaders2 folder; restarted...... headed towards targets looking through camera, swapped over IR, looking at... nothing but cold dark ground; bright white. Things looked different/better however this time with the normal TV mode, like things weren't as high contrast, despite not touching the knobs. So, same issue; then I did something. Zoomed back out, went to TV, back to IR........ working. So I am now under the impression that swapping to IR breaks when you're zoomed in, not sure by how much, and I've only had the opportunity just this once this morning to just try doing it again to prove/disprove my issue, but I'm now leaning that pressing the IR button while zoomed in is the bug.

Unfortunately I haven't been able to come up with a solution; and no it was certainly not pointing up; as it was in forced forward / slave mode so I could just throw the copter around without slewing, and it was.... just white. Zooming made no change or anything. Definitely a bug either way though I think that's agreeable. I don't want to say it's completely a polychop issue though, I recall a few other aircraft having issues with the TGP and like cameras glaring out and sometimes never returning. That's the issue with the gazelle though is the not returning to normal function. Usually with the other aircraft like the F16 I could reset the TGP and it would return to normal, not the case with the Gazelle.

And this mentality is ruining the fun of today's technology that can be used on aging frames. If it required new systems, it would make more sense to question things; but if you can literally plop a system onto a pylon and it works with literally zero effort... we SHOULD be able to do it. Which exactly what the APKWS system was designed to do. I truly don't understand the people say "no that's unrealistic for what's been designed" when... there are literally this aircraft flying around using these weapons. How is that unrealistic?

I don't have a replay, but can likely easy get one; night mission, enabled TV, put it in IR mode and... white. Solid... blank white. Contrast and brightness knobs had zero effect on the TV. Switching from IR back to TV, still solid white, made no change in brightness; despite before pressing IR mode, the image was solid black (because it was 1AM mission time). For reference this was on the NTTR map.

Shoot, even an IR flare would be a good start; we've already got signal flares, can one be made so it's visible only in IR?

Bump for this. Disabling shadows nearly doubles my FPS at least in VR, but seeing things in cockpit depending on time of day becomes next to impossible due to light reflections. Cockpit only shadows would be a massive FPS booster for a lot of people; but should be an option either way, as they're really the only true shadows that really matter.

Can this be revisited? This is insanely frustrating and without anything informing anyone that it wouldn't work I just had to quit playing because... we didn't know it wouldn't work for me in a Viper.

Sorry for delay, I hardly ever get on this forum. Make sure that you run OTT or the Oculus Debug Tool. I had set mine to 3684. That said, at 1.5PD my 1080Ti was DEFINITELY struggling on a simple mission (was on the F16 cold start Caucasus mission); I was running at the default VR preset. I ended up giving up and going down to 1.3PD for the sake of framerate which brought a lot of it back up to a reasonable amount of ASW usage. Going to up the 1.5PD though really made things incredibly clear, but yeah, my 1080Ti was steamrolling a bit haha

As it stands, Mavericks are fairly broken right now in some form; at least with TGP, that said, without TGP they're pretty fast and easy to use; literally just hud as soi, slew to target area, mav as soi, FOV zoom, and TMS up until the cross collapses on target and launch. Personally I haven't been able to get PRE mode to work once, also because my TGP likes to break every time I try to use it with mavericks onboard. But VIS designation and locking with the HUD is fast and dirty; but it works, and doesn't break... as many things. Mavericks still like to break the steerpoints though because of the current SPI issue which ... knock on wood will be fixed in the coming patch in two weeks.

Can confirm it's also breaking my TGP. Once I load any mavericks onboard and hit A-G, enabling steerpoint autopilot only wants to go straight ahead until I return to Nav mode.... and hit CZ again. Also, more importantly; with Mavericks onboard and nothing being touched, once you reset to CZ on TGP, you can no longer slew the TGP.... at all. It WILL NOT MOVE. Entirely frustrating. Jettisoning the mavericks does not seem to fix the issue either. Viper broken TGP and Mavs.trk

Can you clarify what you mean between "the two?" Not sure I follow. 1070Ti will certainly struggle a bit more, at 1.5PD and the VR default settings I'm fairly positive even I am barely pumping 60FPS let alone 90 (granted until further notice the Q2 is at 70hz for the time being until it's unlocked; same with hand tracking [not sure why yet but.. that is the case]) I'm generally not that aware of what it takes for a good VR experience, I .. rarely ... fly DCS in VR, like once every half year or so, so I'm definitely not the best in terms of what's recommended to improve your experience. That said doing a small amount of research it seems as though MSAA and the "filter" doesn't seem to improve performance; at least according to most people. Hence why I ended up just ending back up at 1.5PD and no AA because it made things the most legible for me personally. EDIT- ohhh did you buy a Gen 1 Quest, a black one? If that's the case you very likely will not be able to read the MFDs, I didn't catch the used part. The resolution on it is significantly lower than the new version; and being pentile OLED ... makes it even more difficult to read things.

I'm loving my Q2, and now trying to find the fine line of best visual quality / performance with my 1080Ti via Link (I've already had VirtualDesktop running and have been playing games like H3VR and Onward wireless the past week... absolutely LOVE being able to see things so clearly!) That said, I could not get VirtualDesktop to run DCS wirelessly; so I've had to end up on Link as that's the only way the Oculus software sees the HMD and will output DCS (because reasons... only had this issue with DCS thus far) I've had to reinstall Oculus Tray Tool and bump up my encoder resolution as for some reason it was incredibly low by default from my Quest1, and so far... it's been fine sailing. Encoder set and running at 3684, and running PD 1.5 in DCS. Pretty awesome to be able to actually read incredibly small text and finally see AND READ the text on MFDs.

Confirming this is indeed still an issue for me since 2.5.5 task manager also shows mine using little / no resources and even not responding sometimes for half a minute; sometimes if I pester it, it will go ahead and crash itself. Up until 2.5.5 I rarely even saw the splash screen. Still a bit annoying to see it sit and do nothing for half a minute.

This should answer anyone's questions about Mavs. Expect to wait.... even more.

So the next day I actually had zero issues. Something interesting to note: Besides being on Caucasus vs PG, the only real difference was range. At closer ranges they didn't want to lock up on targets at all. At range, it would lock them up lickety split.

I may have gotten it backwards then, was working off what I had realized the night before; I think you're right. I'm not used to spinning via mouse wheel... let me correct that.

Got in touch with Khopa for anyone else having this issue it came down to this: - Check the content of the file <dcs_installation_directory>/Scripts/MissionScripting.lua - Check if it match the file provided in <dcs_liberation_directory>/resources/scripts/MissionScripting.lua If it doesn't match replace the file in DCS scripts folder. In theory Liberation SHOULD be replacing that file when you launch it; it was not happening for me.

Came across this from Samurai 1-1's channel on Youtube by pure chance. Looked like fun. However this is all I ever get after flying. As far as I can say mission setup wise; doing a cold war 1965 on Caucasus Western Georgia [recommended], start date of Fall 1970 I've tried it twice now rebuilding the mission... twice; and this same error has popped up both times. edit- just tried modern timeline and same thing happened. Anyone have any ideas?

And the answer is a yes not that it matters. And the extended answer is: Not everyone's controllers will be incredibly accurate as yours. At the end of the day, we all have different input devices; just because it works for YOU, doesn't mean it works for EVERYONE. And the fact remains, there is absolutely NO REASON for me to have to have a deadzone on my stick for autopilot to function properly. It is FAR too sensitive near a central deadzone area.... period. If this thread exists, and there are people like me entering the thread to say "I'm having an issue" There is an issue.

FYI all, the bug exists for everyone; it depends how you use them, I was going to say "I don't experience this either" until I tried the other method. Scroll wheeling spins infinitely. Grabbing with mouse and spinning works correctly. edit-got them backwards

If that's how it's supposed to work, I would argue it is far too sensitive. Having any kind of deadzone, especially one this big, now in my stick means I won't be able to AA refuel. My new argument would be this: This is a game, and everyone has different inputs from controllers to sticks. WE, shouldn't be putting deadzones in our flight controls. The AFC should either be logarithmic in nature, or have a built in deadzone itself. but yes, putting a [large] deadzone in the middle does "fix" it, but I would hardly call this a fix, more of a crutch. And the reason I state this is because it won't take but a little while until more people notice it and get fed up with this new functionality. Putting a deadzone in the AFC on the programming side of thing is a very easy thing to do, and I would argue would be closer to how the aircraft would work in the real world anyway since it's a computer augmentation that intakes accelerations and vectors, not ... stick precision.

Sometimes if I'm lucky it will roll over instead of just trimming back as far as it can go until it runs out of trim. Track attached. Again, I'm not sure how a switch can be user error; either it's on and you fly straight until you move the stick and it D/C's I can't even it altitude hold, it will never engage because it constantly pulls trim. But I fail to see how one can get flipping a switch wrong. Used to be that I could let go, and it would hold my pitch and fly wings level, or at a significant angle, and if I hit hold alt it would hold alt. Now it just... holds the trim button back until I run out of airspeed. Harrier broken AFC.trk

Why would my stick which is completely fine have anything to do with pulling trim? The system worked just fine. Now it does not. I can fly level-ish hands-free until a roll eventually creeps up; but as soon as I flip that AFC switch it just noses up and keeps nosing up until there's no trim left in the system. It just pulls trim and continues to pull trim, no input BESIDES trim forward will combat it. Alt hold won't even engage because it keeps pulling trim. Never have I ever had this issue until this patch, so it most certainly is not a "me" problem.

Still having issues where the IRs won't hit their targets or will aim for areas around targets but never actually hot-spots. I don't remember these things being so finicky and frustrating, but at closer ranges, they'll lock onto the grass areas alllllllllllllll around, but never the single bright white hotspot.... Surely this is wrong.

AFC now just continues to pull trim back until it can't trim back any more. So for me, yes, Autopilot is incredibly broken. I can sit there and fight it and trim down, and it will trim down, but as soon as I let go it just trims alllllllllllllllllllll the way back.