BoundaryLayer

I actually think it's more like a steam vr issue, because it's always the steam vr that crashes first, while DCS still palys the sound. Then force restarting steam vr exits DCS, so bascally DCS itself does not crash in this case. Ah, I see. I somehow ignored this phrase in the reply. Thanks! I will try it.

I tried this, but I don't know if I was doing it properly. On starting DCS I choose "start DCS with OpenXR", but eventually Steam VR starts and immediately 3GB VRAM is then taken. I'm not sure if OpenXR only works with VD, while my Pico does not support VD. Steam home has always been turned off (but still steam vr consumes large VRAM), and Pico does not have a "home" as far as I know. Ok.. this is insane. How could they let the hangar stay in the VRAM all the time. I will try to remove it this weekend. I thought this is realted to RAM only, so I've always been setting it to 100%, and the visual range as well. I will test it this weekend too. Will do. I also noticed the difference in usage of VRAM for different aircraft (F-16, A-10II and Su-25T), but that is only in hundreds of MB, compared to 3GB by steam vr and 3GB by the hangar... Nice, will test this too. Thank you Mr Sukebe for your advices!

I was told about VD before, but my Pico was retailed in China that unfortunately does not support VD. So I have been using the default PICO Connect, and indeed people say that it is worse than VD regarding to performance. I will have a look at this this weekend, but I'm afraid that its eye-tracking feature won't work with Pico though.

Hi, my hardware: 9600K, 32GB RAM, 3060Ti 8GB, DCS installed on SSD, PICO 4 VR set. I don't play VR quite often, but I clearly remember that a year ago, I could play in VR for medium graphics settings and crashes happened but not always. Now, I must set all textures to low, and steam vr crashes everytime when I try to reload another mission. I know that VRAM is an issue here, and I've noticed that after starting steam vr, 3GB VRAM is already consumed; and after starting DCS (main menu) another 3GB VRAM is consumed, that leaves only 2GB usable for the actual play. In the mission, all 8GB VRAM is consumed but it's fine, it's still playable (DLSS on, no super sampling from either steam vr or PICO set, I basically set everything to mininum), FPS is acceptable even though there is lagging in some scenario. However, after quiting the mission, the VRAM is only freed for hundreds of MB, so loading the next mission crashes steam vr, and this always happens now; and sometimes simply quiting the current mission crashes steam vr. Does anyone has any thought on this, like what further settings or optimizations I should do .

It seems not. I tested with the mission in the track file I posted before. The embarked unit is invisible to player but still visible at the embarking location to the enemy, until it disembarks somewhere else. And even worse is that the Moving Zone now doesn't work properly. In the last patch it just did not move with the unit, to which it was attached: remaining at the embarking location and then shifted to the disembarked location. Now the Moving Zone triggers nothing, no even functions as a stationary trigger zone.

I see, so the similar issue with CBU-99 might be hopefully easy to fix by the next update, I guess.

Hmm, so this was reported in February. I wonder if it's fixed yet.

As shown in the figure, below MFUZ there is nothing displaying but it's actually clickable, directing to the sub-page shown in the second figure with a clickable OFF option. This seems to be the setting of EFUZ. This is easily reproduced with CBU-99, so I don't attach any track file.

So I took control of the very first track of A-10C II in this post. After the radio was jammed, I hit the VOIP radio key. The stucked radio messages to JTAC then magically (as expected) started transmitting , radio fixed! Confirmed that both radio bugs reported here should be due to the same cause regardless of aircraft. Hope this be helpful in degbugging.

Yes it was, as if the UHF channel was still being used. On A-10C there is no indication whether the radio is being occupied, but for F-16C I noticed this inverted video of UHF. This gave me the hint to hit the Transimit Switch - UHF (VOIP) to see if the problem could be fixed, and it indeed worked. So maybe the jammed radio on A-10C II could also be fixed in a similar way once it happens. I guess this is not an issue to a specific aircraft, but rather the radio mechanism implemented in DCS.

In a F-16 flight of 4 members, there is no way to issue commands to wingman 4. So I play the flight leader, with wingman 2, 3 and 4, but in the radio menu, there are only two options: Wingman 2 and Wingman 3. In the case of A-10C II, I can command my Wingman in the lead element, and issue command to the Second Element (wingman 3 as the element lead) that wingman 4 will follow this command with wingman 3. However, for F-16C, this is totally broken up. The option Wingman 3 does not behave like the Second Element, and wingman 4 follows 2 or 3 arbitrarily. As for as I know from a simple test mission I built: Wingman 2 or 3 - Engage - My target: 4 will fowllow 2 and engage the target, but not follow 3 Wingman 2 or 3 - Hold position: 4 won't follow either 2 or 3, and thus I cannot anchor 4 at all Wingman 2 or 3 - go to - RTB: 4 will follow 3 to RTB, but not 2 It just looks like the option for Wingman 4 is randomly merged to 2 or 3, while for the free Su-25, there are 3 individual options to issue commands to 2, 3 and 4. Since this is a quite general bug that can be found in any mission of F-16, I do not attach a track file.

I've encountered a similar radio issue recently on F-16, which is quite similar to the one of A-10C II, so I think I will just post it here (or should I start a new thread in F-16 forum?). The track file is attached. It is "The Night Life" mission of F-16C, which I editted a bit while keeping the story original. In the track, after dropping bombs to the target and finally egressing (at the late stage of the game in the track), somewhere I noticed my UHF radio is jammed, and the DED keeps looking like the following (UHF channel being used) The radio issue again is that both "Transimit Switch - UHF/VHF (call radio menu)" stopped working, i.e. after clicking the desired radio message, I couldn't hear my own transmit, and thus no respond from the receiver. However, the interesting part is that after pressing the key of "Transimit Switch - UHF (VOIP)", the jammed UHF is fixed; and, all the previously stucked transimits (as if they were buffered in sequence in the game while the UHF was jammed) that I randomly conducted (to AWACS, flight, ATC...) now are being sent one by one. After that, the radio menu worked again. I hope this may give a hint to fix this radio bug. Perhaps the JTAC is innocent, while the implementation of the radio menu is bugged. night.trk

So this may not be a bug, but more like an implementation issue. It seems that the unit/group is just invisible and immortal after finishing the embarking task, and does not move along with the vehicle. This causes some undesired issues. In the attached track, I directed the following actions: An infantry: ready to embark onto UH-60A at LZ; to be disembarked from the UH-60A at a near airport; walks around at the airport. A UH-60A flight: performs the above embarking/disembarking actions. A hostile infantry squad: activated after infantry embarking and flying enough far away (a trigger zone is placed on the route of UH-60A to the airport). A moving trigger zone (2000ft radius) linked to infantry with triggers: Message "Alert" if there are hostiles inside the moving zone Message "Safe" if the hostiles are outside the moving zone I observed the following: The Alert message triggers immediately when hostiles are activated, even though the infantry has flown far away The activated hostiles starts shooting at LZ immediately, even though the infantry has flown far away The Safe message only triggers when the infantry disembarks at the airport (becomes visible to the player again in the game), even though the hostile squad should have already been outside the linked zone during flight to the airport. This implementation of embarking is kind of annoying. Maybe best make the embarked units moving along with the vehicle, or at least completely remove them from the game temorarily so that hostiles will not be able to interact with them. Embarking.trk

Thanks! Will dive into this

Thanks, NeedzWD40, this works! I get your idea here that the script checks if the unit is still inAir or not. From other answers I see people also use world.event.S_EVENT_LAND. I wonder if this can be combined to your script. BTW, where can I find docs on this, as I've just started playing with scripts in ME.