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.

Are there docs or guidance on this? I've searched on the forum, but most answers are scripts used for "Do Script", while I wish to simply use the script on the condition.

Hi, Sedlo. I wonder if there's such a script used to put under Condition - Lua Predicate.

Not likely, since I changed quite a lot of default key bindings to A-10C II, so I need to do the same to each control of the old A-10C as well if I will play it. Now I'm moving on to a new mission Hideout! Edit and play it BTW, the IP selecting issue mentioned above, also occurred in the mission CASR. Looks like it's the same age as the Yankee base one.

I did similar to build a simple JTAC training mission and it goes all well. Could be. I don't know how old the mission was built for A-10C, so there might be some later updates to the game and ME that cause some issues. One thing I noticed is that there were two IP's created in the old mission: one is TOWEL placed around the IP waypoint of A-10C, and it is indeed used by JTAC during communication; the second one is placed somewhere north with no callsign given, and it seems not be used. I tried to select either of them to edit, but failed. Selecting TOWEL opens the menu of trigger zone North Outpost Marker Zone (I don't remeber the exact name, it is used for the somke marking the north outpost), and selecting the other IP opens the menu of South Outpost Marker Zone. I just couldn't edit these two IP's at all. I then deleted these two trigger zones, and now nothing happens if I click either of 2 IP's, they are non-selectable. I also checked the mission file in the .miz, and located the scripts of these two IP's. They seemed unspecial. I deleted them and went back to ME, and now they are gone. So I created a new IP and it's editable. I've just become interested in ME recently, and thus use the A-10C missions as practice to edit them to my preference. I only have limited programming skills that aid me reading the mission scripts but couldn't provide me with an entire clear picture of how the script flow works. So I might have missed something that could trigger undesired features, but the IP issue described above should be a legacy problem of the game update itself, and there might be more potential ones I think.

That's really quite a lot details implemented and to be implemented, great effort! Even though I often ignore JTAC's requested attacking angle, he doesn't always call abort, either. But anyway, contacting with JTAC in full procedure is a super cool role-play to me! Hope the cause of this bug could be located eventually

So, since the last post, I've played this mission about 5 more times, and today this bug occurred again. The track file is attached. I didn't finish the mission to the end since I couldn't issue orders to my wingman (I really cannot spot infantry so the wingman is greatly needed, lol). The story in this track is: I was orbitting around IP and asked one of the JTAC's for tasking; 9-line, remarks, readback, standby data, IP inbound, contact to marks were all good; as I was approaching the target, I chose Maverick as my weapon instaed of CBU-97 as ordered by JTAC; to find a better attack route (avoiding the trees that blocked my LOS to the target) I flew close to JTAC while kept tracking the target by TGP; I don't know if it was this reason, at this moment JTAC called "Abort! Abort! Abort!" (in what circumstances would JTAC call this usually?); I ignored this and continued trying to attack; after shooting my Maverick, I called out the VHF menu (251MHz, dedicated to contact with my wingman) to ask him to attack the second target on my SPI; now the same bug occurred that the comm stopped working, I couldn't contact anyone again. I wondered if it was due to JTAC, so I hovered back to the second target and destroyed it with CBU-97. Now JTAC congrated me and told me no more tasking and may depart. I thought this could have broken the jammed comm by JTAC, but it did not. I still couldn't use the comm menu. Game quited. Edit: In addition, I did not install any Mods, eveything is original DCS, except the mission .miz, which I editted it in ME to my preference. If needed, I can upload the .miz. jtac_jammer_2.trk

Seems I misunderstood this dial selection (thought it's just a FM/AM selection), but indeed I could not use any other radio either then. That's true, I played twice more this mission after reporting this post, and evrything went well. The first JTAC even warned me "Abort! Abort! Abort!" before he was killed by enemy mortar, since one plausible cause to the bug, which I thought, could be his sudden death during transmitting. And later comm with the second JTAC went also well. I recall that the bug in the attached track occurred when I Ctrl+Z the game during check-in with the JTAC. In the later two games, I did all transimission in normal game speed all the way. Don't know if this matters.

Yes, I used realistic comm, but I changed the default keyboard bindings for each radio of the three. I only use the default \ on ground to call groudn crews. The "\ menu" might be a bit misleading (as I couldn't come up with a better concise name for it), but I just meant the dedicated radio here, such as ARC-186 for VHF 30MHz to JTAC, ARC-164 for UHF 251MHz to wingman, etc.

I was playing the A-10C single-player mission Defend Camp Yankee, which I editted the player's a/c to be A-10C II. On station of IP, I checked in with JTAC (VHF 30.00MHz FM, assigned by the mission editor) by radio ARC-186, and since then I received no response from JTAC at all. Furthermore, all my radio communications menus stopped working. In details: all three radios were functional, i.e. I could turn it on, off, tune frequencey, etc.; I could also receive the radio from another A-10C flight (that he was passing waypoint, spotted AAA, etc.) and ground units if tuned to the correct frequency. The problem is that I could not send any radio by the \ menu (I played realistic radio, so dedicated usage on ARC-210, 164 and 186). Nromally, for example, if I call my wingman to rejoin, I would hear my own transimision "2, join up." first, then the response "2, rejoin.". However, in this bugged mission I could not hear any of my transimission on all 3 radios, and thus no response from anyone, either wingman, jtac, ATC, etc., as if my radio call is jammed by the initial check-in with the JTAC. In the game I then strafed the bugged JTAC with HEI but he took zero damage. I don't know if it could be that the JTAC might be killed by enemy mortar when receiving my very long check-in radio call, and thus a bug is triggered, just a guess. This bug didn't always happen. I played this mission 4 times today, and there were twice that the JTAC didn't respond to me: once I could still use my radio to contact others; and the other time is the bugged one, and the track is attached. And usally, the JTAC would respond to me "no more tasking, good job" if there is no task, but sometimes he doesn't. jtac.trk

Nvm, I've figured out. There is an entry of ["optionsView"] that should be set as "optview_all" in the 2 files 'options.lua' and 'options' in the track file. Perhaps this should be added to the wishlist of the replay. You save all options applied at game into the track file while some of them should be easily changable when watching the replay.