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.

Usually when I hit bugs I'm one hour or more into a mission, and those are usually not reproducible due to how .trks work (and even if they worked, nobody would want to watch a one-hour long replay multiple times trying to debug it). Such issues are a huge nuisance for hardcore fans of the game who are ready to spend hours in just a single sortie, be it a virtual squadron MP operation or a Raven One campaign mission. Those complainers are usually the most noisy ones, and rightfully so.

That's unnecessary, unless you really like doing all your mappings again. Just make sure that the encoders dropdown has only dashes and zeroes. In your case, it would have said "EncoderDial 23 24"

Nope. Checking if I forgot to remove it was literally the first troubleshooting step I did.

After reinstalling the OS and following the guide, for some reason DCS now opens in full screen despite the VR checkbox being on. SteamVR works. Edit: I was using the OpenComposite switcher program that seems to be the currently recommended solution, but it was the culprit. Dropping openvr_api.dll manually into the game directory solved the issue. In both cases, the d3dcompiler_47.dll file was removed manually. This is why I hate automatic updaters that force the latest version down one's throat.

Can't use the PNVS in headtracking mode during night as the jitter causes horrible nausea even when projected onto both eyes. In fixed forward mode there are no issues. By adding some heavy averaging to the HMD head position this issue can likely be done away with.

An almost-happy new user here! The only gripe I have is this slider in Simshaker for Aviators: The deadzone center should be at 1.0 g, not 0. Currently the pad gives a positive g feedback even inside the 0 to 1 g range, when everything below 1 should be negative relative to the user.

Radio frequencies are exported. Other parameters - including guard status - aren't so SRS has to export the cockpit indicator state and interpret it to its best ability.

SRS has no way of accurately knowing which radio you're configuring. Whenever the frequency shown in the top left display matches any of your SRS radios, the right side option button values are read by the export script.

The rules above sound complex, but they can be summarized "always intercept the glide slope from above".

The F-5E is now unplayable in PvP multiplayer and PvE multiplayer on servers that use IC. This RWR mod has been widely considered a legitimate fix as the underlying issue has not been fixed for more than four years now.