Harker

At this point, it doesn't need to be realistic, just functional in DCS. Can be anything, such as specifying a certain F/F 1 code can act as a way to set up your flight callsign and F/F 2 can be the flight number. Example: F/F 1 = 153, 15 = Joker, 3 = Joker 3 flight. F/F 2 = 2. Result, Joker 3-2.

I tested with realistic slew enabled and disabled. No difference. The problem is that, according to the TAC-300 manual, the seeker can be slewed while the designation is still present. Page 93 (98 of the pdf). This is not possible in DCS. In DCS, if we want to slew the seeker manually, we need to undesignate and lose the designation (or not have one in the first place). Having to undesignate in order to regain slew capability is not described anywhere in that document (which has detailed, step-by-step checklists of all the possible ways to employ weapons).

Yes, TWS AUTO can use any combination of azimuth, elevation and elevation bars settings it sees fit (even things like 3B, which are not accessible manually) in order to maintain as many MSI trackfiles as possible. The scan pattern is adjusted based on a set of priorities, with the highest being the L&S, then DT2, then Rank 1, then Rank 2 etc (designating a trackfile does not change its rank, like it currently happens in DCS). And obviously, it's also based around a minimum trackfile update rate. Do keep in mind that MSI trackfiles also include non-radar trackfiles (the L&S can also be a non-radar trackfile), so when initiating TWS AUTO, it will adjust to detect these as well, if applicable. So, if we get a proper implementation of MSI and TWS AUTO, it'll essentially be a system that allows for significantly hands-free operation, because it will adjust the scan pattern by itself, based on both radar, datalink and other MSI data. It'll always try to keep the most important targets within the scan pattern, so you won't have to make azimuth and elevation adjustments yourself. Fingers crossed we actually get it.

And also AUTO should be closer to TWS AUTO in the F-14, where the azimuth and elevation bars are automatically adjusted to maintain as many trackfiles as possible, with the limits prioritizing the L&S, DT2 and then stepping down through the ranks.

Good to hear, thanks for the heads up.

Tested on latest OB, but this has been present since the beginning, I think. Our Hornet correctly transitions from CCIP to AUTO for appropriate weapons, once a designation has been made. However, it is possible to re-select CCIP from the STORES page or choose another bomb that is in CCIP. This will exit AUTO and cause the CCIP solution to co-exist with the designation. This is a bug, if a designation exists, all CCIP weapons should be converted to AUTO, where applicable. Selecting another bomb that had CCIP selected by default, should automatically initiate it in AUTO. FA-18C_CCIP possible with designation.trk If you have the FLIR as the designating sensor and the above bug occurs, the FLIR will be slaved to the CCIP aiming cross, as it does, but it will continue being the designating sensor, so the designation will move with the CCIP aiming cross. This means that you lose whatever you were designating before. FA-18C_CCIP possible with designation_ATFLIR moves designation.trkFA-18C_CCIP possible with designation_ATFLIR moves designation_2.trk The latter is a problem caused by the former, since CCIP shouldn't be possible with a designation, but also the FLIR shouldn't be designating when slaved to the CCIP cross. Solving the first issue will automatically solve the second one as well.

In DCS, you're just designating a track in radar memory after you land, not a non-radar MSI track, so it's not necessarily the same as in the IRL video. MSI is still missing in DCS.

The Hornet does not have TFR capability, merely has a Terrain Avoidance radar mode, that informs the pilot of the terrain ahead. The pilot has to manually fly though.

That and it also takes HAFU type into account. If you have verified bandits (red diamond HAFUs) approaching you, they'll remain in the first ranks, instead of the unknown contact that's speeding away from you. The other problem is that in DCS, trackfiles are built immediately, after a single hit. IRL, it's possible that your radar wouldn't detect the missile in every frame in a way that would allow it to correlate hits and create a trackfile for it that quickly.

I appreciate that you're looking this from a casual perspective, but even like that, the Hornet is not 90% complete. I'd say somewhere around 60% when compared to what would be possible with public data and somewhere around 75% when compared with the top high fidelity modules in DCS (think A-10C level, with all the little details in the MFD pages, the ability to set up a network, send and receive messages etc). Sure, you can do most things in some way and the module is great fun as it is, but it's missing a lot of stuff. Namely, MSI, which is the core of a mid-2000s Hornet, is not implemented and neither is TAMMAC. Other systems are half-way there, but they are missing a lot of functionality and features left and right. Still a great module and one I fly regularly, but far from complete.

you can at least spot the elevators by fully zooming in - the guardrail posts are visible

Not exactly, but there are ways of quickly looking for a contact with the radar. You can make the MSI track the L&S and then enter TWS AUTO: the radar will prioritize the L&S in its search pattern, likely finding it quickly. Or you can attempt an acquisition with FastACQ, using SCS->RDR ATTK page: the radar will enter a mini-raster scan and attempt to acquire the target, transitioning to STT if it does. The thing with MSI, is that an MSI trackfile can be created by several different inputs and the radar is only one of them (the most important one, but still, only one). The radar works with and considers MSI trackfiles, not necessarily only the ones coming from itself. In DCS right now, we just have datalink, but not really MSI.

Consider that when you're on the deck, not moving, your motion is only the carrier's motion. So, your ground track symbol will be pointing down on the BRC.

If you cycle through SCENE -> AUTO and back to INR, then it doesn't drift anymore, sure. But that's not correct behavior, INR should be space stabilized from the beginning, since the pod is commanded to designate (the INR crosshairs are a diamond).

Noticed it as well. Normally, all of these displays are outputs for the same info, so info should be consistent across them. In that case, since the aircraft type is known on the net, it should be visible in all MSI displays in the aircraft.

Yeah, AFAIK, SRS uses the cockpit state to determine the frequencies. The UFC displays, in the case of the Hornet.

BN, follow these steps and you should be able to reproduce the first issue (FLIR walking off target upon TDC Depress after designating with WPDSG): 1. In the ME, place a WP at ground elevation (just so the problem is clearer). 2. Start the mission. Air start is fine, but also happens with cold start. 3. Select that WP, press WPDSG. The FLIR is slaved to the designation, as it should. It is not slewable yet. 4. With TDC Priority to the FLIR page, depress the TDC to drive the designation through the FLIR INR mode. The BUG occurs here, as soon as you depress the TDC and the FLIR can be slewed, it wanders off target. It shouldn't.

No idea where the burn through distance came from. As for the jammer blinding your own radar, IRL, radars and jammers operate in discrete frequency channels (each channel is a collection of different frequencies), not all over their frequency spectrum. In most cases, the jammer can be set to operate outside the channels the radar is currently using (Radar priority) or the radar can be set to operate outside the the channels the jammer is using (Jammer priority). Prioritizing one system might compromise the other. Take the following, extremely simplified scenario: You're tracking a target, with channel 5 (C5) selected and you are in Jammer priority. Your and your target's radars and jammers are different and may not use the same channel definitions. They start tracking you on a frequency that falls inside your C5. Thus, your Jammer goes online on C5 and your Radar is either blanked or forced into another channel, say C6. It tries to re-acquire the target with the frequencies in C6, but maybe your target's Jammer covers those, so your radar tries with C7 and manages to re-acquire the target, if their Jammer can't keep up or if your radar is able to use a range of frequencies they can't jam. The opposite of that is that you're in Radar priority, on C5 and your target also tracks you with frequencies that fall within C5. Your jammer is not allowed to operate on C5, because of Radar priority, so it has little to no effect on your target's radar.

Good summary there. There was another long bug thread about this. I would say that there two issues that lead to the current behavior. 1. The ranking works wrong. When you have verified Hostile contacts heading towards you, they should always be ranked higher than the Unknown contact that's speeding away from you. This should also be true if you have incoming Ambiguous or Unknown contacts, but to a lesser extent. 2. The F-18 builds trackfiles from a single hit. Here, this causes the missile to become a trackfile immediately. Normally, it should require at least two hits that can be correlated to each other, which might prevent a just launched missile from becoming a trackfile. While I have no info for this, I wouldn't be surprised if the radar was programmed to suppress the output of a fast, outgoing contact, for a number of seconds after a missile launch. As for the missile flyout symbol, this is just a visual representation of the ACT and TTG timers, nothing more. The radar does not correlate to with the actual missile, even if it can detect it. 3. Finally, this can also lead to the situation where your STT lock switches to your missile, if you have 1LOOK RAID enabled, but this is also related to the lack of range and velocity gate modeling.

Yes, it should provide lead computation for AUTO drops. So should the ATFLIR in AUTO track, with the MVTGT option selected. We're missing both of these in game.

IIRC that's the process for A/G radar scan centering, which we also don't have in the game.

Yeah, I meant in the context of DCS, since they are two different units in-game.

The S-3 looks great. I really hope that the rework extends to the tanker variant as well.

This was due to the last update in DCS, ED changed the brightness of certain viewports. Nothing changed in the files related to the mod, I check after every update. The only solution I could offer is that I could upload a darker gray texture for the picture, but then the FLIR and A/G radar will be too dark, requiring display adjustments all the time. For now, your best course of action is to adjust the picture using the brightness and contrast knobs, when you are in CCD mode.

Indeed, good addition. The L&S doesn't need to be created from the radar, any MSI input will do (radar, FLIR, Link 16 etc).