Jump to content

WobblyFlops

Members
  • Posts

    229
  • Joined

  • Last visited

Everything posted by WobblyFlops

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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!
  11. 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
  12. 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.
  13. 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.
  14. Sure, but radar limitations and nuanced interactions in DCS are generally not simulated.
  15. 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.
  16. It's a good module, sure and the functionality is absolutely there, but there are quite a few painful ommissions even if we don't count MSI. All the IAM features, fixing the CCIP bug, fixing all the bugs and simplifications related to the radar, the missing HOTAS functions and the improper DDI autopage logic when it comes to master mode swapping, the incorrect RWR thread bands and the lack of map slew function, just to name a few. The missing radar modes would also be really nice to have, all the third party modules implement every radar mode, even the "useless" ones. Another year of development could fix all these issues. On top of this, nice to have would be finishing all the BITs, implementing the target data page and a functional MIDS page and finishing the missing weapon submodes and functions. (Cooperative MITL launch, certain Harpoon, HARM and Maverick functions, etc.)
  17. 97s use the FZU-39, which is a radar based proximity sensor and uses AGL for HOF. I've heard of older fuzes that may use MSL (based on barometric altitude) but I don't know which ones specifically.
  18. This is not true. When people asked on the Razbam Discord about how they'll get data on the Strike Eagle, Prowler said that it's a licensed product, implying that they get access to some level of data. ED also has authentic Betty recordings alongside some other things, so it's very safe to assume that Boeing gave them at least some kind of data. It's possible that with data there can limitations as well.
  19. It's also possible that these features have open source, legally available documentation for the Viper but none for the Hornet. (Remember, just because you can buy a manual online that describes how that works that won't necessarily mean that a company making a product through legal channels can use the same manual.) Obviously there are some really easy pickings when it comes to the missing features (like the map slew, I mean come on, that one is just indefensible) but assuming that certain features will get implemented to module A just because they were implemented for module B is not necessarily going to be the case. The Hornet is a licensed product and they may very well be under heavy limitations as to what they can implement. For the MSI stuff, I simply can't believe that ED didn't know what it actually stands for and how it should behave. I mean Wags surely knows more about the Hornet than all of us, non SMEs combined. It's his favourite aircraft as far as I can tell and he even worked on a previous Hornet simulator that for its time had these things implemented at a suprisingly high fidelity. The MSI is one of the most famous features of the Hornet, it being the first example of proper sensor fusion. No one should believe that they simply didn't know how to actually implement this stuff or what's missing. It's much more likely that the contract limits them when it comes to fidelity. Case in point, preplanned threat symbols are possible for both yet they aren't simulated in the A-10, and based on the last post by Nineline regarding the topic, it may never even be allowed to be implemented. I'm sure that eventually the Hornet will have all the easy pickings and bugs added and fixed but I personally wouldn't expect anything more than that. A realistic expectation is map slew+waypoint creation, ACLS functions, the ability to designate from the SA page and see offboard datalink tracks on the Az/El display. To actually properly finish the Hornet, they'd essentially need to rework the entire trackfile correlation and memory logic and rebuild certain functions with MSI in mind plus fix at least 10 radar bugs, many of them are incredibly complex and intricate.
  20. Sure, you don't have to simulate the internals of the FLIR pod and work out how the sensors actually IR information and output it on the display. But simulating real life interactions and more importantly limitations allows to have a faithful recreation of the experience of operating such a system. I also don't think it will amount to any of this stuff, but it's nice to discuss what the ideal implementation would look like. Without proper multicore support and Vulcan none of the deficiencies can be corrected aside from ATC. The core game needs better AI, better damage model, better weapon and sensor simulation. The only way any of this stuff is possible if they actually update the engine so that it can utilize modern hardware better, which they are already working on. If that arrives, I'm sure that it would make it possible to correct these issues and according to ED's statements, many of these are on the to do list.
  21. If you can go below the cloud cover to launch a Maverick, you can also loft LGBs. This delivery profile isn't replicated in DCS and many people don't even know that it exists but it was practiced extensively. Even PW 2s can be employed from down low from a loft (in a tactically limited manner but still), and the 24 was specifically designed to be employed on a terrain masking interdictor with a much more sophisticated autopilot guidance scheme, where the main limitation is not the energy retention capabilities of the weapon but the ability to designate the target at such a range where this can be exploited. This is why self lazing a 24 is a very difficult endevour and really only Strike Eagles were capable of developing a good enough workflow to reliably do this. Vipers flew into the ground when trying the same thing, it's just one of those things that a single seat aircraft can't really utilize effectively and safely. This mission profile was the entire reason why the Block 40 with the LANTIRN and NAVFLIR capable HUD was a thing. There are many things on military platforms that sound good on paper but never really perform at the expected level in real life. A2G radars are kind of steering us off topic, but I don't really disagree with you about the fact that we must consider the platform specific differences. If you ask a Viggen pilot from the 70s or an A-7E pilot from the 80s, even they would likely say that the radar was useful and trained on, even though the absolute capabilities would be exceeded by the 73. But as time went on, more and more capable radars emerged (like the APG-70) and the required resolution, reliability and effectiveness became much higher so the relative capabilities of say the 73 made it that its use became very limited. The APG-70 can target individual stationary tanks and generate accurate coordinates to drop JDAMs on them. The 73 cannot even be utilized to generate coordinates for TOO attacks at all. So if we get down into the weeds, the relative performance difference is staggering, which is why comparatively the 73 can be considered of very limited use. Now the upgraded USMC version are not something I know much about so it's possible that they are much more capable than what the Navy Hornets used. This is true about pretty much everything about the core game except for maybe ATC.
  22. This is a really good point. Currently, the limitations of proper contrast lock, lazing, TLEs and certain IAM errors aren't represented well or at all. Not entirely. I agree with the point about JSOWs or SDBs or other advanced weapons but I'm saying that if we're talking about a theoretical situation where your choices are either D Mavs or GBU-12s, you'd probably be better off with lofting the PW 2s, especially in a two seater. If the weather makes it impossible to laze or to conduct LGB attacks, the notoriously weather sensitive IR MAVs would also be impacted. This is obviously a highly simplified approach, because in real life, this stuff is incredibly complicated, even back in the DS era, let alone today. This quote can reflect to how sensitive all these weapons are to specific conditions and how a non-permissive environment can degrade effectiveness. Sure, the last time these were used in combat were around the start of OIF but that doesn't mean that in this theoretical discussion we should dismiss them. When conditions make it likely that a certain weapon would get employed, even if it's not part of the traditional training cycle, people will bring out the books and start refreshing their memory on them. So they would surely be an option if a conventional war broke out with massive amounts of MBTs. Radars are platform specific. Strike Eagle guys love their radar and it was heavily used even in Desert Storm. Hornet guys said that even the 73 was virtually useless in real conditions for anything else than INS updates and anti shipping, let alone the 65. Some people find this very hard to accept but like always, if there's no hard data, the only thing we can rely on are SME statements.
  23. Offering options for more accessibility and making a module have completely fictional capabilities are two different things. When it comes to peripherials, customization options, various user settings we need to understand that when using commercial, off the shelf products there will always be a level of inaccuracy. The products will have different qualities, materials, limitations and because of that, allowing people to customize their experience can't do any harm whatsoever. The same argument is often brought up against things like user curves, zoom and now this feature, which just doesn't make sense. The very nature of sitting in front of the computer with completely different set of controls, while looking at a screen will make the experience inherently different from real life. Having the option to customize this experience will not make it worse for anyone. Especially since it's all optional, no one is forced to use it.
  24. Taxiing, staying aligned properly on the runway during takeoff.
  25. Rudder pedals and rudder control are two very different things. Pedals are not the only way to control your rudder. You can easily use twist stick, or those handles on the back of the TWCS throttles (or other similar contraptions) when you occasionally need to use rudder during ground ops, crosswind landing or BFM. These uses don't need dedicated pedals at all. A well working twist grip is more than suitable. Rudder pedals shine when you either need to use rudder very often (warbirds or analog jets), or you're required to put in pedals continuously (like helos). And even these are perfectly flyable with twist stick, especially if you use rudder trim in helos, it's just somewhat more uncomfortable. In a Hornet (simulated or real), you only need pedals during ground ops, crosswind landings and BFM, that's it. This is confirmed by GB, who was a real Hornet pilot.
×
×
  • Create New...