miguelaco

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

Reported here and seems related to this:

What really puzzles me more about this subject is realizing that some people prefer to run the headset at 90Hz,which means it's more likely to have drops below the native rate. Having quite a hefty system myself (i9 14900K + 64Gb + RTX 4090) I find it simply it's not possible to run the sim at 72 fps in all situations. There are instances, for example, while flying low over highly populated areas in some maps, I struggle to reach the required rate for smooth flying. Maybe lowering details or reducing the headset's pixel density would alleviate things a bit, but I'm quite skeptical it's worth it at all. What do you think, is 72Hz the way to go or 90 Hz with less detail is worth it?

I concur with your observations. Anything below headset's native refresh rate seems jittery and definitely not a good experience. I also wonder how people cope with these situations and even say they're happy to have such a "high" refresh rate. I also thought if there is some magic or trick I am not aware of to get good results when fps go down below native's.

I can confirm this issue, all programs are shifted when loaded from the dtc. Moreover, there is also an issue with the selected program for dispense being shifted at mission start, as described here: I'm also attaching my own track in case it helps. fa18c_cmds_dtc_bug.trk

I can confirm this issue and also add that cycling through all the programs back to man 1, makes the dispense switch aft to release program 1 as it should. Dispense switch fwd seems to always release program 6 as @Nazgûl pointed out in the previous post. I made a short track showing the behavior. fa18c_cmds_step_bug.trk

It's not my intent to start a discussion here, but with all due respect, I don’t understand the reasoning behind closing the previous thread. The proposed solution aligns with my findings, and I don’t believe it’s my specific issue. I’ve shared two different sets of logs, which show delays that are inconsistent, ranging from less than a second to 7 seconds. While this isn’t a critical issue, I believe it might be indicative of something else. Furthermore, the last post from the OP in that thread reflects the same findings. Additionally, I don’t find this approach efficient. Opening a new thread closely related to an already closed one and losing all the comment history doesn’t seem ideal. That said, as I mentioned earlier, it’s not a major issue, and I’ll continue investigating. If I uncover anything new, I’ll create a new thread.