peachpossum

For now you can grab the top of the kneeboard and move it wherever you like, if that wasn't obvious to some reading this post.

The latest update appears to have corrected the issue with Standalone dedicated server files getting quarantined as trojans. Thank you ED for fixing this issue rather than having everyone bypass security.

is reinstalling Windows really a solution? Could the solution get a little finer grained than that?

I set a couple of radio presets in a simple MP mission yesterday based on Fargo007's process above. In SP the airplanes I tested received the correct carrier IDs and location data for the two carriers I placed in the mission. Later last evening when flying the same mission in MP, things worked normally in the first airframe, but after crashing it due to those pesky twin 25mm AA cannons I had to get into a new plane. The nav radio presets which previously worked no longer worked for the rest of the evening. No others reported getting the nav radios to work either. We could get a morse code signal if we switched the C-26 CW/Voice switch over to Voice, but that was AGA L (presumably Agana on Guam). I can attach a log if that would be helpful, I think my track file will exceed the 50Mb limit. peachpossum

yeah these are some vicious AA guns, and really tiny to spot and hit too!

Ah, a small detail I forgot to change when looking for the radio parameters for the Corsair in the ME -> aircraft type to client or player. I see it now and got things to work, thanks for your help fargo007! peachpossum

What terrain were you flying in? When I look for radio presets in the Marianas WWII terrain I can't find any radio presets for the F4U-1D. Also what frequency range, MHz or KHz? peachpossum

Also demonstrated in this mission; AI aircraft do not obey Advanced (waypoint actions); -No Report Waypoint Pass = off (AI-Corsairs) -ROE: Weapons Hold (EZ-fiters-1)

here is a track file & dcs.log that demonstrates the problem. I shot down 3 JU-88s, and the kill buffer awarded me the kills. Yet the three JU-88s went into a perpetual flat turn. This was a locally hosted MP mission. AI-Flat-Turn-Zombies.trk dcs.log

yep - saw this behavior last night in a MP mission I hosted. JU-88s, Bf-109s, and Fw-190-A8s all exhibited this behavior once they were severely damaged. edit - I tried adding my track file but it was too large (73 MB), any suggestions beyond running the mission for a shorter time period? dcs.log

I'm seeing the same issue, and I am not comfortable excluding these file from Windows Defender and risk a trojan. Please fix the update for the dedicated server. Thanks!

oh brother - I ran a repair of my DCS install and now things are working as expected (except this forum eating the text in my original post). Nothing to see here <whistles while walking away> peachpossum

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hi All, I have been away for a couple of weeks and there have been 2 DCS updates; DCS 2.9.16.10973.1 DCS 2.9.16.10973 Prior to these updates I have been able to join CFrag's Marianas Proving Ground Mission running on a friend's MP server. After the last two updates, I can no longer join the mission (the server line is grayed out), and DCS mission editor cannot "see it" to open it. -The top pic in my post shows the grayed out server hosting the Marianas Proving Ground mission -the middle pic shows the view from the DCS ME of the folder where the mission exists -the bottom pic shows the view from my Windows explorer of the folder where the mission exists. Any ideas? peachpossum

Well that's even more interesting, where did the text from my post go? There was text explaining the pictures, I guess I will write things out again.

Thanks Cfrag, I will give this a try. Appreciate your help! peachpossum

Ah, I found the link to DML; https://www.digitalcombatsimulator.com/en/files/3324851/ peachpossum

Hey cfrag, Thank you for the thoughtful response. I hadn't considered using scripting to check for map_object deaths. The ability to increase the 1 second periodicity of checking for map_object deaths is really interesting and worth learning more about how to script this. My scripting knowledge is very limited to using simple MIST or MOOSE scripts, the latter of which I really struggle to understand when I drill down into the specific AI or core functions. Would detecting the deaths of map_objects (or statics or ground vehicles, etc.) require using the aforementioned scripting tools, or would the Simulator Scripting Engine tools be the right place to start learning how to do this with scripting? I'm not familiar with DML's debugger, but I see you've posted a tool based on DML on ED's Users files site. peachpossum Hi Mistermann, Thank you for the reply regarding sounds. I usually use very short duration sounds for such events as the death of an object, mostly to draw the attention of the user to the text message that I program to appear. If I need a sound of with a sufficient duration such as announcing a new objective or such, I will often delay it to play after the duration of the previous text message, which is usually 25 seconds or longer. peachpossum

Hi All. I am curious about a couple of mission design approaches that may help improve performance Say I have a bunch of map_objects defined at a factory somewhere, and there are many of them. If I wanted to detect when each map_object was destroyed, I could use the trigger condition MAP OBJECT IS DEAD for each map_object, and have a trigger action play a short sound and display a message. If I have a lot of map_objects defined in the mission, which approach would be better for increasing game performance? option 1.) Use a ONCE trigger for each MAP OBJECT IS DEAD condition? option 2.) Use a SWITCHED trigger and list each MAP OBJECT IS DEAD condition for each map_object, separated by an OR condition? I've attached missions with each example. I realize the example missions may be too small to see any difference in performance between these options, but if I scaled up the objects by an order of magnitude would it matter then? A few other questions; - Would the better approach for detecting the death of map_objects also be better for static and/or ground units? - Is there a way to list all the flags defined in a mission? - When detecting the death of a static, is it better to use the condition:GROUP IS DEAD or the condition:UNIT IS DEAD? Thanks for your feedback. peachpossum cw_germany_map_obs_detect_option1.miz cw_germany_map_obs_detect_option2.miz

update: Good news! After poking around with some more things, I realized I had not updated my nVidia drivers to the 572.83 version from last week's March-18th update. ME mission load time (hang time) went from ~2min 20 sec to ~5sec, big improvement! peachpossum

I sent @miguelaco a message. In the meantime I double-checked my virus scan exclusions and added the more detailed logging from Flappie's autoexec.cfg file posted in the linked thread. I did notice my autoexec.cfg file had a lot of cruft in it, so I removed it and replaced it with the simpler version with more detailed logging. Still having the same long load time; hanging for ~2m 20sec. 2025-03-25 14:22:15.595 DEBUG LuaGUI (Main): Mission C:\Users\myusername\Saved Games\DCS\Missions\OP-Open-Gulf-1950-1995-CTLD-01.miz loaded 2025-03-25 14:24:36.098 ERROR_ONCE DX11BACKEND (22920): texture 'lns_vig_ext_wing_l_s' not found. Asked from '' peachpossum

Thank you for responding Flappie, Unfortunately, this information is not very actionable.

hi silverdevil, Yes, I have the following exclusions for my Antivirus scans; trackIR program roaming AppData for NaturalPoint (trackIR) DCS-SimpleRadio-Standalone program ~\Saved Games\DCS ~\Saved Games\edModelViewer ~\DCS World application

Ever since the update on March 5th, 2025 (DCS 2.9.13.6818.2), I've noticed the loading screen progress bar hang on loading into the Mission Editor or when joining the same mission on a dedicated MP server. This long delay has persisted with the latest update from last week (DCS 2.9.14.8222). My squad mates do not report longer than normal loading times when joining these missions on my dedicated server, so it seems reasonable to suspect my local machine (specs in signature). I've used the dcs-log-analyzer on Discord and followed the advice given; 1 - Disable Core Parking 2 - Disable Game Mode 3 - Disable Hardware accelerated GPU scheduling 4 - Disable Core Isolation After a fresh reboot I confirmed that all items above have been disabled. Steps to reproduce; 1 - reboot PC 2 - start trackIR 3 - start DCS 4 - open Mission Editor 5- open OP-Open-Gulf-1950-1995-CTLD-01.miz Expected behavior: mission opens in ME within 30 seconds Observed behavior: mission takes over 2 min to open, it hangs in one spot for 2m 20sec The same long load time behavior is observed when joining this mission when it is running on my dedicated server. The same long load time behavior is observed when joining this mission when it is hosted on my local PC. When loading from the ME, it seems to hang for 2m 20 sec at this point of the progress bar ( see hangSection.png ) In the dcs.log file, there is a similar gap in time (2m 13 sec) between line 872 and 873, indicated by yellow tic marks in dcs-log-ME-PG-1st-load-from-reboot-detail.jpg I've attached the mission & full DCS log from this example. Unfortunately, nearly all my missions exhibit this behavior. If anyone has any ideas I'd be much obliged for your feedback. dcs.log OP-Open-Gulf-1950-1995-CTLD-01.miz

I had a similar experience as ZeroDay. I must have crowded my regular FARP with support statics too close to the 4 pads on the FARP. Once I moved the statics a little further away (still on the FARP), the problem went away. possum

The ME has become unbearably glitchy & laggy and I just had to force-quit DCS from the task manager because the map in the ME would not let go of my right mouse button. No matter what I tried, everywhere I dragged my mouse the map moved with it and I could not activate any buttons within the ME. Log and MIZ attached. possum Edit: Hmm, after writing this post I noticed DCS was waiting for me to respond if I really wanted to quit, so I said no and saved the progress of my mission, also attached as -00c. Edit2: quit DCS, and uploaded a new log file dsc2.log OP-Murmur-00b.miz dcs.log OP-Murmur-00c.miz dcs2.log