shagrat

Pre-ordered! Thank you for your hard work. This will be one hell of a flight experience. Despite the perception, that there's not "much to do for a C-130J in DCS" I can't wait to do all those things we will be able to do! From supply drops, combat landings on improvised short runways, cargo delivery on a dynamic multiplayer server, to the MC-130J and infil and exfil of SpecOps teams behind enemy lines or in the Hindukush mountains in weather and at night... And the impressions from the pre-order trailer are awesome. Really looking forward to this gem!

Spekulation, aber ich vermute es wird wie bei der CH-47F mehrere Crew-Stationen geben und man kann bspw. nach hinten auf die Loadmaster-Station wechseln, während der Autopilot an ist, und Kurs hält, bzw. "Bob, der virtuelle Co-Pilot" die Maschine fliegt... Ich denke es wird auch die Möglichkeit geben Dinge wie den Frachtabwurf aus dem Cockpit (per Menü?) auszuführen, ohne extra auf die Loadmaster-Station wechseln zu "müssen". Bin mal gespannt, das Video sah sehr vielversprechend aus. Pre-Order ist erledigt. Das Anubis C-130 Mod wahr schon genial, aber das sieht nochmal nach ganz anderem Level aus.

Unter dem Balken stehen die Daten zum Download (also was tatsächlich durch die Leitung muss), oben steht der Fortschritt beim Entpacken und "installieren" austauschen der Dateien. Je nach Blockgröße deines Datenträgers können viele kleine Dateien eine ganze Menge mehr "Größe auf der Festplatte" haben, als ihre reine Datengröße. Und da DCS extrem viele Textbasierte Dateien hat, die sich extrem gut komprimieren lassen, ist das tatsächlich der größte Download mit 101 GB, nicht 180 GB.

This is an advanced feature of your windows OS and filesystem implementation, designed specifically to allow for flexible redirection, virtual folder integration (e.g. adding the same Missions or config folder to multiple DCS instances) and is used in professional IT systems, a lot. I don't mean to be rude, but it is definitely worth to learn these advanced options of your Windows OS, not only for DCS...

Well said! I absolutely agree. I know the intention of the original comment was to point out, it is a bit of advanced scripting, but the attitude of "if you don't have at least A certificate and 3 years experience in any major script language and already know lua, you won't understand" doesn't cut it. Every(!) DCS creator started learning the DCS scripting environment by reading the documentation, researching hoggit, looking at other scripts AND mostly, kindly asking this awesome community for help! And help was given, not snide comments. To make use of the new scripting features it is necessary to understand what they do, how they do it, and especially with the security implications, in a way that people don't fall back to the usual "just give every permission and it works". I've seen so many YouTube videos, posts and comments in scripts, that tell people to "just comment out the following lines" to de-sanitize the DCS lua environment and the script works fine... Some at least point out, that this means you should review ANY script in every Miz file and make sure it doesn't contain malicious actions on the io or lfs environments... but, like cfrag pointed out, my guess is the majority does not understand the implications and just did it, to "make it work".

You can use windows file system junctions for that (distribution of folders to different drives), but I recommend a dedicated 2TB SSD for DCS, I have mostly everything, installed and a bit less than 1.2 TB used.

Depends on maps and modules owned and installed! There was an update to the Sinai map that was huge, and if you have a lot of Modules that get fixes, the overall install size of DCS can get quite large. During downloads, decompressing the downloaded stuff and installing/replacing the files, it requires some additional, temporary space. If you have everything on the same disk/SSD, you should clean up things like track files (especially the large multiplayer ones), if you use TacView delete old TacView files and if that doesn't free up enough disk space, consider, temporarily deinstalling currently not used campaigns, modules or maps, until you can add a larger or better dedicated game / DCS disk or SSD.

You may want to read up on what "reverse engineering" is actually referring to. The result "can" infringe on patents, but it is by no means "illegal" in itself... As you pointed out, the culprit is, if any NDA or other legal binding agreement between both parties forbids reverse engineering.

Any detailed information on this? Maybe examples, how to make use of it? I understand now it's possible to exchange arguments between, say "mission" and "GUI" or "export" environment, so that sounds very interesting, but I am not sure I understand the purpose correctly. For example I would love a way to pass the TGT point coordinates visible in a TGP or on the MFD of a module to the scripting engine to use in scripts to call in a bomb on coordinate or verify a player in Multiplayer "looks" at the correct object, without crude workarounds like reading markpoint text...

Didn't read all ideas, yet, but easiest solution, would be to monitor the convoy actually reaching a zone ( with a number of X vehicles / health percentage) and thus indicating, it has successfully made it through the ambush. Thus the goal is still achievable and you need to ensure the convoy is really "safe"!

That's why I suggested to add it to the George menu setting for IFF that's already implemented. To be able to switch on the fly. Long press already allows to filter the list, we only need an option to "don't show anything else than red" because currently if no red targets are found George will fall back to blue targets. If that's not possible, put it in the Mission Editor similar to the checkbox where we can disable searching for air targets, so the mission designer can decide what is required for his mission design.

Nope! "Invisible" only affects the spot logic of the core AI, as a way to switch, between automatically engaging everything that's enemy coalition. George is a separate logic and ignores that one. Currently there's no way in DCS to "hide" units from George. Even late activation won't work if set to "visible before activation"... Also the idea isn't to have George completely ignore "hidden" units, but require a deliberate scan by the player on the suspected location to "find" a concealed enemy unit.

Not sure this is easy to implement, but here's the idea. I would love to "hide" a concealed sniper or certain static objects (weapons cache) from George AI in missions. Currently if George has LOS and is close enough, he seems to spot ANY unit easily from 4-5 km whereas a human CP/G find it quite challenging to identify the Infantry AK-47, kneeling behind the mudwall on a building with his head barely showing. I know it's a bit contradictory, as often we complain, that George fails to see the enemy, as well. So if possible, can we use the Mission Editor options: Hidden / Hidden on MFD / Hide on F10 map and if "Hidden" is selected George needs to be commanded to point search and only if the unit is in a narrow cone (2° ? ) and close < 4 km George will "find" it and show in the target list. This would allow incredibly interesting search mission design, surprise ambush scenarios where you could preemptively search a "suspicious" compound or orchard and find the BRDM waiting for you, but if you look at the wrong compound a bit left, you may miss it and get attacked... Sniper searches, where finding the target in build up areas or hidden between bushes or orchards is actually challenging, despite using George.

Add an option to have George only list identified enemy (red) targets show in search list. I suspect in real life Apaches the CP/G won't announce any friendly car, or building he sees on the TADS unless the pilot explicitly told him so. Currently, we can set red as priority, but if commanded to search and no red units are found blue units still populate the list, so we need to cancel the list, search again, rinse and repeat. We can deactivate "Air Targets" in the Mission Editor, but it would be nice to have an option to ensure all neutral and blue units found are NOT populating the target list (of course a blue unit "misidentified" as red would still show). What we currently encounter regularly, is George searching PHS LOS, not seeing any of the red units despite the tracer fire clearly visible in the TADS FLIR, instead finding the blue Outpost 3-4 km behind the engagement and constantly listing the outpost in the target list! So either we need to - adjust the George menu (Target list) to switch between "ALL", "RED PRIO" and a new "RED ONLY" or - add an option to the Mission Editor to select "Show in Target list" and check red, blue, neutral.

He does prioritize targets, already. He just doesn't magically see everything, so he may see the couple dozen Infantry AK-47 and a HL DShk, but not the MANPAD behind the building and prioritizes the HL DShk, until you command a new search... But that should get better, with the updates planned in the mini update thread.

+100 With the new statics we can create the COP and fortifications, but the iconic hill and corkscrew road leading to the top need to be modeled as terrain.

Keybinds have been added with 1st July 2025 update! Thank you ED team.

Jupp, die müssen soweit ich weiß mit dem jeweils aktuellen Schlüssel versehen werden. Leider ist das zum Schutz des Intellectual Property mittlerweile notwendig. Jepp. Es stände ihm gut zu Gesicht einfach mal im autoupdate_log.txt nachzuvollziehen was der Updater wirklich tut, anstatt wild zu spekulieren.

Absolut richtig, man kann das sogar mitlesen, beim Updater, wenn zuerst alle Dateien die aktuell auf dem Rechner sind überprüft werden, dann die geänderten zu der Update Version identifiziert und nur diese dann komprimiert (und in einzelnen Paketen) heruntergeladen werden. Oben sieht man im Updater dann auch schön, wie die ersten Pakete, parallel zum Downloaden bereits entpackt (de-komprimiert) werden. Was tatsächlich vorkommt ist, daß erst der eigentliche Updater upgedatet wird, dann das Update geladen wird, und wenn man bspw. im Sale 3-4 Module neu hat und diese mit ausgewählt hat, werden die als separate Pakete mit derselben Methode, sequentiell runtergeladen und installiert, innerhalb des Updaters. Steht im Prinzip auch alles im autoupdate_log.txt im DCS World root Verzeichnis.

Yes and no. There's some information in the GICHD documents. The RED describes 10% and 0,1% ranges for damage to human bodies, so we can assume there's fragmentation, at least up to that distance. The problem I see, with the current increased blast model, is fragments will slow down faster than the blast wave and that's why we end up in the outer edge of the damage zone from the blast. So your observation is definitely valid. Guess, there's still some tweaking needed. But it's better than before.

☝

Looks like part of the problem is, the blast traveling faster than fragmentation would after the initial lethal zone. But in general this is still an improvement, though it needs a bit of fine tuning. IRL the whole process of a bomb explosion is even more complex. Blast waves in urban areas do produce additional damage, through reflection of house fronts, funneling along streets and alleys and enhanced fragmentation from material propelled by the blast. Whereas in an open field, with little to no obstruction the blast disperses evenly and even a small mound of dirt can deflect a blast wave "over" a human lying prone... but I guess this will take CPU power from a distant future to do on a home PC.

I just looked up an old reference for the F-5E that has the fragmentation envelope of a Mk82 and Mk83 The maximum height is 2520 ft, 9 sec after the explosion, for the MK82 and 2820 ft, 9 sec for the Mk83. I guess the adjusted blast damage is similar to the damage on the ground so below 1000 ft? Assuming the real life fragmentation heights, and planning for a safe escape maneuver above 3500 ft, should keep us out of harms way... though I still need to test/verify this assumption.

Hm, those reflect, what you program in your aircrafts mission computer, IIRC, at least for the A-10C. You enter the abort altitude and that's what calculates the HUD abort cue, based on your current flight envelope. ...and, again IIRC, it doesn't know the height above ground, but you need to plan your mission, figure the height of the target above MSL and calculate the correct safe barometric abort altitude. This is what you enter into the profile.

You mean finally manage to destroy an unarmored truck that's as close as 500ft (~150m) to a 1,000 lbs bomb? That's actually good news. Thank you ED. For some context, according to statistics compiled by the GICHD (Geneva International Centre for Humanitarian Demining) the typical lethal area of an Mk82 (500 lbs) is 80m by 30m (260ft by 100ft) with RED (Risk Estimate Distance) of 250m(!) for 10% (one in ten) people incapacitated! ...and that's just the "small" 500 lbs Mk82. Here is a link to the GICHD website for research: https://www.gichd.org/our-response/policy/explosive-weapons-in-populated-areas/ Direct PDF download link for the MK82 study (Annex-E): https://www.gichd.org/fileadmin/uploads/gichd/Publications/Explosive_weapon_effects_web.pdf Seems they are now quite close to real life, so proper parameters and planning matters.