Harker

Agree with everything. This is general problem with how light sources are handled in DCS. Various modules have the fake bloom effect present in different quantities, but for some modules such as the Hornet and the SC, it's overused to a ridiculous degree. They'd be better off removing the fake bloom completely and instead making the light source brighter and only using real, direction-based bloom, which is already present in DCS. There is no need for these fake halo effects.

In VR with a G2 (PD 1.0, SteamSS 100%), no. I can make it out at this distance, but not easily. It's impossible to clearly discern it at 0.75 NM. It's also difficult to discern in 2D, because of the excessive bloom effect, but it's not nearly as bad as in VR.

What about HOJ? HOJ is there as a fallback, when you cannot resolve range and the missile just does a beeline for the jammer. It's purely based on LOS and maybe angular rates. And if you do have resolved range (and velocity), then you don't fire a HOJ shot, you fire a normal one. I'm saying that if the radar - missile data transfer is simulated correctly, then if the radar can resolve the range and velocity and thus display it to the pilot, it can also provide the same data to the missile. If, in DCS, you are seeing target range and velocity on your radar screen, but then your AMRAAM behaves like it's a HOJ shot, then the radar - missile data transfer process is not simulated in DCS and your AMRAAM is going HOJ for artificial reasons. It's easy enough to test, just hop in an F-16, target a contact with the option "ECM: TURN ON WHEN LOCKED" in TWS, look at the firing solution and missile trajectory (fire from far away to ensure lofting) and then repeat the test, but fire from STT this time. In the F-16, your radar will display range and velocity information in both tests and thus the missile trajectory should be the same, in both tests, everything else being equal. NB: The target will turn on their jammer when the AMRAAM goes pitbull, in the TWS, but that's not a problem, as you can observe the loft trajectory way before that happens.

2. should be possible, but in limited cases only, where the target continues moving with the same speed, heading etc. I don't know if this is applies to the ATFLIR specifically, but it's entirely possible for the pod software to extrapolate the target's path. If 2. occurs for a "maneuvering" target, then of course it's wrong. I'm also concerned about the fact that pod LOS is not accurately simulated, since the pod will enter INR SCENE and INR AUTO only if it reaches the MASK limits, but not when a wing or a store blocks the LOS to the target. Right now, it'll track, and even lase, perfectly fine, through a wing. It's also weird to me that the wings are not part of the MASK zone, considering that the ATFLIR can only be mounted on one position on the Hornet. Seems that only the fuselage is actually causing a masking condition.

No worries, everyone needs some help with modding in the beginning. The flir_texture.dds file is a texture file that determines what color the video feed is going to be, on the displays. By default, DCS already has this file and it is a green texture. In my mod, I simply have a gray texture. So, if you replace the original file with mine, you will get the gray Maverick, AG radar etc video color. If you wish to keep the green color for the Maverick video, AG radar etc, then you must not replace the original file with mine. (In fact, you can delete the entire folder that contains it, since it is not useful anymore: Before you apply my mod, go in my mod files, in \FA-18C LCD MDIs\Mods\aircraft\FA-18C\Cockpit\ and delete the file called "IndicationResources". Then, proceed with the rest of the instructions. That way, the original file is used and you still have my mod, with Option 2: LCD displays, off-white font, white Maverick crosshairs, but green Maverick, AG radar etc video. If you need any more help, don't hesitate to ask or PM me, I honestly don't mind.

Option 2 simply requires you to *not* use one of my custom files, so you should delete it from my mod, before you apply it. Don't delete the original flir_texture.dds file in the game directory.

True, navigating and attacking ground targets effectively without GPS is not really possible, considering the rate and weird implementation of drift and the inability to use some update options. I did find that DSG worked though. However, the INS/GPS simulation is still marked WIP in the Roadmap, so they'll likely flesh out the system more.

The TPOD is irrelevant, what matters is that you have a ground designation (diamond). Currently, we are unable to slew the Maverick seeker with a ground designation present. The TAC Pocket Guide describes two different ways of employing the Maverick with a designated A/G target - one of them seems to allow slewing of the seeker with a ground designation present, but we don't have it in DCS.

It seems this is what is happening. The radar does not retain memory of the STT target, but of course it should. Although this is not directly related, another thing currently compounding this behavior in DCS is the fact that STT causes MSI processing to stop in DCS, whereas it shouldn't (it should only stop in ACM and when in A/G mode). So, while the radar shouldn't need MSI, since it should employ gates, retaining the correct target becomes even easier, since all the radar has to do is focus on a particular MSI trackfile. This should become better once MSI is sorted out and we get actual MSI trackfiles, correct MSI sensor contribution logic and we can differentiate between radar and non-radar MSI trackfiles.

Regarding this thread: I would like to point out that the radar should not be jumping between contacts uncommanded, since it should employ target range, Doppler, heading etc filters, in order to maintain the intended contact. A switch like that should only be possible to occur (if it occurs at all) if both are in the same resolution cell (not modeled in DCS, AFAIK) and have extremely common characteristics when the switch occurs. The radar could be confused, merge them into one contact and then pick the wrong target when they break apart (i.e. being far away, smaller RCS targets flying in very close formation, initially being picked up as a single contact, with larger RCS). As such, an outgoing missile would never be confused with a fighter, for example and even if it entered the STT beam, it would be rejected immediately by the radar. Apologies for referencing another bug post, but it was locked before I could comment. I'm just putting this out there so that, when devs go to fix this issue, they are aware of the intended final behavior, so they wouldn't need to possibly revisit this in the future. @BIGNEWY, feel free to merge the two threads. This isn't new information BTW, @GGTharos has already spoken about this in several threads, in good detail. I just wanted to put it out there. Thanks.

OP isn't saying he doesn't have the patience required to learn a module, he's saying that he doesn't have the patience to deal with all the technical issues that they encountered. These are two very different things. And that's after reportedly spending 8 hours trying to get the game to work. It's perfectly reasonable to expect a game to work, regardless of how complicated it is. OP, DCS certainly has its quirks and challenges, but once you dial things in, you can enjoy an experience you'd be hard pressed to find anywhere else. If you're willing to give DCS another try, my advice to you is to start in 2D, get a feel for the game, fly the aircraft a bit and you can retry with VR a little later. I'll say it now, the VR performance in DCS isn't good and that's coming from someone with a 3090, who spent the better part of a month trying to optimize his VR experience. Don't expect both amazing visuals and performance at the moment (an engine transition to Vulkan is underway, but we currently don't have either a concrete ETA or an estimated performance improvement). But you, like a lot of others, can probably find a happy medium between the two or go for 2D and headtracking (if you don't have, there are several solutions of varying costs). If you have issues not related to game performance, be specific and I can guarantee that you'll find people willing to help. DCS has a steep learning curve, both from a software and a gameplay perspective, but the community does a good job of helping newcomers, as long as they're willing to put in the effort.

You can already do that. It's under Advanced Waypoint Actions -> Perform Task -> Aerobatics. You can add maneuvers with the + button and then you can select them in order to customize them (how many repetitions, optional use of smoke, initial altitude and speed etc - the options are specific to each maneuver).

Considering we're not getting any of the cues, it's not implemented.

Oh, if that's the case, then it's not your fault. It could also mean that 0 is equivalent to undefined and the missile doesn't care about terminal speed. If you entered a terminal azimuth only and it didn't work, then it's a bug. If you can replicate it, please create a short track showing the issue and post it in the Bugs section.

Sorry, I meant to answer the poster above me, regarding the implementation of the dynamic IZLAR. In your case for 1), I think that the system rejected your input because you set the terminal speed to 0. The missile cannot possibly achieve that. I think in a situation like that, the system should inform you that this is an invalid entry by double flashing the UFC, but I don't have the relevant manual.

Not modeled yet, TERM HDG change does not affect the IZLAR on the HSI. For that reason, I'd avoid using TERM HDG, unless you absolutely have to (or are launching along the heading). You could launch outside valid parameters and not know about it, although this is less of an issue with the SLAM-ER.

Thanks for the update, BN.

That can't be right then. There's no way the APG-73 wound lose a target with Vc of nearly 1000 kts at 10k ft...

Sure, the initial statement was for OFP 13C, what we have seems to be 15C and up, with features and weapons from much higher OFPs.

I'm trying to bring the Hornet's TDC up to realistic speeds, because it's way slower than IRL, at the moment. Does anyone know where could I start looking for a file that controls the max slew speed? For now, I've found files that control slew speed for missile seekers (Maverick etc) in \Mods\aircraft\FA-18C\Cockpit\Scripts\Computers\SMS\, but I've found nothing for the designation cursor (yellow cursor) yet. Thanks in advance!

@BIGNEWYLook down detection should not be an issue for the APG-73, unless the target is flying in the weeds and mixed with the ground clutter. And even like that, it shouldn't be impossible to detect, just have a decreased detection range. The detection performance shouldn't decrease if we're talking about a target at 15,000 ft, while I'm at 25,000 ft. It's a Doppler radar, it should be able to pick up a contact like that, because the Doppler return from the target and the return from the ground are completely different. Same should go for missile seekers, BTW. If you want to confuse a radar like that, you need to be in the weeds and mixed with the ground clutter, not just be below them. Especially for missiles, consider that they often come down at targets from above, due to lofting.

You can select RSET with the TDC and depress, just like you'd do with a PC mouse. So it can be done through the HOTAS. Plus, in the real Hornet, the TDC can be slewed much faster and thus it's easy to click things around. Sure, it might be faster to have a dedicated HOTAS control for it, but if you're in a situation where you don't need any contact designated, you have plenty of time to slew and click RSET.

Thanks! Yeah, thinking about it, this makes sense, there is no way to differentiate, so you'd get warnings all the time just by being scanned by friendlies. Plus, both the RWR and the pilot can only process so much information at the same time. And if you can't reply, meaning that most likely, you're scanned by a non-friendly, you'd know.

+1. The JF-17 already has this implemented, among with the anti-ice system. It'd be nice to have it on all modules.

You can follow the link on the first comment of this thread. And thank you for using my mod!