Naquaii

Yeah, no worries. Was kinda an assumption on my part as there's much talk about the APQ-120 going on atm. Just wanted to make sure people aren't expecting the exact same picture on a different radar like the AWG-9.

It's a combination of things. One is that that radar model for pulse in the AWG-9 isn't nearly as advanced as the one developed for the APQ-120 in the F-4E. It's only natural that our focus for the AWG-9 was on the pulse-doppler side of things. With time and luck there might be some back port of the tech for the AWG-9 as well as it would be nice to improve where we can. No promises of any sort though. That said it's also not a straight comparison. The AWG-9 is a different animal all-together and various different factors (especially the antenna design) combine to mean that some factors, like the altitude return and sidelobes weren't as prevalent as they were in the APQ-120. Still factors but not the same as the APQ-120. So even if fully implemented you should not expect it to be the same as the APQ-120.

Yeah, I've seen that. But that's also the only source I've ever heard that from. The information I have says the opposite and it wouldn't make sense either way.

The limitation is that you need to be in STT, so single track. I've never seen a limit mentioned in any documentation about only being able to support one AIM-7 at the same target. That's how we model it.

A tip with SRS is that you can set each radio to either left or right ear. Fully or partially higher volume. That helps me a lot to have them in different ears.

Likely because it was a really early HUD and that it was too difficult to make a pitch ladder that was correct to the outside world. Or they just didn't prioritize it due to not having enough experience with HUD interfaces in general.

Yeah, there is other symbology like that one and the targeting stuff that is positioned correctly vs the outside world but the pitch ladder is not.

Not sure what you mean by aligned, like I mentioned the pitch ladder on the HUD was never intended to be referenced to the outside world. You can use the trim to move it on the HUD but as it doesn't correspond to the outside world it won't be correct for anything but that specific altitude and aircraft position. You really should regard it as a digital ADI that's on the HUD, nothing more. Imagine the ADI in the attached image transposed digitally on the HUD, that's basically what it is. And the only reference to read the pitch line being the aircraft wings that I've circled in the HUD image. The pitch lines aren't designed to be used as a reference for anything but those. You're ofc free to use it as you wish but this is the reason it isn't detailed in the manual, it was never intended to be used in any other way. This is the primary reason why the HUD in the F-14 isn't a primary flight instrument unlike in newer aircraft where the horizon line on the HUD is in the correct spot on the HUD vs the outside world. (And the other pitch lines for that matter which it isn't in the F-14.)

That's because there isn't a setup or trim for "proper use". The pitch ladder on the F-14 HUD isn't at all referenced to the outside world, it just references the wings on the HUD. You should regard it as an ADI on the HUD and an instrument in itself not referenced to the outside world.

I disagree, I've yet to see any source of that that's not an internet source without any references or second hand knowledge from some interview somewhere. That's just not good enough in my book to be proof of this.

The real problem is that in addition to that we don't even know if they actually worked. As in being able to be launched and having it actually track and hit something.

Afaik it's an ongoing thing.

Not sure who you've been discussing that with. I've seen exactly no-one defending the missiles going backwards. What we've said each and every time is that the missile kinematics, i.e. the motor performance and the aerodynamics are really close. The guidance however is lacking which makes the missile worse off than it should be due to that, but that also not really something a 3rd party can fix. The issue with the backwards lofting/firing missiles is due to how lofting in DCS works (at least with older missiles) and the fact that players have started to manually loft which wasn't really intended either in DCS or IRL. But no-one is defending that and it's not correct behavior, but again, also not something HB can fix on our own.

Known and on the list to be added.

It's not just that either but these old phosphor based screens are really hard to capture accurately in themselves as well.

It's notoriously hard to capture how an old phosphor screen like that looks on video and this is added to that also a kinda crappy old video that has been digitised. The colors are likely way off. My guess is that the AJSH radar looked kinda similar to the PS-37 but that that video is not a good representation of the colors at all.

No, those does not contain the parts related to the weapon systems. Like I said we've had to piece this stuff together from other sources.

We have extensive documentation gathered while researching the aircraft. Stuff like maintenance manuals etc that while unclass isn't available on the net.

It's purely trigonometry, the only thing the radar knows is the angle to target so, like I said, you need to have either a previous track which gave you altitude and speed or the RIO needs to guess.

We can't really tell exactly how the AIM-54 was launched simply from this and how the AWG-9 was affected. There's not really any information about this in this document, just that it could launch at it and hit it. The ADR used angle to track and speed and altitude to estimate range, but was hard to use as you'd either need good previous measurements from the radar or good guesses from the RIO and would become increasingly inaccurate as soon as the target manuevers. You also need quite a bit of altitude difference for it to work at all. And just to be clear, this is currently not modelled in DCS.

No, you're misinterpreting it, the only release date given is still winter 23/24. (Until end of March) As my attempt at a clarfication tries to say is that what Cobra meant is that the team is busy finishing off certain features to show those features off. He's not talking about the module in it's entirety. You can't just read "this week" and skip all the rest!

It should be positioned in the right spot according to seen closure but you also have the closure rate on the other side so there's really no reason to use that. The point of it existing is that it's the actual radar return and that you want to see that visually, the other readouts are better for basically everything else in STT. The part about the azimuth is that the radar doesn't adjust for seen groundspeed (ownspeed) at each azimuth, it just applies own speed across it all. That's why the MLC is a curve, not a line. So with greater azimuth you have to compensate for that curvature yourself as you should really measure distance to the MLC curve, not to a straight line across the scope. In this case my guess is that the deflected real return in code is using that position to display the return, not what it would be at the actual azimuth. Unfortunately I don't really have the time and ability to load those files in atm and have a look so if there's anyone else here that feels like helping that'd probably be quicker.

I've been able to reproduce but the first issue is likely not a bug, if you switch between the different aspect settings the previous location remains for a moment before being erased, that's just how a screen like this works, like an after image. So unless those extra markers remain over time that's not a bug, that's just how the screen works. The other one is a bug though but a minor one as far as I can see.

Seems like you've actually stumbled upon two unknown bugs here (at least to me). The extra markers seem to be the target returns from the two other aspects which shouldn't be there and the positioning of the target rate vertically seems to take azimuth into consideration when it shouldn't. (Normally you have to consider the location for the MLC for targets offset in side for azimuth). So both of these seems to be bugs and I'll save your screenshots and report them. At least it shouldn't hinder anyone as you're better off using the closure rate on the right anyway. So please disregard the location of the target return on the left side in PD-STT for now.

Both STT modes build a trackfile that drives the target tracking, the difference is just how it calculates the different values. In P-STT it tracks using angles and range but that is then used to calculate rate as well so the rate shown is valid. In PD-STT the target is tracked using angles and rate and the range is then measured using FM-ranging, kinda how it is in RWS and TWS. To be able to show range vs azumith in PD-STT the AWG-9 shifts the real target return to the left and generates a synthethic target return at correct azimuth and range instead. It's a bit hard though to say too much about the scenario you describe other than that it can be hard to get the radar pointing exactly where you want it too. An IRL RIO would likely use a 1bar or 2bar scan and try to point it straight at the target instead but that can take much training. Also the range of the pulse modes is much less than the PD modes. Also remember that the altitude coverage indication is for coverage at the selected TID range and only shows coverage at TID cursor when you're in half-action.