shagrat

Correct, but they "can" incapacitate someone within 425m, through fragmentation. The current issue is that blast does damage to all objects inside the blast distance, instead of only a certain percentage. The biggest issue I see currently is, that bombs trigger other bombs in the air through blast damage. This definitely needs adjustment. But the correct approach is to adjust the damage dealt and set distance thresholds for bombs being triggered. Not reverting back to the old damage model where a bomb designed to level a couple buildings barely scratched some vehicles 50m from the impact... As for the concept of Risk Estimate Distances, we need to learn that RED with a PI 10 of 250 meters means you do NOT drop a live Mk-82 bomb closer than 250m to friendly forces and expect no blue on blue casualties, at least in real life. You may drop danger close (inside PI 0.1), if the ground commander takes the responsibility and accepts potential harm to his soldiers or civilians, but that's still a certain risk many NATO countries wouldn't accept...

Seeing Mossul mentioned, did the team have time to add some landmarks in the coming update? Asking for a friend... https://forum.dcs.world/topic/371325-details-and-landmarks-in-mosul/#comment-5630236

Maybe this visualization helps to better grasp what 425 m of "danger close" to friendly forces actually means. First picture represents a Mk-84 (2.000 lbs) bomb and shows the difference between the direct effects and the fragmentation radius "in the open". The second shows a comparison between the Risk Estimate Distances area. Note the 100m RED of the AGM-65 Maverick in the center, in comparison to the Mk 80 series bombs. Source is this article, PDF direct link: https://article36.org/wp-content/uploads/2016/10/PAX-A36-Areas-of-Harm.pdf

It's how a 500 lbs bomb works in real life. That's the reason why those special low yield weapons for CAS employment were developed in the War on Terror with the aim to minimize collateral damage. They even used training bombs (casings filled with concrete) to minimize damage to civilian infrastructure and innocent bystanders. Keep in mind the damage radius is ok, the time for fragmentation to reach the full distance will be slower than the current blast damage, but it will still incapacitate a couple people if fragmentation simulation is implemented later. Unfortunately blast is "hitting" every unit in the RED currently. So now we need to make the same tough decisions for CAS and choose appropriate weapons in danger close scenarios, as finally the "danger" in danger close is real... not ridiculous.

Analoge Uhr (Ziffernblatt) nicht, aber eine im IFEI unten rechts und mit TIMEUFC unten auf der HSI Page kann man eine im HUD einblenden lassen.

That's not addressing the issue. The problem is if you command any search, AI George will find the yellow "Unknown" outpost or workshop you added to a FARP in 25 km distance, while you want him to find the red infantry you currently look at that's lobbing tracers and RPGs at the blue MRAPs 4 km directly in front of you! The list now shows a couple yellow buildings in the distance and nothing else, so you have George scan for targets again, and again and again, only to get the same yellow buildings from the FARP now 20 km away, while you get too close for comfort to the AAA and infantry still directly in front of you. Even if you adjust the list display to Hostile & Unknown only, the far away and out of weapons range unknown outpost, is still clogging the target list. Now, with the new scan PHS Zone, why is George listing unknown targets 20-25 km away, if I clearly look at an orchard 3.5 km in front? If we had an option to force the AI (like telling our CP/G in real life) to only report HOSTILE (red) targets and ignore neutral, blue and unknown, especially out of weapons range(!) for building the target list, that would be great.

Solange du keine großen Dateien (50GB+) kopierst, speicherst oder viele (200+) kleine Dateien in einem Rutsch kopierst oder entpackst solltest es kein Problem geben. ...und das nächste Problem, diesmal inklusive Windows 10. (...)Streaming-Chaos nach Windows-Update Betroffen sind Nutzer nach dem Update auf KB5063878 (Windows 11 24H2) oder KB5063709 (Windows 10 22H2), die ein Network Device Interface (NDI) zum Übertragen von Audio- und Video-Feeds zwischen Computern verwenden. Die Probleme zeigen sich besonders deutlich in beliebten Streaming-Anwendungen wie Open Broadcaster Software (OBS) und NDI Tools. Nutzer berichten von Rucklern, erheblichen Verzögerungen und abgehackter Wiedergabe, selbst bei geringer Bandbreite. Die Auswirkungen werden besonders deutlich, wenn die "Display Capture"-Funktion aktiviert ist, die viele Streamer nutzen. Microsoft bestätigt NDI-Regression. Microsoft hat das Problem offiziell bestätigt und erklärt in einem Beitrag im Release Health Dashboard, dass die fehlerhafte Interaktion auftritt, wenn NDI für seinen Standard-Empfangsmodus konfiguriert ist.(...) Quelle: https://vmod.info/forum/index.php?thread/8922-windows-11-patch-day-übergangslösung-für-streaming-bug-gestartet/

Das Problem tritt bei allen Quellen nach der Installation des KB5063878 bzw. bei Beta Testern durch KB5062660 auf. Und das ist nur für Windows 11. Das letzte reguläre Update für Windows 10 war Out-Of-Band KB5066188, am 19.August, zum beheben des Recovery Mode Bugs aus dem letzten Security Patch von vorletzter Woche (12. August).

Yep, blast range is ok now, but the damage dealt over distance is A) a bit too excessive (my subjective opinion) and B) as it is a stand in for fragmentation too fast, as the fragments slow down faster. Keep in mind, if you dropped more than one bomb the damage is cumulative (also in real life), as the blast waves overlap (and IRL would interact). Also IRL an airburst Mk-82 would spray the whole site and damage most if not everything not armored. The thing here is damage modeling, though it has improved, isn't able to visualize things like crew incapacitated, a track of a tank damaged (mobility), though some effects are modeled. For example damaged units can't drive full speed any more, simulation of engine/mobility damage. So, yes, the current change is not perfect, but it is a big step in the right direction. For a long time, you could more or less throw a Mk-82 between a couple T-80 some 10m apart and if you were very lucky one got noticable damage. IRL the crews would have been heavily disoriented, or even injured, likely the tracks on the side of the explosion damaged and some of the optics and external weapons (DshK) damaged.

Yep, that's pretty accurate. 150m is less than half the 425m RED. So the fragmentation should incapacitate/render the majority of the site unusable, at least you would need to fix a lot of damage. As I pointed out above, currently the fragmentation is "faked" by blast damage, which is not perfect. Blast wave travels faster than fragmentation does. But actually DCS bomb damage felt like a joke, compared to real life, before. The adjustment definitely needs fine tuning, fragmentation calculated and in a perfect world even blast wave accumulation and reflection on objects, including over- and underpressure effects, but at least we now have bombs that can destroy/collapse buildings and do damage to vehicles without a direct hit! I am not sure if it's still linked on the GICHD site, but there was a nice damage area and damage distribution simulation linked, where you could see the distances on a simulated village. Also the document I linked, is really worth reading, especially the part of damage and casualty rates in urban areas (as secondary fragmentation increases the actual damage to people and unarmored/light armored vehicles). At least I hope there's an interest in understanding the real life effects and distances, with exactly the problems for weapon employment under ROE, which led to the development of low collateral damage weapons like the BLU-39 or BLU-129/B.

Wanna try? Open ground, no cover. I wouldn't recommend it! Even with eye protection, helmet and body armor... real life is different than computer games.

Also, there were modifications to the actual bomb body, that aimed at improving the fragmentation damage and radius. Like pre-fragmented casings, optimized materials and air-burst fuzes. In the recent conflicts the requirement changed toward less, but precise damage. Though typically that was addressed by separate low yield or kinetic weapons. I mentioned it in an earlier post, in DCS the difficulty is currently to balance the lack of fragmentation modeling with the effects of blast damage. Blast damage naturally travels faster than fragments. So the new adjusted blast radius is a stand in for fragmentation, which in itself is a step in the right direction and very much appreciated (finally a bomb, rather than a glorified handgrenade). On the downside, the danger to low flying aircraft is calculated by the fragmentation pattern over time, so with the blast reaching a low flying aircraft, way faster than the fragments would, we need to delay the bombs fuze in a HD low altitude attack, so we clear the excessive blast range faster. But we need to be aware, a friendly ground unit or helicopter inside the RED is not "safe". The "Danger Close" definition, is friendlies inside the 0.1 PI RED... and that's 425 m according to the GICHD document and other sources. If we assume it is a good idea to have cleared the airspace inside a 450 m radius around the impact point before(!) the bomb explodes, we should be safe.

...ever thrown a hand grenade IRL?

It's not necessarily the money, but the lack of qualified specialists in both programming and aviation including physics, that need to learn an unfamiliar development environment first... and if they exist they maybe already in a contract with aviation industry, military or both, which may or may not result in a conflict of interest, that prevent side-gigs at another developer.

No, I am aware of the process, typical timeline and do good expectation management. Or simply put, you might not be cut out for Early Access products, as your expectations mismatch greatly with reality.

Yes, absolutely. Only(!) three years, which is actually quite fast, for such a complex DCS module. And considering they did basically dump all the existing code base AND the 3D model and started from scratch along the current development (see interview below), that's an incredible development pace.

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.

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"!