andyn

Update: as of today, using the backup radio head disables the selected radio altogether. The displayed guard frequency is still 121.0. Additionally, the backup radio selector switch seems to select the wrong radio.

Out of interest, what is the disruptive use case here?

One of the most common use cases for function keys is to go to the F10 map, select a unit or weapon and press another function key to go to view that selected unit in external view. This requires you to: - Know the type of the unit you just clicked - Know the function key for the external view of said unit type - Be able to press that function key or key combination in, say, VR. My suggestion is to change the default behavior of the F2 key as follows: - If the F1 view of a player aircraft or a combined arms unit is currently selected, view the player unit in external view. - If the F10 map is open and no unit has been hooked, view the player unit in external view. - If the F10 map is open and a unit has been hooked, view that unit in external view. - If an external view is open, cycle between external views of units of that type. This will follow the principle of least surprise, which should be one of the primary UX design guidelines.

Topic. Most easily verified by having the Simpleradio overlay open, as it directly reads the in-game radio frequencies.

For some reason the forum software only uploaded the pictures I attached and never sent the text I wrote. See the two screenshots. The radar dish can be seen at one third from the left front end of the nose cone. The radar transmitter body can be seen taking up the right rear third of the nose cone - it has been pulled out onto its service rails! The nose cone could never be closed with the body in that out position. The radar antenna 3D model also has been scaled down if it is to fit inside that nose cone. See the two real-life photos for reference. Such a visual discrepancy has little effect in game since you're unlikely to see it. However, I seriously hope the radar simulation code does not use antenna aperture measurements taken from the 3D model. I'm also curious as to how such a miscommunication happened in the first place In the first screenshot you can also see the bort number bug.

1) Are the target coords intentionally for Sandman 5-1 and not the target? They clearly point at the group of Humvees. 2) Where is the IP on the western edge of the green zone? There is none on the actual map, it's just one huge patch of various shades of brown. I've tried calling IP inbound on multiple locations along the attack heading from above the river to the outskirts of the town to no avail.

This seems to mitigate the issue, too. In any case, the bug still exists in OB 2.8.3.38090. Attached is a crash log and a sample log from a non-crashing session with mirrors off. dcs.log-20230322-165447.zip dcs-mirrors-off-msaa-off-nocrash.log

Did some further troubleshooting. The issue only seems to happen when MSAA is disabled and cockpit display resolution has been set to 1024. Am I hitting some hardcoded limit? Attached is a crash dump in which I slot into a mission with textures set to 512 every frame, then exited back to the menu, set the textures to 1024 and restarted the same mission. dcs.log-20230317-232822.zip

Just confirming this bug still exists on OB 2.8.3.37854.1. dcs.log-20230317-230239.zip

Running VR with OpenXR enabled. The game crashed every time I started a mission, and the offending lines right before the stack trace in the log always looked like this: 2023-03-11 23:45:56.265 ERROR GRAPHICSCORE (9180): Failed assert `depthBuffer.getDims() == dims && depthBuffer.getMSAA() == msaa` at D:\Projects\Buildworker\nevada_testing\build\Projects\render\renderer\Include\rwrappers\inl/FrameBuffer.inl:339 2023-03-11 23:45:56.265 ERROR DX11BACKEND (9180): Failed assert `false && "depth buffer must be the same sizes as color targets"` at Projects\render\dx11backend_win8\Source\DX11FrameBufferManager.cpp:99 All the usual remedies (slow repair with extra file removal, disabling mods, fxo2 & metashader cleanup) had no effect. Then I tried setting MSAA from off to 2x, and the crashes are gone for now. I can do some further troubleshooting with specific settings if you have any pointers. dcs.log-20230311-234556.zip dcs.20230311-234556.log

Without .dll replacement it starts in SteamVR even with this patch; with .dll replaced it starts in OpenXR. No OpenComposite switcher shenanigans. WMR set as OXR runtime. Ran slow repair with extra file removal, as always.

My go-to quick test is always the Syria Viper Golan heights strike mission and I was able to play it without any noticeable issues. Here are the relevant parts, if that helps narrowing down the issue in any way: - WMR & Reverb G2 - OpenXR Tools runtime 112.2211.2002 - OpenXR Toolkit GA-2 v1.2.2. Updated to v.1.2.3, still works. - Reprojection disabled on both OXR tools and OTK overlay - Turbo mode enabled on OTK overlay - OpenComposite installed by dropping openvr_api.dll manually to the bin directory, as the OpenComposite switcher does not work on my machine. Without replacing the .dll, the game starts in SteamVR normally. I randomly picked two older .dll versions I have left over in my Downloads directory and it worked on all of them.

Indeed - they now have to opt in to it in order to prevent cheating. It's an all-or-nothing choice now, with nothing not being an option.

It surely feels like CM presets should not be behind IC. This bug was introduced earlier this fall, then fixed in a subsequent patch and reintroduced again now.