ruprecht

Maybe, though it definitely seems more extreme lately. Just shrugging and accepting a 6, or 4, or 2 hourly restart isn't something everyone is relaxed about. In any case, there's hard data here that the problem is directly affecting customers of commercial hosting providers so I'd suspect there is some incentive to want this finally hunted down and shacked. Big persistent dynamic sandbox missions like these are the raison d'etre for commercial hosting. If it's a leak because some dev in 2008 missed a pointer delete somewhere, it's about time it was fixed. If it's an intentional architectural decision to persist these groups, the impact needs to reconsidered and alternative designs explored. It's interesting, but without knowing any details about the mission running and how it is spawning and destroying units, it's hard to draw any conclusions from it.

Unfortunately a mission restart doesn't seem to. You can see it halfway through the second chart. Only a server restart cures it.

In my head, it's in a category at the top of the page for visibility but it won't get buried as quickly as it might in some other performance/general thread. *shrug*

TL;DR: when a mission spawns or clones a unit, memory is allocated. This memory is never deallocated, even on group/unit destroy, explode or removeJunk. Thus over time any mission that creates units will crash either from memory starvation or from hitting the RegMapStorage cap of 4094 groups. This investigation started after we noticed the excellent Pretense mission was dying after a few hours on our hosted server. By profiling the memory usage of the DCS_Server process using Process Lasso logging, we noticed that the VM (private bytes memory) continued to increase regardless of unit destruction, client join/leave or any other factor. The control was performed with a basic ME mission with a single client helo and no AI. VM usage was flat. The logical next step was then to write a script that spawned new units at a constant rate, and destroyed them on a cadence. If VM was deallocated, we would expect to see a sawtooth pattern. If it wasn't, we would expect to see a relatively straight incline up. The mission starts with 2 minutes of no spawning to establish a baseline with all scripts loaded. It is virtually flat. Once spawning starts (1 group of 5 vehicles every 3 seconds), VM rises steadily and does not reduce with destroy() being called on all ground objects every 60 seconds. When the spawn rate was increased to 1 group of 10 units every second, as expected the rate of VM accrual increased and VM was never deallocated. With a mission (not server) restart, no (effective) deallocation was performed as the VM restarts higher than when the mission was restarted. The next step was to also removeJunk around the spawn Zone to clean up as much as is permitted in the scripting environment. The same spawn parameters were used, with an additional step of calling removeJunk on a sphere 2x the size of the spawn zone every 5 minutes. In this test, VM continued the trend of accruing with no reduction due to destroy() or removeJunk(). It continued to accrue VM until the server crashed with the following error: 2024-04-11 03:15:28.743 WARNING EDOBJECTS (Main): RegMapStorage start cycle to find empty space in <viColumn> 2024-04-11 03:15:28.743 ERROR EDOBJECTS (Main): RegMapStorage has no more IDs (4094 max) in <viColumn> 2024-04-11 03:15:28.743 ERROR EDOBJECTS (Main): Failed assert `false` at Projects\edObjects\Source\Registry\RegMapStorage.cpp:124 This effectively caps the life of any mission that creates units on the fly based on the server RAM and the RegMapStorage cap of 4094. At 1 group per second being created, we'd expect to hit this cap at ~4094 seconds, or about 1.1 hours. This is basically exactly what we saw, despite all units in those groups being both destroyed and junk removed. A working theory is that this behaviour was introduced with the Apache FCR in order to allow destroyed vehicles to still be seen by the FCR. That said, others have said anecdotally that this predates the Apache. The effect is that dynamic missions require a regular server (not mission) restart to prevent this VM saturation, on a cadence that depends on the rate at which new units are spawned by the mission, and the total server RAM. Request that ED advise or investigate a solution that allows mission editors to purge the VM allocation of "dead but still there objects" in areas that are no longer relevant to the mission to prolong the life of the mission/server. While this may have other effects e.g. rendering them invisible to FCR, the alternative (a server crash or restart) is surely not better. Log data and charts: https://docs.google.com/spreadsheets/d/1p0tKoeipHJOaChhKnzNKjLD30maU3xKCvJH5o4quBY0/edit?usp=sharing (edit: if anyone wants to help me replace the MOOSE functions with stock to eliminate that potential source of error, please do!) edit2 another data point using trigger.action.explosion rather than destroy(). Same issue. RnR_Memtest_Syria.miz update: tested a different miz with no MOOSE (thanks cfrag), which creates 7 groups per second and destroys the group rather than the individual vehicles. Same VM accrual, and right on cue at ~590 sec (4094 / 7) it starts spamming RegMapStorage full.

Even easier, just use Process Lasso to keep DCS off E-cores.

There are workarounds in the meantime. People have had success with SteamVR, Virtual Desktop and rolling back the Meta drivers to v62. I did the latter using files provided in the main bug thread for this, and it works for me.

Currently the UI for George AI displays in both eyes in VR, and I believe there is no way to force it to a single eye similar to the IHADSS. This would be useful to eliminate parallax splitting of the two images in certain orientations, and permit for example putting George on the left eye with the IHADSS on the right. tx

Bit of a necro I guess but here is what I'm using with a Warthog, game controller and an old cougar stick while I build my TEDAC. These are not intended for generic use, as they're very specific for me. I like to have common things like radios, vr zoom etc on the same button in every aircraft (AH64, UH1, F/A18 etc) to minimise finger fires.

Is this your original design?

Likely not. ED have a fix and it's just waiting for the next patch cycle. If you can't even load in pancake and the above fix didn't work for you, it's likely you have another problem possibly unrelated to the oculus driver.

For ED testers, I can confirm the V63 Link update pushed about 40 hours ago busted my Quest 1 in VR. Reverting to the folders kindly provided by one of the pilots here fixed the issue for me, but I don't know how long that will last, or whether Meta will actually respect the "do not auto update" setting. I know Meta are the bad guys here, but we'd all really appreciate ED being super good guys and prioritising this fix for the next patch. It's gamebreaking as you've seen.

Thanks for reproducing. Given the map shows elevation in feet of ground targets, dividing by 3.28084 in a VR headset is not my idea of a good time so I hope they fix this soon.

I'm glad it's not just me or a PEBKAC error. So.... ED?

Problem: waypoint elevations manually entered in feet are reduced by a factor of ~3 each time the waypoint is undesignated and redesignated. It appears to be erroneously converting between feet and meters. Steps to reproduce: Hornet with latest open beta, multiplayer on caucasus, with ATFLIR on standby while airborne, enter a precision MGRS waypoint on an empty waypoint with elevation in feet WP the waypoint in HSI. Check HSI Data - the elevation remains as entered, displayed in feet Undesignate the waypoint with the HOTAS, and redesignate with WPDESG Note that the elevation is still displayed in feet, but is now about 1/3 of the entered elevation (it appears to have been converted to meters but displayed in feet) repeat and note that the elevation is divided by ~3 each time it is undesignated and redesignated Try process again with elevation entered in meters, note that the elevation is displayed in meters and does not get divided each time the waypoint is un/redesignated Sorry I don't have a track, but I'm curious if anyone else can reproduce, thanks. *edit* track attached. Each redesignation divides the elevation by * 1000ft > 304ft (3.289) * 304ft > 92 ft (3.304) * 92ft > 28ft (3.285) etc. Given a meter is 3.28 feet, this seems pretty clearly a bug. It seems to have been introduced sometime since the Apache release, as I haven't flown the Hornet since then, and it was working fine before the Apache. ElevationBug.trk ElevationBug2.trk

Hey @Deltaalphalima1I just sent an email but thought I'd post here as well. My slew was working great for about 6 months but has been getting increasingly bad Y axis drift despite frequent recalibration. Today the Y axis gave up altogether - no response at all. Is there somewhere I could look on the hardware side, or would I be up for a new cable/unit? cheers mate *edit* thanks for the email response, all good.