All Activity

Hey QCumber I am using 1920x1080 in the DCS meny system page, is that reolution you were thinking of? Is there a better option?

I'm glad you all like it! I already have a script that lets warships (Arleigh Burke–class, Ticonderoga–class) launch Tomahawk cruise missiles! Link: https://forum.dcs.world/topic/374049-automated-cruise-missile-strike-script-v1 HAVE FUN! The Scud-missile version is expected to be added in the next few days!

I decided to continue and sent my Log for comparison. I have i9-12900K 3.20 GHz Comparison of the Two DCS Log Files I've analyzed the provided log file (dcs.log from August 25, 2025) and compared it to your previous log (dcs.20250821-202548.log from August 21, 2025). The comparison focuses on key differences in system configuration, warnings, execution flow, and outcomes. This helps explain why the previous setup experienced crashes while the new one appears stable. I'll structure this as a table for clarity, followed by an explanation. Aspect Previous Log (Aug 21, i9-12900KF) New Log STONE SKY (Aug 25, i9-12900K) Implications Installation Path & Version D:\DCS World\bin\DCS.exe (Stable, MT version 2.9.19.13478) G:\DCS World OpenBeta\bin-mt\DCS.exe (OpenBeta, MT version 2.9.19.13478) Minor difference; OpenBeta may have slight patches, but same build number. No impact on crashes. Windows Build NT 10.0.26100 (Possibly Insider/preview build) NT 10.0.19045 (Stable release build) Preview builds can introduce instabilities; stable build is less prone to OS-level issues. CPU Model & Config Intel i9-12900KF: 16 cores, 24 threads (hybrid: 8 P-cores/16 threads + 8 E-cores/8 threads). Efficiency classes: Mixed (class 1: cores 0-15; class 0: 16-23). Performance classes: Varied (class 3: 12-15; class 2: 0-11; class 1: 16-19; class 0: 20-23). Affinity: All cores used, IO on E-cores (16-23). Intel i9-12900K: 8 cores, 16 threads (appears to be only P-cores active). Efficiency classes: Uniform (all class 0). Performance classes: Varied but simplified (class 1: 8-11; class 0: 0-7,12-15). Affinity: Common cores {4-7,12-15}; Render on {8-11,0-3}; No IO cores listed, no unavailable cores. Key difference: E-cores seem disabled in BIOS on the new setup (reducing to 8 cores/16 threads). This eliminates hybrid CPU issues. Hybrid setups often cause DCS instability in multi-threaded (MT) mode. RAM 32 GB (32556 MB) 64 GB (65303 MB) More RAM in new setup reduces memory pressure, but unlikely the primary crash cause. CPU Warnings Explicit warning: "CPU HAS PARKED LOGICAL CORES (this can be source of stuttering and reduced performance especially on hybrid CPUs with P/E-cores)". No such warning. Core parking (Windows power-saving feature) on hybrid CPUs leads to desyncs and crashes in DCS MT, especially in CPU-intensive modules like AH-64D. Disabling E-cores prevents this by avoiding mixed core types. Scripting Errors Present (e.g., "No preset named 'MDRN_B_A_PGM_HTP'" in HeavyMetalCore for B-52H/B-1B). Identical errors present. These are benign vanilla DCS issues; not causing crashes. Mods & Plugins Loads mods like Currenthill Assets Pack (replaces units); same plugins start/end. Identical mod loading (e.g., Currenthill Assets Pack). No difference; mods aren't the culprit. Audio Devices 4 devices (Headphones, Speakers, Digital Output, Monitor). 4 devices (Digital Output, Monitor, Oculus Virtual Audio, HD Audio 2nd output). Slight variation, but no errors in either; irrelevant to crashes. Execution Flow Loads modules, but crashes during simulation (ACCESS_VIOLATION in AH64D.dll during ExternalFM sensor/timing calls). Ends with crash dump. Loads modules, initializes Syria terrain, handles object position errors (non-fatal), then normal shutdown. No crash; log closes cleanly. Previous crash tied to AH-64D FM/sensors under hybrid CPU load. New log shows stable run, likely due to uniform cores. Timing & Outcome Starts ~17:56 UTC, crashes ~20:25 (long session?). CTD to desktop. Starts 14:21 UTC, normal exit ~14:31 (short test?). Successful shutdown. New setup avoids the violation, confirming hardware config fix. Explanation and Insights Root Cause Resolution: The previous crash was an ACCESS_VIOLATION in the AH-64D module, triggered by core parking on a hybrid Intel 12th-gen CPU (P-cores for performance, E-cores for efficiency). DCS MT is sensitive to this, as it assigns tasks (e.g., IO to E-cores), leading to memory access issues during high-load operations like flight model (ExternalFM) or sensor processing. In the new log, E-cores are disabled (evident from reduced core/thread count and uniform efficiency class), eliminating the parking warning and crash. This is a common fix for DCS on 12th/13th-gen Intel CPUs, as hybrid architectures can cause stuttering or CTDs in VR/multi-threaded scenarios. Why It Works Now: With only P-cores active, DCS runs on consistent high-performance threads, avoiding desyncs. The increased RAM and stable Windows build may help marginally, but the CPU change is the key. Recommendations: If this is the "other comp" without crashes, replicate the setup on the first PC by disabling E-cores in BIOS (under CPU settings, set E-core count to 0). Alternatively, use tools like Process Lasso to force affinity to P-cores only. Test in a mission with AH-64D to confirm. If mods like Currenthill are still suspect, remove them temporarily. It's still not certain, sir! I hope you will continue your investigation and find the cause. We should probably wait for the new distribution of tasks for cores in the AH-64D mod. I don't remember exactly, but I did some kind of processor setup in the BIOS after assembling the PC. Probably this issue also requires study, judging by the comparison table of our processors

What resolution are you using?

This was difficult for me, I used the Grock AI, if you don't mind. We seem to have a direction where to look for the problem. But I'm not sure. This is the AI's analysis, not mine. Type of Error: ACCESS_VIOLATION (code C0000005). This indicates an attempt to access memory that is either non-existent or protected (e.g., null pointer dereference or data corruption). Crash Location: In the module AH64D.dll (D:\DCS World\Mods\aircraft\AH-64D\bin\AH64D.dll), which is responsible for the AH-64D Apache module. The stack trace shows calls from ExternalFM (external flight model) for AH-64D: ExternalFM::AH64::AH64FM::setImmortal + 0x10EC5 ExternalFM::AH64::AH64FM::getSensorsSystem + 0x29115 ExternalFM::AH64::AH64FM::setImmortal + 0x15D97 Followed by transitions to CockpitBase and World (DCS simulation core). Context: The crash occurred during simulation or loading, likely when DCS was processing cockpit device timers (cockpit::avDevice_BasicTimer::NextEvent) or the event calendar (wSimCalendar::DoActionsUntil). This happened shortly after launch (log starts at 17:56:29 UTC, crash at 20:25:48, though this could be local time; actual launch ~17:56). DCS Version: 2.9.19.13478 (MT - multi-threaded version). This is a relatively recent build (build 376), possibly beta or open beta as of 2025-08-21. System: Windows 10 (NT 10.0.26100), Intel i9-12900KF CPU (16 cores, 24 threads, hybrid with P-cores and E-cores), 32 GB RAM, NVIDIA GPU (based on loaded DLLs like nvwgf2umx.dll). 2. Key Findings from the Log CPU Warning: The most notable line is WARNING EDCORE (Main): CPU HAS PARKED LOGICAL CORES (this can be source of stuttering and reduced performance especially on hybrid CPUs with P/E-cores). This directly points to an issue with core parking—a Windows mechanism that "puts to sleep" inactive cores to save power. On a hybrid CPU (like your i9-12900KF with Performance-cores and Efficiency-cores), this causes instability in multi-threaded applications like DCS. Similar crashes are described in threads such as "DCS World - Force CPU Core Parking" (DCS Forum, 2025) and "DCS 2.9 stuttering with 12/13 gen Intel CPU" (Reddit, 2023). Many users with 12th+ gen Intel CPUs report CTD (crash to desktop) issues with AH-64D due to this. Your log shows the CPU affinity mask using all cores, but with different efficiency classes (P-cores: 0-15, E-cores: 16-23), and DCS assigns IO tasks to E-cores (16-23). This is not a bug in the AH-64D itself but a system incompatibility exacerbated by the module (AH-64D demands significant CPU resources for its flight model and sensors). I hope this helps. Naturally, this should be double-checked.

Try this example: test.miz

RWR issues? It's almost like the closer a radar gets the stronger the signal.

Got it consistently inconstant.

I was wondering if anyone can teach me how to create a mission of a Tu-22M: 1. Take off from Airbase A from a parking spot 2. Attack a ship 3. Land at the same base I have tried but for the life of me, I can't get it to engage the ship. It always seems to not engage the target. It just flies back to base.

Раньте это делалось длинным зажатием команды вниз взаимодействия с ИИ Джорджа. Перечень команд был в виде таблицы в самом конце мануала, в разделе «GERGE» AI. Мануал обновился недавно, под рукой нет. Были большие изменения Джорджа в крайних патчах. В описании этой команды должно быть что-то типа … regenerate target list

Thank you Bankler！ Learned alot！FINALLY！

Same testing parameters, Only difference is 35k ft altitude. All have been done with full fuel & no fuel only to see if how much of a factor weight was and tested over a 40nm span, Which the differences in fuel of that have been incredibly insignificant. "2x PL-5 + 4x SD-10: Max Speed of Mach 1.15 before complete fuel exhaustion" This of them all is the biggest concern with it all, Now let me also say I am not questioning this in a sense of I am right and it is wrong. I just merely don't understand how a loadout similar to; "2x PL-5 + 2x SD-10 + 2x GB-6 SFW" Has a 45% higher drag value, weighs more (I will see exactly how much more later when I am home) and somehow gets closer to its top end much faster than the first loadout. While at the same time only reflecting a 15% difference in its top end.

Давно не летал на Апаче. Забыл каким образом вызвать список целей Джорджа , НЕ ОТДАВАЯ КОМАНДУ НА НОВОЕ СКАНИРОВАНИЕ.? Раньше так делал для экономии времени. Кто подскажет?

Hi ED team, This is a safety request. I fly DCS with a motion simulator chair. I use Sim Racing Studio (SRS) to read DCS telemetry and drive the rig. The problem is what happens after the player aircraft is destroyed: the airframe tumbles unpredictably and the telemetry reflects that. SRS dutifully follows the data, and the rig thrash violently, without a secure harness, a user could be thrown around and potentially injured. The first thing I did is contacting SRS support, and this is their replay: I’m not asking for a gameplay change. DCS is already amazing. I’m asking for a small telemetry addition that would let SRS (and other motion software) switch to a safe profile as soon as the player’s aircraft is no longer flyable. Proposed solution ( any of these would work ) A boolean flag: playerAircraftDestroyed (true/false) An enumerated field: playerFlightState = { Normal, Ejected, Crashed, Destroyed } Why this helps: Third-party motion apps can immediately cut motion or fade to a neutral pose when the flag/event appears. This is backward-compatible, doesn’t affect gameplay, and meaningfully reduces risk for motion-rig users. Thanks for considering this. It’s a small change with a big safety impact for a growing part of the DCS community.

@Flappie @BIGNEWY Any chance of having this as feature similarly to the R-60 control box?

Hello @Charley, Did you check the Hyd pressure? I'm not sure if this could be the reason, but next time you have the issue, retract the gear and flaps, make sure pressure is within limits and then lower gear ... And then flaps.

Anti-aliasing in DCS graphics-meny seem to have an impact. DLAA gives the best image both close up and at distance (for me). Pixel-densnity and Texture Resolution in the DCS graphics meny also seems to have a large impact aswell. In my Hornet flying VR I can see the HUD very good, but I have to lean forward a little bit to read text on dials (but actually in real life I have to do that aswell to be honest :)) Here is my thread about my current settings, performence results and things I discovered up to now:

I don't know your testing parameters but in my tests, the JF-17 with CMBT engine mode, full internal fuel, QNH 29.92, +20°C, 30k ft altitude hold, starting speed of Mach 0.75 are this: 2x PL-5 + 4x SD-10: Max Speed of Mach 1.15 before complete fuel exhaustion 2x PL-5 + 2x HF20 - 16x BRM-1 rockets: Max Speed of Mach 1.04 before complete fuel exhaustion 2x PL-5 + 2x SD-10 + 2x GB-6 SFW: Max Speed of Mach 1.00 before complete fuel exhaustion With all three payloads generally starting to plateau in speed after 10nm traveled with the 2x PL-5 + 4x SD-10 loadout taking the longest to get to the max speed I recorded. The values presented for the HF20 with the BRM-1 rockets in the post by AeriaGloria are incorrect, as they have an effective payload drag value of 8.192 (0.002 * 4096) for one pod. I would personally attempt to double-check the payload drag values themselves for inaccuracies since the ones posted don't seem to be 100% accurate. I personally do not see anything wrong with the drag for these weapons. The only gripe I have would be the payload drag for the LS-6-250 being the same as the LS-6-500.

Good luck buddy with your purchase! Let me know how it went

Pictures please? (the only reference I have is here - while it may be that this picture doesn't do the the map justice, I actually like Syria more; at night that is.

Hi again guys! I have only 2 things to add to my post above. In Virtual Desktop I had to set OpenXR Runtime to VDXR. Also connecting a high speed internet- cable between my PC and my Router (a LAN cable) improved performance also. Performance also seems to be dependent on map and module (how well optimised they are). What I noticed is that generally EDs modules runs the best (for me atleast). Best performance I get with the F-18 Hornet and Viggen. Apache also has good performence. Worst for me seem to be Chinook and Hind. So I am right now playing F-18 Hornet and Viggen on Cacasus and Syria Map. I get solid 72 FPS in singeplayer and solid 30-40 FPS in multiplayer, without any crashes or disconnects.

DIY F16 DED Screen Instructions - Tekcreations Is it just me? I bought the hardware. Other than moving the resistor, I followed the instructions and have had no problems at all.

I have put everything I have in that mission into one ship and it's still trucking along, drives me nuts.

These goggles are far more realistic than the full screen NVG. Have you tried adjusting the gain on them? I have to fine tune it depending on the ambient light constantly

There is no crash in this log, was it taken directly after one? What do you actually see when it crashes? Check if you have any dcs-logs-<timestamp>.zip files as well around the time of the crashes. This log only shows some errors from what I'm assuming are your Echo9 mods. Might want to remove those, run a slow repair, and see what happens. It also shows you are running Process Lasso, do you need to? If this is a log after a crash then it is possible that Windows is killing the process. Run the Windows DxDiag tool, save the report, and attach it here.