Naquaii

We have modelled the LANTIRN as closely as we can with the info we have, we won't implement unrealistic capabilities for the chosen configuration. The ZUNI rockets are a different matter, those were implemented and the F-14 was capable of using them, they just weren't so in that regard we're modelling a real function.

It would be nice to do what would effectively be a "newer" F-14B with CDNU, GPS, PTID, Sparrowhawk etc but as have been stated above we don't have complete info on matters relating to primarily the PTID menus and combat oriented symbology. And even if we did get a hold of that information it would not be a 100% sure thing as it would entail remodelling the RIO pit extensively. The information regarding the -D does not show everything and is in many ways not relevant for the -B anyway as there were many other things differeing in that aircraft, not the least the radar. What we do know is that the first LANTIRN implementations were using the old TID and were used if only for a short while. In the end it was a decision between not having it at all or having it in this limited fashion and we decided to model it as we knew this configuration existed.

As said this isn't a bug, this is modelled as detailed in our documentation and should be as is. The best range resolution can be had in the pulse search mode but with all the limitations of that mode. In RWS and TWS the range resolution is limited by the FM-ranging used. And within those range resolution limits the AWG-9 won't be able to tell the targets apart. Newer radars have various techniques to get around this problem but the issue still exists to a lesser degree.

Yeah, the correct B instruments are being worked on. The functionality will still be the same though, neither the -A nor the -B shows afterburner fuel flow, only basic fuel flow.

Yeah, the AB is gradual, just as dry throttle settings are, it's just not shown.

It's correct, the instruments do not show afterburner fuel flow, according to our data that's how it was in the real aircraft.

In regards to the HUD being huge from the back pit, that's correct as Ironmike says. As the HUD is collimated to be focused at infinity (or at least close to) it will appear as the same size regardless of if your viewpoint is further away, i.e. it will always look like it's the same size to the viewer, not relative the HUD frame. Imagine that the HUD symbology itself is the same size in the RIOs field of view as the pilot just that the frame and display of it is much smaller, that will mean that the RIO will just see a tiny part of the HUD symbology through that same viewport. You can compare it to looking at the ground in front of the aircraft if in a dive, it will appear at the same size for the RIO as for the pilot as it is far away and if both look through the HUD frame the pilot will see more as he's closer to the HUD frame. Hopefully this makes some sort of sense, at least it did in my mind. You can try this as a pilot btw if you move your viewpoint towards and away from the HUD, the symbology will stay the same size but more or less of it will be visible through the HUD display.

If you find it and manage to center it enough and do a point track, yes it will.

Yeah, the A/A mode is in fully but like some of you guys have said it has no way to be slaved to the current WCS track in the F-14 so it's completely manual. The reason for it not being extremely detailed in the manual is simply that there's not much to say. You point it at a target and do a point track as with a ground track just that it's optimised for an aerial target instead.

Hi! We have documentation showing that the F-14 was capable of carrying AIM-9D, G, and H as well as references to the N as well as the AIM-7E. We know about these and would like to add them but they're unfortunately further down the list as we would currently have to do them ourselves. If ED add them to DCS later on we can for sure add them. And even if they don't we may anyway but it's not on top of our todo list for now.

If it's a three position switch, just set the two end positions as flaps up and down respectively, that's what I do on my WH.

Just as an update we have gotten hold of a mission that reproduces the issue fairly consequently so we do have something to work with. No timeline on a fix unfortunately but we're on it!

Had a look at that video with our radar guy and it has us a bit stumped. We're kinda thinking we might be dealing with multiple issues. One thing that interests us with that video in particular is that you seem to have gone A/G for a short while there, I guess maybe you wanted to wipe the targets? We really haven't tested that as you'd never do that IRL as switching means you're loading a physical magnetic tape which always runs a risk of failing (not modelled but still). Still doesn't mean that should happen so we will look into that. Our main lines of reasoning atm is that we might be looking at one issue in mp relating to rubberbanding and lag, one in sp where it relates to positioning of targets and or doing other stuff we hadn't thought of in the cockpit. We'll have to test this stuff more to try and find out. Additional bug reports will help ofc, try to mention if it was in sp or mp and if with a human RIO or not. If in sp a copy of the mission and how you got it to happened helps. Unfortunately I'll be out of the loop until late friday this week due to RL but feel free to post anyway, if not sooner I'll have a look next weekend.

Velocity is one of the criteria for sure so there might be something else at play here as well.

Thanks, I'll forward the video to our radar coder.

Just to clarify, having ghost tracks appear in situations where the radar is and should have trouble keeping track of targets is realistic and intended. We are also looking at track generation in general but what we currently have is quite close to how it is described in our documentation. The main issue here that is clearly a bug and wrong is where targets generate a lot of spurious ghosts in situations where they shouldn't.

Hi! Thanks for the video, it is entirely possible that you might get spurious ghosts against a maneuvering target when it's in our out of the notch, that's realistic and intended. The main issue is when it happens against targets that aren't maneuvering or if it is a lot of fake tracks. That said, everything helps!

It isn't really the radar trying to group them together but it being unable to tell them apart. Within a certain distance the radar return simply appears as one to the radar. And when merging into one or splitting into two the WCS will create a new track or drop a track accordingly. This distance depends on range from the radar as it depends on the azimuth resolution and that angular. So close in the radar has a greater resolution vs distance and further out less. In general this number is between 2 and 3 degrees in azimuth but it varies slightly with selected radar mode.

Hi guys! I'd just like to jump in here and say that we're definitely looking at this but we're having a great deal of difficulty reproducing it on our side. It's unlikely to be due to the INS and it's not jamming. It is for certain possible to have ghost tracks when you have bandits flying close to each other and skirting around the distance where the radar can tell them apart but not at this level. One theory we're trying to work around is that it might be related to lag in mp. Have anyone of you guys had this issue in SP or is it only MP and do you have any recollection of general lag when it happens. (rubberbanding etc) We'll keep working on this for sure.

Hi! The display type switch selects the prio for the rwr display, it doesn't disable display for other types than the selected one. The exception is the F and U which enables display of additional types. This means that unless having a very large number of threats or using the limit switch the display likely wont change as the display will likely be able to display all threats even if prioritizing the selected type. Try setting a display type and then hold the limit switch, as the rwr only shows a maximum of six threats when doing that the prio should be more obvious.

Yeah, that's correct, thanks for the additional info. As for the implementation of the MK-20 in the HB F-14 it doesn't currently matter if you set it to N or N/T as long as you set one of those two. The mark of bomb and fuze we've chosen should have an optional arming wire going to the T position which when used enables the option mode on the fuze, changing the fuze timing. But as we've as of yet been unable to implement this in DCS it currently doesn't matter if you set N or N/T on the MK-20.

The N/T settings basically tell the aircraft to hold or open the N/T fuzing claws (holders?) on the rack so if nothings connected to the tail position N/T will be equal to selecting N. It's still good practice to not do so as to not get a bad habit for when it matters. IIRC some bombs use one to arm the bomb and the other to select retarded or free-fall.

That's correct, the WCS will control azimuth, elevation and if to use 4 bar / 20 degrees or 2 bar / 40 degrees. And as for launched missiles, it will always prioritize targets engaged by actual missiles in flight above tracks that have a prio as loosing those targets will likely scrap those missiles. Gyro is the main coder for the weapon systems and has been with us from the start more or less. The data for the displays is from our cache of systems manuals for the F-14.

We've heard you guys for sure and we are discussing it. An additional note though is that we're also likely going to add a more realistic model for what actually happens to the WCS and the tracks if you disable it. This means that you'll have much fewer situations where you get away with doing this. When you disable the MLC this means that all targets detected by the AWG-9 in the MLC clutter arc will be treated as tracks filling up the track memory really quickly, even making real tracks dissappear. Even if these tracks are unlikely to generate track files in TWS it will still fill up the track register as in RWS and thus make it much less likely to track the real targets. This all depends on the situation ofc, if out at sea with calm waters there will be much less clutter from the sea than over land as an example. That said, this doesn't mean that we're not going to add a function to tell Jester this even if this is not something a real pilot would chime in on. But it's also likely that you won't want to use it when/if we have a better model for the clutter in.

Hi, that's nothing wrong on your side and it's not the BRU-34 or 42 that's missing. When loading more than one bomb per fuselage station the F-14 is supposed to use something called a MAK-79. These are not yet implemented visually. It is on our todo list for sure though!