Harker

The Hornet is only missing VS for its AA radar, which is rarely used and I doubt we'll ever see it in DCS anyway. HPRF in RWS/TWS should also be a bit better than what it is right now, though, according to pilot feedback, so make what you will of that. As for the 68(V)5, every open source I've found places its max detection range for a 5.0 m2 RCS target, at around 32-35 NM and that includes data I've found on the V9 (80-85 km max) and scaled down (because the V9 is advertised everywhere as offering a ~30-33% range increase over the V5). Also, I'm thinking guessing that VRS for the Viper will suffer the same fate as VS for the Hornet.

Yeah, I wasn't debating that. I was just stating that the AZ/EL doesn't show you what the radar beam is doing at all times, just what the full pattern is. And in most cases, the pattern is rectangular.

It shows the scan pattern, not the radar beam itself. The scan pattern is always a rectangle, with the exception of BST, IIRC.

That. And IMO, the Hornet's nav lights still look bad, both from up close and from a distance. The solution is to increase draw distance of light sources (including AB effect), add correct, intensity and angle based bloom and completely do away with using textures in place of bloom.

It is. People aren't forced to play on that server. And since it's a private server, the owner should be able to choose what aids etc they want available on it. Also, how does doing mental math equate with tolerating G forces, in a video game? DCS simulates navigation systems and the mental math is one of the things we can actually do, from our desk chairs. This is like saying that certain milsim fps games should have bullet drop assists, map and compass assists etc.

Oh no, why'd you guys have to remind me about the RWR? No INS integration, wrong threat ring logic (only locking targets are promoted to the lethal band) and the filters aren't implemented...

I appreciate the link to my mod, but I'd wait a bit before getting it. I haven't updated for the last OB version yet. Coming soon [emoji6]

In my experience, yes. Haven't tested that extensively though..

If it causes crashes, you should post it also in the Crashes section, it'll likely be addressed faster that way.

I'd argue that it'd be even better if ED worked on developing a basic, physics-based radar API that takes basic inputs like diameter, power, PRF, mode etc and allows for certain coefficients and automatically determines the probability of detection at range x like that. Then, module developers need only to include the specifications of the radar, add the correct modes and use the coefficients to achieve published results in certain modes (I'm including coefficients to deal with things like the APG-68(V)5's MPRF, which is not the same as the APG-73's MPRF, for example). That would eliminate much of the speculation and any changes made to the radar physics API would affect DCS as a whole. Everything would be on the same level.

Yeah, the RCS tables in general need to be addressed. They could easily be approximated with a 2 variable function for say, 5 degree (or lower, so we don't see jumps) increments in aspect and a simple delta function coefficient for stores. Even something small like that, which would be computationally inexpensive and easy to plug into the existing radar API, would greatly increase fidelity.

Yep, that's the main issue at this point.

Just checked, works for me, as long as I don't have a page that can accept the TDC, on the LDDI. Did the EW page shortcut ever work? I didn't know it was in.

FM stands for Flight Model

It's only available in A/A mode, lower left on the TAC menu. You can also bring it up quickly on the left DDI, by bumping SCS Left, if there isn't a page that can accept TDC priority on the left DDI already (always in A/A mode).

The radar modes and functionality would be the same, with just details between modes being different. ECM and ECCM would still be there and there wouldn't be any difference, in terms of how DCS deals with them. There only thing that would change in the A/A systems would be MSI, AMRAAM and AIM-9X. The latter is trivial in the context of how DCS is modeling weapons. The AMRAAM is not tied to the Hornet's development, it's only the interface and the radar-missile communication that needs to be developed, I can't imagine it's that time consuming. The big item is MSI, but even like that, we're halfway between having and not having MSI (leaning more towards not having it, the way it's modeled now), so even that wouldn't be drastically different. Indeed, the absence of MSI would likely necessitate the development of VS mode, in order to have some way of better SA, which AFAIK is skipped now, since it's very unlikely to be used with MSI anyway. FOX3 logic and datalink logic would need to be developed by ED anyway, for aircraft like the F-14. If the code is robust, it should require just a plug and interface design for other aircraft. The only extra MITL weapon is the SLAM-ER, if we're keeping the conversation to 1993 max. So the entire MITL logic would need to be developed anyway. I'll give you the JDAM/JSOW, although they're essentially one item and the JDAM logic existed already for the A-10C. The main reasons for the delays in the Hornet are the need to develop new DCS-wide systems (DL, MITL), the fact that the devs need to reinvent the wheel several times apparently, because of DCS's bad code structure (a lot of things are module-dependent, instead of universal, necessitating that the devs spend extra time implementing things that should be able to be plugged in - just look at how inconsistent the radar simulation is between modules, whereas the physics of a radar are obviously the same) and the fact that a lot of things were implemented wrongly in the Hornet from the start and need to be reworked now. All of these conditions would still be true for an older variant. If DCS had an efficient code base and better literature review had been performed prior to working on the Hornet, it'd likely be done by now. The point I do agree with is that we lack modern Redfor aircraft, but that's due to restrictions of their countries of origin and there's nothing to be done about that. We shouldn't limit ourselves to the lowest common denominator in terms of availability of data and deny ourselves modern Blufor aircraft, if we can have them. Their use case is realistic as well, since Blufor vs Redfor of the same tech level is a scenario that hasn't been seen in several decades.

I think this'll happen naturally anyway, as ED and 3rd parties run out of modern aircraft that they can model. But I actually think that Cold War jets will be just as hard, if not harder, to develop at the fidelity level that people here are talking about. ECM and ECCM, a proper, global radar API, and a correct RCS library, whether for newer or older radars, need to be developed from scratch, but that's true for every single radar system we could have in DCS and so it can benefit all modules. The implementation of ECM/ECCM for modern fighters will be simpler, with older techniques, but it'll be more than adequate for DCS, not to mention easier to program, since modern radars don't show any of the raw data to the pilot, only "hits" and "tracks", which is far easier to program in a video game (you don't have to show all the effects on the raw return itself, you can get away with using comprehensive probability matrices, which would be more in line with what ED is doing now and is far more performance friendly than raycasting - CPUs love matrices). In a way, modern fighter radars and systems can be easier to program, because the real interface became closer to that of a PC or a video game, over the years. And we, as the pilots/operators, care only about what we see on the displays. Given enough time, the whole "digital battlefield" idea can be implemented by ED, since it's close in logic to a video game system anyway. They just have to include layers of limitations, errors, jamming etc, but it's doable. It's certainly more doable than implementing a realistic AWACS/GCI operator that's supposed to talk to you in real time. You can get away with things like the SA page in the Horner, that provide you with the same info, while being ridiculously easier to program. So, unless we stick to either WW2 or very early jets, the only thing that differs between the development of a modern aircraft and a Cold War one, is availability of information, which is not a big problem for quite a few semi-modern fighters, such as the post-MSI F/A-18C of the mid-2000's. Taking the Hornet as an example, there is enough public info out there for ED to properly simulate MSI, radar functions etc, they just have to do it. It's not an easy task, but they need to push themselves to develop what's needed for it, since they sold the Hornet as a mid-2000's configuration that includes MSI. For me, studying and messing around with modern avionics is what's fun. I like the tech and the HMI. Not to say that Cold War stuff isn't fun, but it's not as complex to play as, doesn't have as many systems to use and manage and just flying and fighting, while fun for a time, will get old, for people like me. That's especially true for SP, where managing systems becomes an even bigger part of the core gameplay, since modern systems allow you to be more self-sufficient and less dependent on the AI of other aircraft or an AI like Jester. No matter how much that front is improved, it won't be as good as another human and that'll hurt the SP experience.

Good point, I was going to add that as well. The APG-73 version we have is the RUG2, which, while I am not familiar with the changes from the original 73, it should at least add newer components and firmware. OP, very good work on the data gathering and the discussion.

Tested, I can't see a difference between NORM and WIDE. WIDE should only show high speed targets, while norm should medium and high speed. Tested with targets ranging from M 0.3 to M 1.0 and found no difference whatsoever. All targets were close to each other and were detected together. Looks like the option change does nothing.

You seriously missed the part about the sensor priority and designation discussion? Or the part where I asked you to contribute something useful to the thread and you didn't? I understood your comment, I simply chose not to acknowledge it, since it has no bearing on the bug report. If you want to talk, you seem to know where I hang out on Discord, so message me there. Now, if you don't mind, I'd like to return the conversation back to helping ED with producing an accurately modeled F/A-18C.

Can you please also show the Tacview for the missiles? Like that, we can see whether they're guiding or not.

Disregard, please. Old comment.

I have access to the 746 and the 742, but what we're talking about isn't specific to the ATFLIR's or the radar's operation. It's about the general logic of sensors and designations and the fact that positive action is always required to select the sensor that drives the designation. tl;dr: Positive action is always required, the last sensor/system that was commanded to either track or designate is driving the designation and all other sensors are slaved to the designation. Note that they're not slaved to the designating sensors, but to the designation itself. Simply changing the TDC priority from one page to another should do nothing to the designation and should not change the designating sensor, since positive action has not taken place. Examples: If the TDC is depressed on either sensor (or WPDSG etc is commanded on a WP/OAP/MK), you have a ground designation and the sensor/system that created it is driving it. The other sensors are slaved to the designation. If sensor A is tracking, it drives the designation. Sensor B is slaved to the designation. If sensor B is commanded to track or the TDC is pressed for it, it now drives the designation. Sensor A is slaved to the designation. If WPDSG is used, a ground designation is created and all other sensors are slaved to it. If the FLIR enters SCENE or AUTO, it'll automatically drive the designation, because it's tracking. If the TDC is depressed, it'll drive it through INR. The radar will exit tracking and will display the + on the designation. If the HUD gets TDC priority. If the radar tracks a target, it'll automatically drive the designation. If the TDC is depressed, it'll drive it via a ground designation. The FLIR will exit SCENE or AUTO and be slaved to the radar's designation. Also, if you do have something useful that might help with the bug report, I'd be grateful if you could add it.

You're right. I assumed it didn't do anything because it wasn't mentioned in the changelog, I'll test it out. Thanks.

Pretty much what @Jak525says. One sensor drives the designation, until another one is commanded to, by positive action (TDC Depress, SCS etc). Simply moving the TDC priority around shouldn't do anything. If another sensor is commanded to designate via TDC Depress (for ground designation) or the SCS (for sensor tracking), all other sensors should slave to the latest designation and the latest sensor is now driving the designation. It's only logical and the current behavior (FLIR randomly driving the designation without positive action and the radar being unable to regain designation control) is not documented anywhere and is illogical.