Harker

I believe this is the report you're talking about: /topic/242391-investigating-baro-altitude-value-for-calculations-not-taken-from-cockpit-altimeter/

I'm going to hazard a guess and say that the HUD cue is indeed the JAM/XJAM cue mentioned in 742. AFAIK, X depends on the type of jamming. Here, VJAM could indicate velocity jamming associated with the L&S, although I'm just guessing.

I'm thinking that the HARM Pullback in A/A got stuck to the first emitter it saw when it came online (so, the emitter of one of the CBG's ships)? Which got fixed when you entered A/G mode and it started actually categorizing threats again. Just a thought. Of course, it should run in the background and continuously categorize and evaluate threats, regardless of the mode (or the status of the HRM OVRD option). If it doesn't, then it's a bug. It'd also be good to be able to see your HUD or EW page, to see the boxed emitter symbol for both Pullback launches.

Most certainly is. You can start with the A1-F18AC-742-100 and the A1-F18AC-FRM-000. They contain a wealth of information, as well as figures, for the radar (both A/A and A/G), MSI, FLIR, AZ/EL and SA, among other things. They're both publicly and legitimately available online and can be found with a quick google search. Their close study is a natural first step in the process of trying to understand or simulate a Hornet operating in the 2000s.

Documentation is available though and a literature study is a standard first step in projects like these. You don't just start developing. At least this should be the case. As for the Hornet's budget, we of course can't know where it's at, but if ED burned through it already, then standard practice for an already-sold product is to still finish it, take the loss and consider the whole thing as a learning experience.

The RWS mode display was more correct, with trackfiles displaying correctly, but that was still not MSI (as you already state). Just radar+datalink correlation. I also have a hard time accepting that everything related to MSI would be off limits. There's another commercially available (Super) Hornet sim that features several avionics functions that are absent from our Hornet.

Such decisions and limitations should be known before development work starts. If they knew they couldn't model stuff as fundamental as MSI and trackfiles, then they shouldn't advertise it as a mid-2000s Hornet, simple as that. MSI right now doesn't exist at all in the DCS Hornet. Radar symbology is missing. Radar trackfile memory is wrong and that has nothing to do with MSI (you have radar memory and MSI memory, two different things). TWS AUTO is wrong. These are fundamental elements of the Hornet's A/A suite, not details. Without them, we might as well have a 90s Hornet with IAMs, JHMCS and SLAM-ER. And even then, the stuff specific to the radar would still be wrong. I can't fathom that they'd actually leave the A/A suite in such a state and call the Hornet "complete". Unless ED says so, I can only hope that they'll deal with them at some point. I'd indeed be nice to have an update on that, although it doesn't seem like anyone's working on anything new for the Hornet for some time now.

Indeed, in PB, the seeker should look for an emitter within 10 NM of the designated point, IIRC.

I mean, it's already available to select as an A/G radar mode, it just cannot be selected. It's already been implemented in other DCS modules, there's no good reason why the Hornet shouldn't get it. Indeed, a word from ED would be nice.

And HAFUs should be displayed for trackfiles that have both radar and another MSI contribution, with LTWS boxed, which is not the case right now. It's mentioned above, but just to emphasize, with LTWS boxed, the radar will display only raw hits for radar-only trackfiles, unless the TDC is on them or they're under AMRAAM attack. HAFUs are always displayed for trackfiles with radar+MSI trackfiles (and if MSI is boxed, non-radar MSI trackfiles). With LTWS unboxed, HAFUs are displayed also for radar-only MSI trackfiles (just the top HAFU part, with the radar contribution circle). In both cases, the LTWS option is merely a display option. TWS processing and trackfile creation still happens and the pilot-radar interaction remains the same. Placing the TDC over a trackfile should always reveal its MSI info and you should always be able to designate it as L&S without going to STT.

I never said that the AMPCD in Legacy Hornets was unable of doing the same, I don't know if it did IRL. I said that the font color in those Rhino videos is probably pilot selectable and not fixed to one color, as is the case for the DCS Harrier. It could be a software feature that was introduced later than 2003 or different LCD panels using the same button interface. I don't know enough to say.

I also tried with moving ground and sea targets, the radar doesn't transition to FTT with TMS up, it always goes to Freeze and marks the coordinates of that spot.

The budget for core API development should be separate from individual project (module) budget, since it is not specific to one project (module). And literature review is an essential first step of any such project and has its own budgeted hours, same as everything else. If what you said turned out to be true, then it would point to very bad practices, both from the upper management (project planning, hour planning) and the development/team leading sides (bad literature review and implementing stuff without consulting manuals). At least some of this is probably the case and if it it is, then the company will have to take the hit and still deliver the product they charged for. That's fine, managers can make mistake and employees aren't perfect all the time, it's human. The motivation to be the perfect employee is not always at 100% and that's just part of reality, no matter the industry. I'm more interested to see how they handle that though, because if they don't take the hit and deliver anyway, then it gives me no indication that it won't be repeated. Furthermore, if they cannot flesh out the systems of a Legacy Hornet, then I doubt they can do so for a Rhino. But again, if they deliver on the Hornet and then announce a Rhino (or an upgrade to the Hornet), I'll be the first to buy it.

Yeah, I'm not hung up on the C+ specifically, call it a late 2010s C, an A++, a CF-18, F/A-18 F or whatever. If it's going to be an upgrade from ED to the current Lot 20 Charlie Hornet, similar to the A-10C II, they should first properly finish the current Hornet first. But this is of course not important if another dev picks it up a Rhino.

Just fly it to the deck, all the way down, maintaining AOA. The landing "should come as a surprise" and the deceleration due to catching a wire as another surprise after that.

Let's see if ED can finish the current Lot 20 Hornet first. If they do a good job delivering that, I'd definitely pay for an upgrade, whether we're talking about a C+ or just a mid-to-late 2010s avionics upgrade, like in the A-10C 2. As it is, I'm not paying for an upgrade to a half-finished module. I would also be more than happy to pay full price for a Rhino module from ED, provided they finish the Hornet first (as a proof of concept) or from another developer (obviously the Hornet's status wouldn't matter, if it's another dev).

IIRC, it was fixed some months ago and then reverted back to the current state in the next patch, probably because of different code versions merging. I don't know why, it's literally a number change in a LUA file that controls the position of the ownship symbol. Since then, MIDS symbols (PPLI and trackfiles) in the SA page have been given a downwards offset to account for the wrong position of the ownship symbol, whereas they were previously placed correctly for the correct position of ownship. Finally, there's a bug with the TDC where info is only displayed when you hover over the top half part of the MIDS symbols and over the empty space above it.

This looks nice, but the upper HAFU part is always from onboard sensors. The lower HAFU part is always from offboard contributions. The HAFU halves themselves don't have upper/lower colors, the color of the entire HAFU depends on the ROE matrix (in DCS, two separate non-friendly confirmations or set to Hostile via PLID).

Can't say for sure, but I think it's just a color option. In DCS, you can choose your display font color in the Harrier through the EHSD page, as it carries modern MPCDs.

Most definitely. If your radar knows where the target is, so does your missile, considering that it receives instructions to head to a specific intercept point, from your radar.

These missiles have 1-way datalink, they continuously receive target info from the guiding aircraft. If your radar can resolve the target's range, altitude and velocity, the missile should act normally. At most, in DCS, it should go HOJ when it goes active, if it can't resolve the target itself, but this would also be wrong compared to IRL, since it should keep using info provided by the guiding platform and rely on its own sleeker only for terminal guidance.

I'd definitely go for an E or an F. If it's an early block, then one of the main differences would be the ARL-67(V)3 RWR, which would be nice to have. I wouldn't really go for a D, as it's the same as the C, with less gas.

Without having read the entire thread, I just want to say that, indeed, the AIM-120 does get spoofed way too easily at the moment, based on discussions in several threads in the general DCS Bugs section. I've written before, on the subject of the relative performance of the 54 vs the 120 and I do maintain that the 120C5 should have better ECCM, chaff and clutter rejection etc, but in this case, I agree with you. ED should fix the behavior of the 120, make it behave like a modern missile and then this topic can be revisited. No point in making the 54 worse than the current 120, only to reverse the change later.

People can easily find out how it's supposed to work, they just can't post it here for obvious reasons.

The initial implementation was wrong, it works better now. When entering DBS1 and DBS2, the azimuth setting doesn't matter, since the radar is focused on a much smaller area and spends extra computational time in order to create the displayed picture from DBS processing. DBS should be slow for the radar we have.