KenobiOrder

I believe flood only activates if the target is in the flood fov and range. In any case not of much use if using a 120 or just trying to keep a lock for observation or tracking a longer range shot. But it would be nice to have the auto flood function as well.

I don't think this would be much hassle to implement, and its not a new feature really. Delaying the MEM to start after 3 seconds and then adding 3 more seconds on top of that is in effect merely a scalar adjustment to existing modeling. During this period the radar would require if the target appears inside the extrapolated area inside whatever gates the memory allows for. The 6 second requisition scan is somewhat different but also very simple, especially I would think for FC3 radar model. You simply draw a line to the extrapolated target position and lock onto anything that falls within a beam width defined by a 6 bar 3 degree raster, since at that point the purpose of this scan is to capture a target that is along the extrapolated position but might have move in altitude or range to be outside the previous tracking gates.

It is not a new feature, like the radar range changes were are already getting. At the simplest, ED could simply increase the timeout to 12 seconds.

Sure, but this is a core functionality like the radar range changes were getting. And ED has made adjustments to FC3 over time, such as the Flankers data link or the fact that aspect was not always factored into radar range. This is already a feature of the module, it's just way to short to be useful. This is a core function that gives a reason to use STT and prevents casual notching.

@BIGNEWY

My suspicion is that it has something to do with induced drag, but it could be alot of things. Ive tested straight line drag in the hornet and it seemed to check out. But in dogfights right now its out-rating everything...and not by a little bit. It also has absurd energy retention...or something. Right now in competitive groups the hornet is basically dominating everything, including the Eagle and even in energy fights at higher altitudes.

The document quoted in this post IS NOT ITAR Controlled or Classified. It contains no distribution notice etc. It is from 1979. source: https://www.scribd.com/doc/297530454/TO-1F-15C-34-1-1-Nonnuclear-Weapon-Delivery-Manual-Air-to-Air-USAF-Series-F-15C-and-F-15D-Aircraft-Change-6-15-Mar-1981\ According to the F-15 -34 that can be found publicly online from 1979, the F-15 track memory in STT works as follows: At ranges over 10 miles: -If signal is lost for 3 seconds, the radar goes into memory. -It stays in memory for 3 more seconds -If it does not find the target in this time, it starts a 6 bar +-3 degree scan (HIGH/MED PRF) at the targets extrapolated position for six seconds, and if it finds the target it will continue to track as normal Under 10nm: MEM is not displayed, instead after a 3 second loss the radar goes into the acquisition scan immediately in Medium PRF only for 4.5 seconds, only returning to search if it cant find the target. Below 5nm: The radar enters a 3 second re-acquisition sequence following a 1.5 second signal loss. This should be corrected, especially since this is from a 1979 Eagle and we have a more modern eagle since we have TWS and Aim-120 etc. Furthermore, while FC3 is supposed to be feature complete, this is not a request for a new feature. The game already has a track memory function in STT but it does not work properly, so this is merely a request for the function to be fixed. I think this is no different than the request for the radar range to be fixed which ED has already approved and we are just waiting for. In the game right now regardless of range, the radar immediately goes to MEM upon signal loss the instant it hits the STT notch speed of 50knots. There is no 3 second wait before entering MEM, which reduces the time the target must be in the notch by half. Additionally, there is no automatic requisition at the extrapolated targets position. In total, for a target to notch the radar in STT, it would have to remain out of the radars view for 12 seconds, not the 3 we have in game right now. I have enclosed a track that demonstrates the current behavior is not correct. F-15 STT MEMORY.trk

Or yours? What evidence do you have that makes you think it does not? You misunderstand my point. The point is that they put the inertial system in a manner specifically related to the command aspect, so much so that its used in the name of the guidance mode. As you point out, many missiles have inertial systems to improve general nav. But they dont call the sparrows guidance "semi-active inertial".

That isnt the arguement though, at least not from me, and not from a few others ive read here. Its not that being a best guess means its proven. Of course it isnt proven. The point is that its a good enough guess that its more likely than not and should be implemented until we get better information. You mentioned that you think comparison from 54A to C is reasonable, that it can be inferred they are similar etc. Ok. Well we are doing the same thing from Aim-120 to 54C. Not only do we know the nomenclature being used is the same, but they were made by the same company during the same time frame. Its seems more than a bit reasonable to also infer that if they went to the trouble of upgrading the 54 to inertial guidance as opposed to SARH, which also happens to be the same method the 120 uses (and is using the exact same nomenclature) that they implemented the entire shebang. Why on earth would you go to the trouble of adding a inertial guidance with mid course updates to the missile if you werent going to give it the ability to do the other things that were developed for the amraam at the same time? There is only one reason to have command inertial as opposed to simple "command" guidance: you want the missile to potentially operate autonomously. Going from SARH to Command guidance would generally be considered a downgrade (as it is on every SAM ive ever heard of) but going from command to command inertial would be even worse because this implies your sending updates to the missile less often and letting it coast on its own INS from time to time. Doing that only makes sense if the real purpose of the inertial reference is to provide guidance to the general intercept area in case of data link loss.

Basically what Klarsnow said. These modules are at some point guesswork anyhow. Informed best guesses are better than nerfing a weapon simply because we cant prove it definitely. Should all the missiles have garbage guidance logic , by which i mean in DCS in general and not aim54, simply because we dont have descriptions of their guidance logic? Clearly no, and what ED is doing with the aim7 and aim-120 is essentially making the best guess we have instead of restricting the missiles to PN only 1960s guidance. Command inertial is not some general term. Its specific US nomenclature for a kind of functionality. Generally when the military uses a term like that, it tends to apply broadly to certain specific capabilities. Pretty sure you dont have logic diagrams and other data for the inner workings of the AWG-9 or 54A. So those are ultimately guesses as well. Command Inertial is a term used as part of the "normal" mode the aim-120.

Thanks, guess that clears that up then.

Possibly, but I would like to get dev confirmation of this if possible. It is hard to believe this is how the system worked because basically nothing else works like that. The tactical problem it creates would render the system next to useless and its fairly easy to correct for a huge (in fact necessary) performance improvement. Also if the system did not do this in general it would cause huge problems since you can have targets fade from scan to scan for any number of reasons. It is also strange that it fades so fast and then the radar seem to initiate a new track file immediately when the contact unfades. You wouldnt establish a track file on the first scan, it would be logged in memory and would be registered as a tentative track until the radar confirmed it by hitting it again. There have been claims about check turns but we really dont know the context of these. There are any number of factors that could cause this, in particular the duration and range of the turn. For example, if the turn is done far enough away, the reduction in SnR could result in a target fading long enough to escape track. Same with simply notching for more than about 6 seconds. But simply notching for a half second seems a bit absurd.

It was done on a private server. With just a necessary aircraft needed to test in the mission. I doubt latency influenced this at all, but I totally agree that its an issue in multiplayer in general.

So after some additional testing to figure out why the AWG-9 has been so temperamental over the last year (constantly losing tracks, generating false targets, unable to resolve not so closely spaced targets, etc) I am fairly certain there is a bug or oversight where the AWG-9 has no track memory. I had a friend fly a 300knot 3G turn in a constant circle. As the target enters the notch very briefly, the radar loses the contact dumps it either immediately or near immediately. So either the track memory of the TWS-A mode is nonexistent, or it is very very small. This is probably the main contributor to the issues plaguing AWG-9 performance in DCS because the radar doesn't retain contacts long enough to associate them with new contacts. The target is re-detected almost immediately after the radar dumps the track, but the radar does not associate this is the last track and instead generates a new one. I dont have documentation on the AWG-9 but it seems highly improbable that the TWS radar modes would not have track memory, because it is essentially necessary to how such a system works. It would take at least one frame after last detection before the radar would flag the track file as missed, and it would then enter a track extrapolation mode with a correlation gate based on the possible target maneuvers. Based on other systems I do have knowledge of (all the other teen series fighters), this would last between 4-7 seconds. As it takes about 2.5 seconds to complete a frame, a target would have to avoid detection for 6.5-9.5 seconds before the radar would dump the track file and no longer associate a detection in the correlation gate as being the same contact. @IronMike It may take some time for the video to be full HD.

Its not that it should be impossible, but that it should be far less likely. A missile has a tiny radar cross section when viewed from the front or rear. In the case of a target moving away from the launch aircraft, the detection range would suffer even more. And yet when you shoot you can now see your own missile on the radar. Targets like these would almost certainly be filtered out because there is little use in seeing them and they clutter the screen to no end, especially in TWS. Quite frankly, its hard to see how TWS in any jet is picking the missiles up (especially immediately after launch) because it would take several frames before TWS correlated said detection as a track in the first place. Even then, the radar would notice the low RCS and extremely high doppler of the contact and likely ignore it entirely. In the current situation all radar modes just get completely saturated with BS missile tracks. No one would want a A2A radar that does that. It would cause all kinds of problems in building SA or sorting targets etc. Then there is the issue of them air to air missiles tracking on other air to air missiles. As GGTharos mentioned, the real missile would not correlate the small RCS high doppler missile as corresponding to its target. But there is also the issue of the current lack of INS guidance. Based on Wags most recent statements, the new INS modeling sounds very cool but its not in the game atm. What this means is that we have missiles going pitbull too early and then snagging on to whatever is there.

This happened because heatblur was asked by ED to change the rcs. The RCS of air to air missiles in game is now at absurd values which is why we have this stupid behavior regarding the phoenixes and why air to air radars are now detecting every single missile in the sky cluttering the radar screen. When people shoot the radar turns into a cluttered mess of incoming a s outgoing contacts. I have not tested yet but I would be very surprised if this doesn't cause issues with tws in the tomcat when the missile gets close to the target given how wonky it's correlation gates are.

Of course there is additional processing. But there isn't any good reason that tws should not generate separate track files if the radar is discriminating two targets. It's not a problem if the correlation areas of each contact overlap. When the radar sees two hits on the same bar scan it should generate a tentative track in memory for both. If on the next scan (or however many the radar needs) it detects then again, it should create two separate track files.

This should not happen in a tws system. If the radar picks up two contacts, it would not display any change till it determines based on the statistical difference from last track which is which. There also would be no averaging of the two different aircrafts velocity. The ddd is showing two contacts, so the radar should be able to create separate track files. What it might be doing, which I think is an error, is disregarding one of the contacts as a false alarm. Then it occasionally gets one of the contacts confused with the other based on their different maneuvers. It might get the contacts accidently swapped, but it should still be tracking two contacts. And it's odd that it's swapping them when all they are doing is flying a straight line.

I have continued to test and found some more strange behavior. Something of note is that the velocity vector indicators do not seem to be working. According to the manual they should be showing the velocity vector of the target, but instead the move to the right if the target is closing faster and to the left if slower, not actually showing the direct of the target. Second, it can be seen on the DDD that that radar in TWS can generally see two targets, but does not output them on the TID. wacky behavior.trk wacky behaviorno notch.trk failure to guide.trk

Where are you getting that figure? My expectation would be that the res cell of TWS would be the same as RWS, or sufficiently similar. 5nm sounds fantastically large, and I dont think that is the case in game either because I have certainly detected targets more closely spaced than 5nm.

The range is not a factor. Even a close range it cannot break the contacts out. The range would hypothetically matter, but it doesnt make a different in DCS F-14 in TWS. This should not be a problem for TWS. Clearly the radar is capable of seeing both contacts in terms of its resolution cell, so the issue is with the TWS logic. TWS seems to be filtering out the second contact as a false alarm, which it should not be doing. Since it sees both contacts on the same scan, these should count a separate observations. Tracking gates should then be made for both, and on the next scan it should determine which is which based on the statistical distance of each contact from the center of the gate. Its possible it could accidentally get the contacts swapped, but it would still reduce them to two independent contacts. What it appears to be doing is seeing both contacts on the same scan, and treating one of them as a false alarm. Additionally we can clearly see that there is an issue with how the radar discards false contacts in other situations. This combined with the issues with closely spaced targets is probably causing all the issues were seeing with false targets and the TWS radar becoming clutters with rubbish. In the first track you can see on the DDD that the flanker is approaching the beam. When it seems to hit the notch, a second very high velocity target is generated. The radar decided to treat BOTH of these are contacts and this is why we get as many as 3 contacts on the TID at one point. What should be happening (either or): -The high speed target would likely be filtered out entirely or treated as a totally new contact since its statistical distance should be outside the predicted gate for the existing track file. -Since the target entered the notch, even if the target was within the valid statistic distance of the gate, the contact should have been dropped. The radar should have stored the new contact in memory and then rejected it as a valid contact when it didnt appear on the next scan. This is because TWS systems dont just display everything they see immediately. If a new contact is found outside the tracking gate, the radar should wait at least one scan before displaying this contact as a track.

I have been checking up periodically on the status of the F-14s radar ever since TWS auto released. Since then, the radar has not worked correctly, with significant issues with false contact generation. It has been gradually improving, but the radar is still in a state that dubiously useful in combat because it behaves very erratically. I did some testing today and saw many strange things happen, but I had the presence of mind to record two of them as tracks. Issue 1: The radar randomly generates a second contact not even in the vicinity of the first in TWS auto. Radar then gets confused and fails to operate satisfactorily. This the track titled "false target 14" The Su-27 is flanking to the left when suddenly a second contact appears significantly displaced in azimuth to the left and significantly further in range. The contact can be seen on the DDD, and it is after this that the radar goes bananas. Issue 2: Radar cannot reliably detect semi close targets in TWS. This track is from the BVR mission on Persian gulf that comes with the game. We are not talking about targets that are right on top of each other wing tip to wing tip etc. This is aircraft at a typical formation distance. Strangely, when you enter RWS the radar has no issue detecting these targets. When you go back into TWS, it loses them. Very occasionally it will break out both targets very briefly, but I can see no pattern to when it does this. false target 14.trk TWS cant resolve targets.trk

Higher RPM means more power. A P-51 and 61 inches of boost and 3000 RPM is slower than the P-51 at 67 inches of boost and 3000 RPM, and that is slower than a plane at 75 inches of boost and 3000 RPM. We have speed charts for Mustangs at 3000 RPM and 75inches of boost. Clearly it is false that the propeller could not absorb more power since the plane was faster and climbed significantly better at the same RPM but more manifold pressure. Later P-51 H's would produce the same RPM but have even higher manifold pressures of something like 90 inches or whatever. As an empirical matter of fact it simply not the case the the propeller could not adsorb/output more thrust at 3000rpm.

The speed chart you quoted was estimated. That is not a flight test. It is also faster than the DCS P-51. DCS is clearly just wrong, which is pretty par for the course with the WW2 modules. Half the planes dont even model compression effects, the thermo-model for engines is bonkers, the P-47s prop overspeeds in a manner directly contradictory to the manual....the list goes on and has for years. If the Mustang could have gone faster IRL at a lower RPM, than the engineers would have specified that lower RPM as the best RPM for performance instead of 3000 RPM.

The actual aircraft was tested to higher speeds in every real life test. The top speed on the deck of the Mustang on a standard day was 375mph. In no real world test of the Mustang was it ever slower at higher RPMs at lower RPMs. This is an indisputable empirical fact, and anyone stating otherwise is in the wrong.