Toumal

This is the only server I run, "Caucasus Dynamic Conflict". If that's the case then this must affect everyone, no?

I have the issue that I can start my dedicated server, but after a few hours I get this: 2025-03-07 11:39:40.691 ERROR ASYNCNET (Main): Server registration failed with code 401 This happens 2-3 hours after the server was started. I googled this error and found recommendations to unlink the steam account. I never linked my steam account so that can't be it. I used to be able to host with no issue. I am aware of this thread: but I don't know if these issues are related because I am perfectly able to start my server, it's just that I get kicked out after some time. Is there anything I can/should do?

@Actium Your checks are definitely more robust than mine. I should also note that my issue at the moment is the fact that my server is stopped by authentication failures from EDs servers after a few hours. In that case the web ports are not available anymore. I will post in a different topic about that particular issue, which currently makes it impossible for me to host.

Sure this is my current script: #!/bin/bash while true do dcspid=`ps x|grep DCS_server.exe|grep -v grep|head -n1|awk '{print $1;}'` case $dcspid in ''|*[!0-9]*) echo "Restarting DCS...";lutris lutris:rungameid/1;sleep 200;; *) echo "DCS is running as PID $dcspid";; esac HTTP_RESPONSE=$(curl -s --max-time 3 --write-out "%{http_code}" -o /dev/null http://127.0.0.1:8088/ ) # Check the HTTP response code if [[ "$HTTP_RESPONSE" -eq 404 ]]; then #echo "The server at $URL is up and responding with HTTP 404" sleep 1 else echo "The server at $URL did not respond with HTTP 404. Response code: $HTTP_RESPONSE." kill -9 $dcspid fi sleep 30 done I noticed that if the server is non-responsive, the http ports aren't open. So all I had to do is check if you can access the http server on 8088. If I get a 404 on / then all's good

I don't understand why the dedicated server needs to authenticate in the first place. As it stands, I find myself unable to host a dedicated server not just because of the gymnastics I have to do to check if the server is actually up (check PID, check port connection, etc) but because any time the ED auth servers return a 401 the server quits.

I have this same issue now. It happens after about 3 hours. No amount of restarting seems to help. The server time is in sync.

Yeah I am running with 5GB pagefile which is not on C, and I upgraded to 64GB of RAM. Unfortunately I had to install build tools for microsoft hololens and that's sucked up a lot of space on C, which is why this problem appeared only recently. I thought 32GB would've been enough since I didn't see DCS using all that much, but my mistake with that assumption was that I looked at task manager, which isn't the best tool to judge memory situations unfortunately. So yeah, while DCS eventually uses up all available VRAM, it does seem to evict unused textures etc. as needed. My crash went away once I freed up a bit of space on C and moved the pagefile. I added RAM because I don't want my OS to have to rely on a pagefile in the first place.

Doh! Yeah that would do it. I can't free up much atm due to work stuff that unfortunately has to live on C (thanks MS...) but I doubled up the RAM and disabled the pagefile on C, and so far, no more crashes! Thanks!

Update, I managed to get a full crash dump! dcs.log-20230924-150318.zip

Specs: RTX4090 with 24GB VRAM, texture settings high. These settings worked fine for many months without any crashes. Now, VRAM usage climbs to the limit when getting into an aircraft and then the game dies. Tried repair (removed any changed files too) and also updated GPU drivers to latest. No zip file and no dmp file was generated. However I do have the crash and log files. Sometimes when this happens, I get a dialog box like the one included, but it does not always happen. Something changed with the way VRAM is allocated. It now always grows and is never freed. Even on lower settings you eventually crash if you hop into different types of aircraft. dcs.log dcs.20230924-145213.crash

Since the last patch I have extremely high VRAM usage. I'm running a 4090 with 24GB VRAM in VR with a Varjo Aero using the MT binary. I never had any situation where I ran out of GPU memory. But now, I end up crashing to desktop with a dialog box that says that I am "out of video memory trying to allocate a texture". I tried lowering the textures and visible range, but that did not help. Anyone else experience this?

That's great news! We'll make sure to test it then! Also, yes we were in the L, and yes I have a few winwing devices.

I got two for you from yesterday with Lawrence. I'll poke him to upload his as well. To add a bit of context, both crashes were in the Gazelle, both as I was getting close to attacking enemies but I was not attempting to fire yet. I get these crashes both with the HOT-3 and the Mistral loadouts, and it doesn't matter if I'm in the pilot or gunner seat. dcs.log-20230610-152455.zipdcs.log-20230610-145855.zip

I crashed at exactly the same time as Lawrence playing as his gunner. I also have the CTDs in the Gazelle after a few minutes.

Heya! Could this perhaps be added at some point? This would be a big help in training sessions where the trainer currently has to ask the student to look down at a screen to see what's going on. Having a set of fixed external MFDs for a VR player would be a really neat thing to have.

I actually just tried again and the wrapper worked this time... Not really sure why I got CTD before but anyway, I'll take it

The VR changes broke the game for me completely. I use a Varjo headset and I have to run in OpenXR, I cannot use OpenVR because motion compensation simply does not work correctly. In OpenXR everything worked fine. Now the menu works fine in OpenXR but loading into a mission doesn't complete, ever. My logfile is getting filled with the following errors: 2023-01-28 16:29:21.082 ERROR VISUALIZER (Main): xrEndFrame failed with error: XR_ERROR_SWAPCHAIN_RECT_INVALID 2023-01-28 16:29:21.093 ERROR VISUALIZER (Main): xrEndFrame failed with error: XR_ERROR_HANDLE_INVALID 2023-01-28 16:29:21.715 WARNING LOG (8548): 55 duplicate message(s) skipped. I tried running without any parameter, I tried to force OpenXR, and I tried the Varjo mode. EDIT: Oh and the replacement DLL doesn't work for me anymore either, the game won't even start up. EDIT2: Wrapper DLL worked on second attempt. No idea why but there we go. Any ideas?

Is the performance worse in general or just when enabling the new mption smoothing? In other words, should I hold off from updating?

*sad trombone noises* Is there any word from ED about this possibly being supported in the future? Also, just got my Aero going and wow... the image clarity is truly something else

Is there any way to get eyetracking foveated rendering going with OpenXR Toolkit + OpenComposite? The option for this is not available, which as I understand happens because OpenXR is not able to detect the order of frames being rendered by DCS. Is there a setting to override this?

Same, I tried a dozen different weather systems and the result is always clear sky with varying amounts of wind.

Heya! If I may make a recommendation: You might want to consider always creating the dialog when calling updateDiag.show if it doesn't exist yet, and also always calling updateDisplay as part of show() since there's probably no use case where you want to see non-current information.

Yep. You can uncomment the print() line in comms.lua and it will show that avDev_on_ground() returns true in those cases. I checked where that function is defined but it's within their DLL it seems.

I did some debugging and the problem appears to be that avINT:avDev_on_ground() reports false even though you are on the ground. This appears to be depending on the wind and other factors. A quick workaround is to comment out the check like so: updateDiag.perform = function(self, parameters) local avINT = data.base.GetDevice(dev_radio_int_id) if avINT then -- print("is on ground: "..tostring(avINT:avDev_on_ground())) -- if avINT:avDev_on_ground() then if not window_ then updateDiag.create() end updateDiag.updateDisplay() updateDiag.show(true) -- else -- updateDiag.show(false) -- end else updateDiag.show(false) end end This fixed it for me. No idea what the side effects would be though, since that code looks weird. Why do they only CREATE the dialog if you are on the ground, but always attempt to show it? This is just asking for trouble. EDIT: This only fixes the dialog. However since the same check is used elsewhere for other things, you're stuck with the dialog functionality not working.

Just checked, I get the same error, both in VR and in 2D