WobblyFlops

What people are likely referring to is this comment: This doesn't indicate that all the actual HARM modes will be included for the Hornet as well but rather that the seeker limitation will eventually end up getting modelled.

Sure, every developer is limited by certain constraining factors. Even if we don't talk about confidentiality issues or ITAR, it makes sense why DCS modules don't simulate every subsystem or interaction or obscure MFD page. However, I'd be willing to say that the priority should be shipping fewer but fleshed out systems as opposed to many that not only function in an unrealistic manner but also significantly degrade capability. The way to mitigate this, is to select a variant that requires system modelling that's possible based on available resources. If ED had chosen a Desert Storm era F-18C, the vast majority of these issues would not be a factor; no MSI, no datalink, very limited TPOD integration, very limited number of guided weapons.

The issue is that people aren't in a hurry, rather we are worried that systems that require a fundamental rework will simply never going to get fixed because it's cost prohibitive. It has nothing to do with early access, or waiting for anything.

This is a good question. A lot of stuff that's tagged as N/I in the manual makes sense to be that way when it comes to maintenance procedures, detailed comms ECCM stuff etc. But some of these missing TSD functions would be nice to have eventually. With that being said, these features aren't tagged as 'coming later', like the FCR or some datalink related stuff. I'm thinking that there's a chance this disctinction is made to showcase which features are planned and which aren't. Hope to be wrong.

Considering how the last time this was brought up, even radar related bugfixed where swept around the 'too classified' rug. We simply don't know what they plan to do, but the safe thing to assume is that ACLS will come and everything else will remain as is for the forseeable future. Since they clearly lack the resources to properly finish the Hornet, there should be some kind of community driven wishlist as to what bugs are most important to fix and what missing features should be prioritized. I'd say that MSI and the whole overhaul of the air to air suite is obviously out of the picture; it'd require an almost total overhaul of many mechanics and completely new features to be implemented. I'd say that if we forget the realism aspect, the current datalink correlation system is going to be close enough ish for the capabilities of other 4th gen platforms. It does not realistically demonstrate the capabilities of a real Hornet from the timeframe they are modelling but it's kind of 'useable' enough and it still has an advantage against realistic opponents from its own timeframe (Su-27, Mig-29), which sort of realistically represents the technological advantage that NATO aircraft had over Russian ones in the mid 2000s. The real big issue with the Hornet is the very degraded radar workflow you're forced to follow. What we really need is an actually implemented TWS AUTO (which is not easy to do at all, it took HB like a year to fully implement) and some of the quality of life aspects of the radar. Having the ability to set the scan centering in RWS, making sure that undesignate doesn't nuke trackfiles and having the ability to que TWS auto from STT with undes would be a massive improvement and I dare to say that having a realistic radar is better than having realistic sensor fusion. The other QOL features we'd need are the following: better slew rate on the radar page, the ability to designate L&S from the SA page, and showing datalink tracks on all the MSI displays.

I doubt our Apache pilots will be able to talk much about this system. Once the ASE video by Wags comes out, we'll learn more.

Wags said these rely on core DCS changes, so if it comes, it will come to all modules at once. When that happens, well some time between 2 weeks and 2 decades.

While I agree that napalm is probably - and sadly, depending on how you see it - is one of the most iconic weapons of the F-4, so it would make sense to implement it. But this relies on implementing all the planned advanced weapon functions first. With that being said, having napalm be a bomb with a different graphical effect is still preferable to not having it at all.

As far as I'm aware, ED took over all of the new weapon types. So if HB wanted to implement napalm or the GBU-15, it would be up for ED to actually add these weapons to the core game and 3rd parties would use the API to specifically implement it to the module and show the actual symbology and other aircraft specific behaviour. But the weapons themselves after the leave the jet are up to ED.

Chaff in DCS works like radar flares. Depending on the aspect, every piece of countermeasure is essentially a dice with a chance of success that's decided by the missile's ECCM value. The more chaff you put out and the closer you are to a proper notch, the more chances you have. If you're only going up against targets with radar guided missiles, putting out chaff as you're defending is only going to increase your chances of survival. Flares have some level of preflare modifier, the engine thrust value (AB, mil, idle) and each piece of flare also has a dice roll. Programs are essentially pointless, the more you put out, the more chances you'll have to roll high enough. Roll for deception!

That is true, I only corrected it because when it comes to navigation, there will be some level of inaccuracy when compared to real maps. I've never done any tests so unfortunately I can't give you an exact number or anything more tangible other than this thread: https://forums.eagle.ru/topic/105862-calculate-angle-distances-between-locations

I've been thinking about this stuff a lot lately. When it comes to general air to ground improvements, aside from the obvious AI/lack of DTC and other similar complaints, there are essentially three aspects that make the core game seem quite arcady compared to the modules themselves; 1.) Lack of proper weaponeering interactions and weapon effects 2.) Simplified damage model for ground units 3.) Simplified sensor limitations My intention isn't to list everything that's unrealistic and how to make it more true to real life (because that's not possible due to ITAR and it would cost so much money that no development company could ever finance it for consumer use) but rather how to address it in a gamified but still satisfying way. -Weapon delivery planner: The first way to address this is to make a weapon delivery planner that can feed into the upcoming DTC. This would allow you to take a weapon during mission planning and set it up on the ground. Select the proper fuze, set up arming time and function time realistically depending on what fuze you're using that's compatible with the weapon. So no need for inconsistent workarounds like selecting lazer code for a PW 2 from the cockpit and other fantasy elements. -Fragmentation: To allow proper weapon effects, fragmentation modelling is basically mandatory. Currently, explosives have an increased blast effect to compensate for lack of fragmentation but this isn't necessarily going to be a good tradeoff because frag pattern is shaped. Depending on terminal parameters, height of burst and other factors, you can tailor your frag pattern to match the desired effects on the ground. Frag also impacts a higher area than the blast itself and it can cause catastrophic damage against troops in the open or soft vehicles. To truly leverage this addition, we need better damage modelling. -Damage modelling: Ground vehicles simply need actual components that you can knock out, therefore it would allow M kills to happen. Ideally, you'd at the very least, you could target tracks/wheels, weapons, engine, crew and ammunition storage and sensors. An accurate penetration modelling would definitely be very complex and computationally intensive so I won't touch on that. This would allow dumb munitions to have very reasonable and grounded effects against soft targets, while PGMs would still retain their niche for K killing armored vehicles, but dumb weapons would still have some limited use against them. (Knock out the track and the tank can't move, destroy the main gun and it can't fire). This is essentially adding hitboxes, so with some randomization, if the fragmentation modelling exists, it should be comparatively easier to do. For buildings, modelling impact angle, penetration and other interactions would be very costly to do accurately but the current modelling also can't stay as is. My proposition, have classes of hardened buildings that penetrator warheads would have a damage bonus against based on their impact angle. The closer you are to 90 (and the faster the weapon is), the bigger the damage. Set up a threshold based on the angle and the impact velocity and if it's exceeded do catastrophic damage. Traditional warheads should have drastically reduced effects against targets that are classified as hardened. However, another class could be buildings with multiple floors, which could interact with delay fuze and if you drop without a delay, you'd deal less damage. The really nice step here would be classifying based on different height; the higher the building, the more delay you need to hit the base and deal catastrophic damage. If they'd want actual penetration modelling, it could be done based on location of hit, impact angle and velocity, but this requires either actual hit calculations and defined, specific armor type and thickness based on area and for buildings, orientation and material type, which can be quite computationally expensive. -Sensor limitations Here there are a couple of specific things we'd have to simulate. 1.) Dumb bombing and CCIP: A randomized error that represents the bombs' inherent inaccuracy that results in a much higher CEP for dumb bombs. This would represent the inaccuracy that's associated with atmospherics and the natural slight deviations between each bomb as they come off the rack, stabilize themselves and fly in the air. The other part of the equation is to simulate errors in the CCIP calculation aside from elevation differences, mainly improper G at release, which can throw off the computed solution and put your bomb out to lunch. Also, the solution shouldn't be perfect, it should require a more or less stable jet to have an acceptable CEP. The current magical solution that can instantly compensate for changing bank angle, yaw, increasing load factor and whatnot should be a thing of the past. CCIP is inherently inaccurate in real life and to have a decent probability of destruction against the typical DCS targets, you'd have to saturate a higher area. One bomb one kill is simply not how it should work. This would also allow the modules to accurately represent the different ranging sources for the calculation. If you have no DTED, no radar or radalt, no TGP and a wrong altimeter setting, the computed solution should be garbage. 2.) LGBs: This is a pretty complex topic, with many well documented limiting factors. The biggest one is atmospherics, spot size and the podium effect. This would make it necessary to train for buddy lazing in certain situations and to mind your attack geometry. 3.) IAMs: The big issue here is TLE and altitude error. The simple way to demonstrate this is that if you're attacking pre planned target where you have properly mensurated coordinates the TLE should be a no factor. If you willy nilly designate something through a TGP without lazing and at a shallow enough angle at a high enough slant range, the coordinates you get should be completely useless. The DPI should be represented as a 3D location, where altitude errors could be compensated for by increasing the impact angle. Against vertical targets that you can't attack in the horizontal plane, the big consideration should be that too shallow impact angles could result in case slap and a dud. This would practically require all modules to adhere to the programmable terminal parameters for IAMs. Using penetrators at a steep impact angle against hardened targets should also be a practical application of this. Most of this stuff isn't necessarily 100% realistic and it drastically simplifies the whole picture but it would mostly rely on classes of objects and hitboxes and not on real time calculation of penetration effects. The potentially difficult part is the fragments, but that's eventually coming, plus they want to add in things like actual JPF, programmable term parameters and things like that. These would greatly increase the fidelity and make the actual in game experience reflect at least some parts of what real life mission planning should account for.

Winds in DCS are confusing as hell. The briefing and the mission editor shows you the direction the wind is blowing to as opposed to what everyone uses; where it's blowing from. I can see that you know this, which is good. Someone mentioned true north, which is incorrect. In DCS, the mission editor shows grid north as opposed to true north. What you're likely missing is described here and that's the wind compensation between layers: https://forums.eagle.ru/topic/103956-cdu-wind-correction-done-right/ The last page describes a step by step process that will allow you to do it right, although as mentioned earlier, this is very rarely if ever done in the real aircraft.

Sure, but radar limitations and nuanced interactions in DCS are generally not simulated.

The more I learn about the Apache, the more sense it makes to kind of think about it as a flying MBT/MLRS as opposed to approaching it as a fighter jet that can hover and fly really slow.