Jump to content

peachpossum

Members
  • Posts

    71
  • Joined

  • Last visited

About peachpossum

  • Birthday 01/01/1887

Personal Information

  • Flight Simulators
    DCS World
    Elite: Dangerous
    ROF
    iL2
  • Location
    Wormtown MA
  • Interests
    flight, music, photos

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks Cfrag, I will give this a try. Appreciate your help! peachpossum
  2. Ah, I found the link to DML; https://www.digitalcombatsimulator.com/en/files/3324851/ peachpossum
  3. 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
  4. 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
  5. 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
  6. 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
  7. Thank you for responding Flappie, Unfortunately, this information is not very actionable.
  8. 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
  9. 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
  10. 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
  11. 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
  12. appreciate your feedback Ramsay, I'll give that a try.
  13. Has this issue been fixed yet? I'm having significant problems with the vertical axis TDC slewing of the IRMV seeker.
  14. Glad I did a search of this forum before posting a new thread. I'm having the same issues with default FOV in all my modules, as described in detail above. Thanks for the RCNTL-NUM0 x2 workaround. single monitor, 3840 x 1600, 60 Hz. Thanks for letting us know the plan is to fix this in a future update. peachpossum
  15. I have not personally tried this solution but others are reporting some success with editing the control binding LUA files. Editing control binding LUA files
×
×
  • Create New...