abelian

I have been running into the exact symptoms described in this thread off and on over the years, with both SteamVR and OpenXR, with the Valve Index and most recently with the Reverb G2. With DCS's OpenXR implementation however, the DCS log provides some useful information: the error is always associated with an extra long gc() event (garbage collection in the texture memory implementation?) 2023-04-02 06:49:33.829 INFO EDTERRAINGRAPHICS41 (8012 surface5 gc() 11.225400 ms 2023-04-02 06:49:35.445 ERROR VISUALIZER (8012 xrEndFrame failed with error: XR_ERROR_RUNTIME_FAILURE

Unfortunately I don't have a public source. But I'm quite certain that the beam is going to be much taller than 5°. Probably at least 40°, maybe taller. For older radars this was apparently done by mechanically extended a spoiler in front of the antenna, which could create 60° or more beam spread. Sure, the peak power at the main lobe would drop. But that's how ground mapping radar works: you want to spread the energy out over a large area. Note that the scan is much slower in GM than in air-to-air modes. I presume the beam is made narrower in EXP/DBS. But at the end of the day, the radar is still outputting the same average power. A simplified model for this would be to come up with an educated guess for the farfield radiation pattern of a fan beam, center the beam on the SPI as much as possible within the limits of the antenna elevation gimbal, and multiply the map (intensity? SNR?) by the projection of this curve onto backscatter return.

I'm pretty sure that the OP is not correct. APG-68 should have a beam spoiler which creates a fan beam in the vertical direction when in air-to-ground modes. The height of the beam is not infinite, but it is much larger than 5°.

I wrote some software that might help you: https://github.com/bobmoretti/dcs-tetrad It will create a console and displays various statistics every 5 seconds. It also saves a compressed CSV file with frame rate and object/ballistics counts for every frame. You can also enable a GUI that makes a running plot of this information over time (don't recommend running this on a server without a GPU). Please ping me if you have any questions.

Thanks for taking a look at it!

Yes, absolutely, this times a thousand. For an SME who is not a passionate DCS player, they may see this and say "good enough" for a video game. But also, if they haven't flown in 15 years, it's very easy for pilots to remember this kind of detail incorrectly.

Do you have a public source for this? Your info is correct at least as of 2012. But newer ALR-56M has digital components that can be field-upgraded. I suspect the SME is misremembering or not giving a very critical look at this one detail. But it's also possible that the RWR software features changed over time and the SME is correct for the mid 2000s viper. Without a public source, I don't think ED is likely to change this. Do you have any way of tying specific RWR models to specific videos? I happen to know you are correct regarding the tones (at least of 2012), but to overcome their SME's (likely mistaken) feedback, we need a source that can be traced.

Yep, I have the issue with 0.6.0. Will try with 0.6.1 later.

See my post above. Try restarting the "Windows Perception Service" as an easier workaround.

On a fresh reboot, opencomposite works fine. But if I close DCS and try to run it again, I get this same error. Kind of annoying to have to reboot my machine if I want to tweak settings. I cleaned and repaired my DCS install, no effect. Deleted metashaders2 and fxo, also no effect. Here is my openovr_log from a failed run. EDIT: Restarting the windows perception service seems to also fix the issue, as a better workaround than rebooting my entire machine. DrvOpenXR::GetXRAppName:103 - Setting application name to OpenComposite_DCS DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_KHR_win32_convert_performance_counter_time DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_KHR_D3D11_enable DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_KHR_D3D12_enable DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_KHR_composition_layer_depth DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_KHR_composition_layer_color_scale_bias DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_MSFT_unbounded_reference_space DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_MSFT_spatial_anchor DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_MSFT_perception_anchor_interop DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_EXT_win32_appcontainer_compatible DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_EXT_conformance_automation DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_MSFT_composition_layer_reprojection DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_MSFT_spatial_graph_bridge DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_MSFT_spatial_anchor_persistence DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_EXT_eye_gaze_interaction DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_MSFT_hand_interaction DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_EXT_hand_tracking DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_MSFT_hand_tracking_mesh DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_MSFT_controller_model DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_KHR_visibility_mask DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_EXT_samsung_odyssey_controller DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_EXT_hp_mixed_reality_controller DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_EXT_debug_utils DrvOpenXR::CreateOpenXRBackend:155 - Num layers available: 0 DrvOpenXR::GetXRAppName:103 - Setting application name to OpenComposite_DCS debugCallback:117 - debugCallback Completed loader terminator debugCallback:117 - debugCallback Completed loader trampoline DrvOpenXR::CreateOpenXRBackend:250 - viewCount: 2 DrvOpenXR::CreateOpenXRBackend:256 - xrViewCount: 2 DrvOpenXR::SetupSession:296 - XrSystem: 1 XrInstance: 0000000000000002 XrBackend::PumpEvents:884 - Switch to OpenXR state 1 XrBackend::PumpEvents:884 - Switch to OpenXR state 2 XrBackend::PumpEvents:888 - Hit ready state, begin session... XrHMD::GetStringTrackedDeviceProperty:359 - GetStringTrackedDeviceProperty 1000 (null) XrHMD::GetStringTrackedDeviceProperty:359 - GetStringTrackedDeviceProperty 1000 XrHMD::GetStringTrackedDeviceProperty:359 - GetStringTrackedDeviceProperty 1001 (null) XrHMD::GetStringTrackedDeviceProperty:359 - GetStringTrackedDeviceProperty 1001 BaseExtendedDisplay::GetWindowBounds:15 - GetWindowBounds w 1920 h 1080 XrHMD::GetRecommendedRenderTargetSize:18 - GetRecommendedRenderTargetSize w 2744 h 2676 XrHMD::GetProjectionRaw:95 - xrLocateViews XrHMD::GetProjectionRaw:95 - xrLocateViews XrHMD::GetStringTrackedDeviceProperty:359 - GetStringTrackedDeviceProperty 1000 (null) XrHMD::GetStringTrackedDeviceProperty:359 - GetStringTrackedDeviceProperty 1000 XrHMD::GetHiddenAreaMesh:230 - GetHiddenAreaMesh eye: 0 type: 1 XrHMD::GetHiddenAreaMesh:230 - GetHiddenAreaMesh eye: 1 type: 1 XrHMD::GetEyeToHeadTransform:182 - xrLocateViews XrHMD::GetEyeToHeadTransform:182 - xrLocateViews XrHMD::GetEyeToHeadTransform:182 - xrLocateViews XrHMD::GetEyeToHeadTransform:182 - xrLocateViews XrBackend::CheckOrInitCompositors:320 - Recreating OpenXR session for application graphics API DrvOpenXR::SetupSession:296 - XrSystem: 1 XrInstance: 0000000000000002 XrBackend::PumpEvents:884 - Switch to OpenXR state 1 XrBackend::PumpEvents:884 - Switch to OpenXR state 2 XrBackend::PumpEvents:888 - Hit ready state, begin session... DX11Compositor::CheckCreateSwapChain:274 - Generating new swap chain DX11Compositor::CheckCreateSwapChain:278 - Texture desc format: 28 DX11Compositor::CheckCreateSwapChain:279 - Texture desc bind flags: 40 DX11Compositor::CheckCreateSwapChain:280 - Texture desc MiscFlags: 0 DX11Compositor::CheckCreateSwapChain:281 - Texture desc Usage: 0 DX11Compositor::CheckCreateSwapChain:282 - Texture desc width: 2744 DX11Compositor::CheckCreateSwapChain:283 - Texture desc height: 2676 DX11Compositor::CheckCreateSwapChain:311 - Texture desc format: 29 DX11Compositor::CheckCreateSwapChain:338 - Created swap chain: 2744 x 2676 d3d_make_surface_data:131 - Texture description: 2744 x 2676 Format 27 d3d_make_surface_data:131 - Texture description: 2744 x 2676 Format 27 d3d_make_surface_data:131 - Texture description: 2744 x 2676 Format 27 DX11Compositor::CheckCreateSwapChain:274 - Generating new swap chain DX11Compositor::CheckCreateSwapChain:278 - Texture desc format: 28 DX11Compositor::CheckCreateSwapChain:279 - Texture desc bind flags: 40 DX11Compositor::CheckCreateSwapChain:280 - Texture desc MiscFlags: 0 DX11Compositor::CheckCreateSwapChain:281 - Texture desc Usage: 0 DX11Compositor::CheckCreateSwapChain:282 - Texture desc width: 2744 DX11Compositor::CheckCreateSwapChain:283 - Texture desc height: 2676 DX11Compositor::CheckCreateSwapChain:311 - Texture desc format: 29 DX11Compositor::CheckCreateSwapChain:338 - Created swap chain: 2744 x 2676 d3d_make_surface_data:131 - Texture description: 2744 x 2676 Format 27 d3d_make_surface_data:131 - Texture description: 2744 x 2676 Format 27 d3d_make_surface_data:131 - Texture description: 2744 x 2676 Format 27 oovr_abort_raw:55 - Abort! XrBackend::SubmitFrames:702 - OpenXR Call failed, aborting. C:\Users\Jabbah\Documents\open-composite-acc\DrvOpenXR\XrBackend.cpp:702 SubmitFrames. Error code: -1 res

> I use a warthog, I dont seem to have any issue with slewing Hey Bignewy, can you confirm that you're referring to slewing in the context of AUTO HUD designation? It's fine with the DDIs; it's the HUD TD box slewing that is painful. edit: with saturation at 21, doesn't it take forever to slew the DDIs?

Thank you! For now we can work around it by requesting that users with poor performance directly connect to the anycast IP. But it would be a big improvement for us if we could register a custom IP via serverSettings.lua.

TL;DR: is there any way to choose which IP address is registered to DCS's server browser? I am trying to do a somewhat nonstandard cloud-based server setup. I have two public IP addresses for my server instance: the host VM public IP address, and a special anycast IP address. TCP and UDP traffic from clients to the anycast network will get routed to the VM using either address. Users from around the world will have a better experience when connecting via the anycast IP. The problem is that connections initiated from the VM show up as using the normal public API and not the anycast IP. For example, the following shows up in dcs.log: NET: Registering server as <Public IP>:10308 (port is assumed to be open) Is there any way to manually set which IP address the server registers to?

I have multiple tracks that probably show this, but digging through them to find which ones might be painstaking. As others have been saying, the ship pitch and roll correction is applied to multiplayer clients even after leaving the ship, but the linear position offset is proportional to the distance from the center of rotation of the ship. In other words, it's as if the game thinks the aircraft is still sitting on a giant ship that is pitching and rolling, and applying a correction to make sure that the plane stays on the "deck". For example, this was on a multiplayer server... It's a pretty good way to dodge missiles :): https://gyazo.com/3b608cce8b8d3957e5169ba4cefcca90

No, they do not. But those features confer a significant tactical advantage, allowing rapid employment of ordnance on targets of opportunity without requiring specific dive parameters in order to get the bomb fall point into the HUD FoV. The A-10C has this feature, as does the F-16C. It's extremely useful especially in a fast jet. I'd like to commend Razbam's recent steps to improve engagement with the community. But it's not a great feeling to see a developer dismiss something that as a paying customer we might think is really important. Hopefully community feedback could help inform your development priorities. I wouldn't second guess your assessment of the difficulty of implementing the feature. But even a partial implementation seems like low hanging fruit to me and would add a lot of value. I suspect others would find it very useful as well. Hopefully you can consider bumping this up so that it's at least not on the very end of your queue.