miguelaco

Actually, depending on your configuration, there are now 3 places to setup sharpness: Pimax Play: it works only in VR and it's applied to the entire fov DCS: it works both in VR and 2D and also applied to the entire fov mbucchia's Quadviews Foveated: it works only in VR and it is only applied to the foveated region I would like to do some tests, but my feeling is that if you enable it in PP, it's not a good practice to enable it in DCS at the same time. I have my doubts with mbucchia's QV. Any thoughts or recommendations on where should we set sharpness to achieve better quality or performance?

That's interesting, I updated my BIOS to latest versions as soon as they were released to mitigate the degradation issues. I'll wait for the fix and if it doesn't solve it, then I'll revert to older BIOS versions. Thanks for sharing your observations.

I also have HAGS and Game Mode enabled, and I’m running the latest Nvidia drivers. The results I’m seeing are very similar to the ones I posted earlier, consistent across the last five driver versions. I normally fly in VR, but for these measurements I tested without VR enabled. My CPU cores are unparked as well, otherwise the usual warning would show up in the logs. From what I can tell, the issue is definitely CPU-related, I know there are a lot of factors, but it's clear that there are several users with the same behavior I described and I thought it could give some hints to what's going on here with this issue. If anyone else is seeing the same behavior, it would be helpful if you could share your load times with HT enabled vs. disabled.

I'd stick with mbucchia's quadviews for now until Pimax optimizes its own implementation. Didn't notice any hit in performance in my OG Crystal with latest PP + Pimax OpenXR + mbucchia's quadviews.

I'm happy a fix for loading times is in the works, but at the same time, I don't think HT On vs Off should be disregarded, if not as a direct cause to the issue, at least as something that might point to it. It's clear many users find that disabling HT helps with load times, both in these forums and the discord server. In my case, I made 12 runs, 6 with HT on and another 6 with HT off. The results are as follows: Desktop to launcher average of 37s with HT on vs. 13s with HT off. Launcher to menu average of 85s with HT on vs. 41s with HT off. I don't think it makes much sense to assume as normal behavior that disabling HT cuts loading times by more than half compared to HT enabled. I really think this should be looked at by the developers as it may point to a possible issue with Intel CPUs. I'm running DCS on a 14900k, btw. dcs-hton.log.zip dcs-htoff.log.zip

I have the same issue in the menu and I'm not disabling e-cores at all. I'm trying to pinpoint the cause and noticed that disabling Hyperthreading kind of fixes the issue in the main menu. Sadly, it seems that fps are less stable once in the cockpit, so it is a dead end for me. I keep reading that lowering the polling rate of the mouse seems to help, but I don't know how to do that in my Logitech MX Master 3. I have to say it is really annoying, even if it seems fine once in-sim.

I also noticed a huge improvement in load times by disabling Hyper-threading. I didn't get better performance once in the cockpit, a little improvement in stability if any.

I think the unlock & relock when releasing the uncage button is not right, aside the other inconsistencies noted above between non-acm L&S and STT.

This seems to be corrected in today's patch, MAN, S/A and AUTO modes in the Hornet are working as expected. Congrats to the team!!!

There's a mention in today's patch: I'll give it some testing once I have some time.

Any word on this? I provided a track and I think there's enough evidence to determine if this is a bug or working as intended. My view is that this is bugged and it makes no sense to change mode to BOL on undesignate while it is possible to select R/BL with no target selected. Any comments?

I noticed it is possible to select R/BL mode with no target selected. This seems to contradict what's stated in the manual and Chuck's Guide. Additionally, if R/BL is selected before having a TGT, when undesignate, the mode is changed back to BOL, but only for the selected station. Even more puzzling if you observe that when R/BL is selected for the first time, the indication INV TGT is displayed, possibly indicating that you need a designation first. However, later on, if you undesignate and select R/BL again, the last TGT seems to be remembered, IN RNG is displayed and the target is displayed in the HSI. If this is a feature and the target is persisted to the missile's memory after undesignate, why changing mode back to BOL? Is this correct behavior? Doesn't seem very consistent as it is right now. agm84d_mode.trk

The obvious workaround is to edit program 6 to your liking. And I somewhat feel the same about these issues. First patch introducing the DTC and it was broken both for radio presets and ALR-67 programs, but at least you could ignore them since everything worked as it did when ignoring DTC. Second iteration and DTC ALR-67 programs are still not fixed and the dispense function is broken in the process. I can't help but think that these problems should have been seen in the most basic tests, they don't look like corner cases at all.

I think there are three issues that might be related: DTC programs are loaded in the wrong/shifted by +1 slots (i.e. DTC program 1 is loaded in ALR-67 program 2 and so on). This is what the OP reported in this thread. Dispense Switch Aft releases the wrong/shifted by +1 program. Dispense Switch Fwd releases program no 6 (it was 5 before this patch). Bear in mind that cycling through all the programs back to the one you want selected seems to reset the counter and then Dispense Switch Aft executes the selected program as it should. This is the workaround I'm using at the moment for issue 2.

I did my own tests with latest patch (2.9.16.10523) and I'll try to showcase the results here as briefly and simple as possible. I focused on testing the AIM-9X boresight mode with no radar, since I think any issues when slaving to L&S target are related to cage/uncage behavior as well. Please, feel free to comment below if I missed something: HUD only (HMD off): Seeker placed over the target: Press and release CAGE/UNCAGE button: a lock cannot be achieved Press and hold CAGE/UNCAGE button: a lock is achieved whenever the button is pressed. As soon as it is released the lock breaks. After a lock is achieved it is no longer possible to achieve a lock again as described in point 2. HUD + HMD: Seeker in HUD placed over the target: Press and release CAGE/UNCAGE button: a lock cannot be achieved Press and hold CAGE/UNCAGE button: a lock is achieved whenever the button is pressed. As soon as it is released the lock breaks. After a lock is achieved it is possible to lock again by holding the button as described in point 2. Seeker in HMD and placed over the target: Press and release CAGE/UNCAGE button: when pressed, a lock is achieved and upon release the lock briefly breaks and locks again as described previously in the thread. Press and hold CAGE/UNCAGE button: a lock is achieved and when released, there are three possible outcomes depending where you're looking when that happens: If released over a target, the first lock is broken and it will lock again on the new (or same) target If released while looking at the HUD (the HMD is masked as a result), the lock breaks and if placed again over the target it will not reacquire again automatically. If released while HMD is not masked, the lock breaks and if placed again over the target it will reacquire the lock automatically Find attached two tracks showing the described behavior. Do not reset view while playing them and feel free to take control and experiment by yourselves. Looking at my findings and assuming I didn't do something wrong, I think the boresight mode is broken and not reliable at all, as pointed out by other users in this thread. aim9x_hud_only.trk aim9x_hud_hmd.trk