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.

Yes, confirmed that this worked for me and a friend.

Think I found a solution. Short answer is a text replace of cd38 with cd13 inside your joystick and throttle's diff.lua file (%userprofile%\Saved Games\DCS\Config\Input\FA-18C_hornet or %userprofile%\Saved Games\DCS.openbeta\Config\Input\FA-18C_hornet) More details to follow... Edit with details: The problem is inside of DCS World\Mods\aircraft\FA-18C\Cockpit\Scripts\devices.lua, devices["HOTAS"] was assigned twice, probably a copy+paste error by a developer. The latter assignment overwrote the former, so the HOTAS was assigned the internal device ID of 38. In the new version of the file, the second one was removed (probably when someone added the NVG device and noticed that the cockpit device). https://i.imgur.com/cGaJnTh.png So anything assigned to the HOTAS with the old version of DCS would be assigned to cd38 ("cockpit device 38"). This also had the effect of changing other device IDs. So if there was anything assigned to devices 39 and higher, the .diff.lua profiles need to be updated to match the new device ids. And to add... it would have made much more sense to just use device 13 for the new NVGs. Then backwards compatibility would have been maintained, there would have been no unused device id, and NVG support would still work.

Is it possible to query certain pieces of information from the game UI state and use that to perform custom settings inside of labels.lua? When running a multiplayer environment, I can force everyone to use the server's label settings by including it inside the miz file. But since (for example) the font size is specified is in pixels, this makes a very different experience for different players running at different resolutions. Labels which are invisible in 4k resolution are massive in VR. But I could make the font size scale as a function of the screen resolution, etc., if there was some way to obtain that information from within the labels.lua file.

I've read elsewhere that the heading bug is a DCS world engine issue. This sounds like a joke, but missions set in the month of January have a compass heading offset of > 100°. Easy fix is to make a backup copy of the campaign, then load the missions in the editor and change the date to a different month (Just change them to for example 1 Feb).

Thanks for looking into it. But this problem occurs with AI only -- no player involvement. In the video and screenshots I posted above, the player aircraft is sitting in its shelter with the engine off. It seems like the AI #2 gets too close to the lead, which causes the lead to stop. The #2 then stops. Sometimes it does not stop in time, and crashes into the lead. Other times, it does stop in time, but then the ground vehicles will blindly barrel into the stopped aircraft. I was able to work around the problem by putting the AI flight into two completely separate parking spots a ways down the airbase, so that when they turn onto the taxiway there is some separation. Then the AI twoship was able to successfully taxi and take off.

My attempts to fix the problem by moving the AI flight to a different parking space has only made things worse:

Within three minutes of the mission start, an AI UAZ crashes into an AI Mirage: This is on DCS world 1.5.6.4818. The only mods I'm using are Barthek's GTM 10. Seems like the lead AI mirage decides to stop on the taxiway for some reason, whereas the mission designer is expecting them to taxi straight to the runway. As a result, the #2 stops behind him, and the AI vehicle convoy runs into them. Track file from the incident.