WobblyFlops

But the current way it's 'modelled' for AI points towards a bug since it can trigger even if there's no way to be hit by any sidelobes. I'm all for implementing inaccuracies like physical blanking of the RWR antennas, actual sidelobe detection (with simulated sidelobes from the radars themselves), mippling, worse azimuth resolution and so on. These are documented effects and it would greatly enhance the fidelity of the RWR simulation to not have them be essentially perfect sensors on par with a radar tactically in many situations. But unfortunately the way it behaves currently when it comes to these erroneous spikes makes it clear that we're dealing with a bug.

Oh boy, you've stirred up the Hornet's nest. While ED accepts that this is a bug (since it's a netcode bug it is likely going to take a very long time until it's fixed) a lot of people very often argue that this is 'realistic' because the RWR would pick up the sidelobes from the radar. In terms of DCS, this is 100% an unintended bug since side lobes aren't even simulated, especially not for AI and when talking about realistic behaviour, we'd have to specifically address this on a case by case basis utilizing open source information about a specific RWR system.

The current in game version, which I was talking about is not exactly a specific suite that's being modelled but regardless it represents the mid 2010s timeframe, so the COMM page would 100% apply to it. And it will not get implemented, just like the missing TGP symbology, HMCS symbology and datalink capabilities. It will only have the new radio and some additional TAD symbology, which by the way was also heavily pruned even in the Suite 3 era back in the day. So the A-10CII will leave EA without the COMM page and I made the comparsion to what if the Apache were to also leave EA without the COM page. The conflict in this situation is not between the forums users and SMEs but between ED and all the forum users, which include SMEs. This isn't that simple. SMEs on this forum can be under much higher scrutiny in practice than regular users, so if you have access to ITAR restricted but otherwise unclassified material, every piece of information that references that material is not allowed to be discussed on the forum, if ED decide to enforce it. So SMEs will be extremely limited as to what they can talk about when things that they say get uncomfortable for ED, like it was the case for the A-10 with things like the amount of hydraulic pressure generated by windmilling engines, or the actual temperatures during an engine startup. There's probably some kind of miscommunication here or I don't know. What will likely happen, based on the previous ED modules is that certain things will be outright missing from the module once it releases and it will stay that way forever. People will argue that they should implement certain features (like the MSI for the Hornet), SMEs will confirm that to be the case (if it's not sensitive) and yet nothing will change whatsoever. Once the module will have been out for 2 years and we'll see the missing or simplified systems or functionality, if the SMEs actually want an accurate rendition, they will be on the same page as everyone else. This is how it's always been historically, ever since the days of the original A-10C.

I'm not looking for any information, not sure what you're even referring to. And that's exactly the point, historically the vast majority of discussions about other modules heavily touch on sensitive areas that SMEs can't talk about. Those areas are still replicated in the sim, and we have to use deduction, every piece of open source information that we can scrounge up and a make some cohesive argument from that. Is it actually true to real life? Probably not, but the entire goal is to make the capabilities and systems as close as possible and push ED to do so. DCS is first and foremost a switchology, cockpit simulator. What it can do is to replicate (even without actually simulating underlying components) behaviour that you could see if you press a button or open a page on the MFD. But the ED manual only tells you what it's supposed to do in the game, not how it's supposed to be in real life. So it's completely useless to see what systems or functions are unimplemented. This is the inherent limitation of this entire hobby. Of course I'd love if there were every piece of testing data, operational report, any sort of technical manual and all that you can think of available about every module in the public realm but this is not the actual situation. We are limited by the availability of the data. But that doesn't mean that we can just give up and let perfect be the enemy of good enough. But to illustrate my point further, let's use the Hornet as an example. It doesn't have a slew map function to this day but its usage is clearly described in the NATOPS and there's even a slew button on the DDI. We know from Wags' video that the Apache will come with a slew function. Let's say as a hypothetical scenario that the Apache (like the Hornet) were to also come without the ability to slew the map and it would stay like that for 3 years. Do you think that because you don't have all the data about the aircraft, you can't make a wishlist item about the map slew, referencing the TM? Another example, the A-10 still doesn't have the COMM page implemented. What if the Apache were to leave EA without the COM page? Or let's examine a topic where SMEs wouldn't be able to help, the F-15's radar. It had the same radar range as the Flanker, even though we have open source experimental data that shows that the real performance is much better. An actual F-15 pilot would likely still not talk about radar performance regardless, so people had to scour the internet and find that data, which may not tell the full picture but it's good enough for ED to adjust it one day. And don't get me wrong, I'm grateful to have SMEs. However, I'm still very sceptical about the result because when other modules also had SME input it was still very often ignored or postponed to be implemented when development resources allow during 'product sustainment' after a 3-4 year old EA cycle.

That's fair but once you get to topics that SMEs can't or won't talk about, all you'll have is public documentation. Not to mention that having multiple SMEs active on the forums is pretty rare. The vast majority of other modules may have some (or none at all) but they usually don't answer many questions, so usually all we could utilize was publically available stuff.

If there's empirical evidence for a certain feature existing in the real life aircraft and it's not implemented, discussion can be had as to why that particular feature isn't implemented in the game. The data may not apply to the specific era that's modelled by ED, the community may misunderstand the feature or it's something it 'should do' but ED for whatever reason haven't implemented it (yet). Discussion is important to validate the veracity of the information through peer review (which includes helpful and informative SMEs) and allow ED to address if that particular feature should be in the game and whether or not it will eventually end up getting implemented. What's wrong with it? Or are you against using real life documentation to fact check the in game products? The last time someone used the TM to ask about certain features of the Apache your reaction was very negative. I may understand if it's due to OPSEC or legal concerns but if the documentation or data is available through legal open source means, I see no issue to discuss. Illegally obtain documents can't be referenced on the forum anyway.

This applies to ED modules though. Back in the old days of BS2, the Shark had INS drift but IIRC after several core updates changed how the maps and the coordinates work in the engine, these functions were never re-added. Other modules like the Viggen, the JF-17, the Mirage and the Tomcat not only have navigation drift but have simulated fixes and updates as well.

There are always ways to see what we want to see, but in my opinion it's better if we don't expect an ED F-4E and be pleasantly surprised if we end up getting it instead of some Naval variant.

I don't think so, they never explicitly denied that the secret module would be the Apache. They denied some things (heavy, redfor jet, F-4) that were clearly not the 'facemelter' and Nineline always skirted around the Apache issue. Later he mentioned that it was very difficult to not talk about the Apache in any way and he couldn't even use Apache gifs on the Discord to avoid people realizing that it will be the secret module. People just suspected it wouldn't be an Apache because they said it would be something completely new and the Apache had been in development before, although that was a 90s era A model. Okay, if we want to disregard this interview what about BN's comments on the Discord? https://cdn.discordapp.com/attachments/543014378643914752/926055209543811092/Screenshot_2021-12-30-11-12-25-81_572064f74bd5f9fa804b05334aa4f912.jpg

I'm honestly unsure what makes you think ED are the one making the Phantom. Why would they be lying on purpose? Why wouldn't they just avoid the question?

None of the new modules made by the former BST team (like the Hind) have any level of formal distinction from other ED products. In fact this type of formal distinction is unprecedented since the official merger and from that point on, there's absolutely no ambiguity regarding the status of the formal BST team. Everything points towards them being an integral part of ED as one of the many internal groups. Both BN, Nineline and Kate confirmed very clearly that ED have no plans on making an F-4. BN also confirmed that BST is considered to be a part of ED and the companies are merged into one and ED does not plan on making an F-4. This post was in November, so if things have changed since then, that F-4 is long, long ways away.

Ed Macy's book is highly exaggerated and full of hyperbole. It's a fun read but don't believe anything he says about the technical aspects of the aircraft without verifying with a reputable SME or with the TM.

Only the F-18 has some kind of INS drift simulation out of the ED modules but that's also very, very far from being realistic. The A-10 doesn't simulate these procedures.

JDAMs for sure have INS only guidance as well, which would work in a GPS denied environment but the CEP would be much higher. This isn't simulated in DCS. The TGP should have an Inertial Sensor Unit, which would allow it to calculate seeker position relative to the aircraft's position. I can't say for sure whether a working INS would be required for this or not but if the INS is working, the stabilization should work for sure. Moreover, the TGP has some kind of 'pixel magic' to compensate and retain a stable track when it's ground stabilized. Obviously the apparent limitation when it comes to these ops is INS drift. If the position drifts, not only will you have issues like waypoints not being where they should be, but since the jet can use DTED for A2G ranging, if the position information is inaccurate, that could in theory invalidate the CCIP solution, since it's calculating the range based on incorrect positional data. This isn't simulated in DCS, the INS doesn't drift and the update functions don't actually do anything.

Currently there is no MOVLAS or proper LSO comms that would address a pitching/rolling deck, paddles would have to inform you of the movement of the deck which would also implicate the validity of the ball, which may not even be accurate due to the movement. This is the basis of pitching deck ops and isn't modelled at all. Same goes for MOVLAS, which also isn't modelled. If the Supercarrier isn't indended to replicate realistic operations in a bad sea state, 'stabilization' isn't going to be relevant because if you're lined up and you're on speed, the glideslope information will be valid. If the deck is moving up and down, it's not the case, which is why you'd need an LSO to dynamically read the movement of the deck and give correct verbal or visual signs that allow you to compensate. It's clearly a balancing act. They say these things to avoid alienatin the hardcore simmers yet still don't fix these issues to avoid alienating the casual audience. Roughly around the linked time stamp the developer clearly says that even if they had access to open source data about ECM, it would still be questionable to implement the functionality because only highly intelligent and well educated users would be able to utilize it and it would upset the playing field too much. But the level of intended realism is kind of an off topic discussion here, so I'll leave it at that.

The more accurate and realistic the deck state behaviour becomes, the more important and difficult it will be to model the accurate stabilization. Plus, in truly bad sea states, the MOVLAS with accurate LSO calls are going to be the main way to get the aircraft back to the boat and I don't think it would be trivial to code all of this, especially to ensure that all the interconnected systems work together seamlessly. That's a marketing statement, if you actually examine the game, you'll see this sentiment very often, even from developers and of course from the vast majority of the playerbase. It's probably not something that would make it 100% impossible to implement realistic pitching deck but it's yet another factor why ED most likely thinks that dedicating resources for a task like this wouldn't be a good idea.

The issue with the pitching deck that it not only has to be realistic regarding the physics of the boat and the sea state and their interaction with the (very WIP) weather system, but they'd have to simulate things like the MOVLAS, an intelligent AI LSO giving you calls regarding the deck state, the effects of the deck state on AI and the fact that the ACLS would have to compensate for the oscillations and give you accurate information. If we take all these highly complex and intertwined interactions and add them to a feature that only hardcore, experienced people would even appreciate (especially considering that the vast majority of servers where most people play very rarely if ever use anything other than CAVOK weather), and in fact it would just alienate the ever growing casual audience, I'd bet that ED probably don't think that such a feature justifies the vast amount of resources that's required to have a proper implementation.

I still think this guy is making fun of people posting their wishlist items with stuff like this.

Simply put: AA TACAN in fighters: range only. Tankers: Range and azimuth, because tankers have a partial array in the aft compartment to help jets line up better in bad visibility. Obviously fighters don't have the space to carry such a contraption. This is a bug and it impacts the Viper as well.

What's your evidence that this is some kind of interaction that's specifically modelled as opposed to being a bug? As for DCS sensors being simplified and not modeling complex limitations, yes, congratulations more news at eleven. There's a difference between not modelling nuanced interactions or real life imperfections correctly and having an egregious bug like this.

There is and it's tagged with '2022' on their Trello. Whether that means it's slated for a 2022 release or a 2022 announcment is not known at this point.

A simple, to the point answer: The missile 'datalink' is kind of a misleading name, the -120C doesn't have the capabilities of the -120D that can be guided by other aircraft for example. The way it works is that the actual radar wave on the launch aircraft has encoded commands for the missile itself, a computer on board the missile interprets these commands and updates the steering. The datalink in DCS aircraft (Link-16, SALD, etc.) have nothing to do with the Amraam. The INS ensures that the missile even without steering commands from the radar tries to guide itself to a computed point of likely intercept with the target.

The F-4 was confirmed by Kate in an interview but nonetheless, this teasing may indicate that the release isn't that far away. Mudhen 2024 and F-4 2023 is a reasonable estimate I'd say.

I don't think they'd mean a core engine 'rework' necessarily but rather an additional core function. Wags specifically said that IAM terminal settings require tasks to be completed outside of the Hornet, from this we can infer that he means new core functions. Maybe the JSOW itself flat out doesn't support these and they need to add this functionality to the weapon itself first before it can be applied to specific modules. Or maybe they simply don't want to add this and it's simply an excuse, I can't know for certain.

Well, the A-10's CDU definitely has a lot of pages, the vast majority of the nitty-gritty advanced functions are either not modelled in the game (so you can change them but don't do anything) or they are hardcoded, stactic texts which only exist for immersion purposes. A comparably complex system would be a fully simulated TAD, however for the A-10 the majority of the functons for that are missing. If we had a fully simulated TAD, I'd agree but even if you compare the navigation system, the A-10 in DCS simply doesn't have nearly as many different point types that all represent something different, and for the Apache, it looks like they have the ability to simulate a lot more things than for the A-10 (or any other jet.) Tons and tons of point types, different map types and symbology and so on. I'd wager that the COMM suite will be just as complete while in the A-10 an entire MFCD page that is used to control the radios, transponders and VMF messages is flat out not implemented at all.