KenobiOrder

It's still a capability. There can also be cars in Germany going faster than 100knots. It should be reduced to the 70 knot option.

The velocity gate is also too high. Lowest setting in for the 1980s manual is 50 knots, with 70, 90, and one that is over 100. Later manuals indicate similar capabilities. DCS velocity gate is like 100 knots.

You dont have anything, which is why you are speculating about what they are using and saying newer than "we" have. Everything they have put in the game so far is from the A/B MLU manuals which are the only publicly available manuals aside from the HAF -34. There are noticeable downgrades compared to the older block 50 functionality in the HAF manual.

Yes but it's the correct radar, and I'm fairly certain they didn't downgrade certain aspects of the radar during ccip. The point is we donst have a 2007 block 50 manual and a a/b apg 66 isn't a correct either. So fundamentally things ar going to have to be spliced on a best guess basis. There is also alot of stuff described in the -34 that the mlu manuals don't have.

yes, there is a HAF Block 50/52 -34. There are numerous differences. The only other public source of F-16 avionics employment is the 3 part MLU manual, but this is for A/B models with APG-66 being upgraded to MLU. In the block 50/52 C, there is no need to switch manually from system to track files. The manual doesnt even mention a difference in file types. TWS is entered simply from hitting TMS right, and it works like it does in the Eagle or Hornet in the sense that your in TWS and there is nothing more to do.

Speaking of real life documents, the radar symbols are too small and the tws system to track file operation is wrong. You guys appear to be using the mlu manual, which are for the a/b and not the block 50 c model. There should be no switching of system to track files via tms right

Squadron Name: Leper Colony Discord ID on MVP Discord: Major Kong Contact person Discord ID: Major Kong Aircraft Selection. F-15C Pilots: USA - Masterpooner

F20 utility manual

Where are you getting that from. I have numerous similar documents and have never known any of them to be wrong. Yes I can see that, but I would definately put this in the design flaw category, not design decision. I have a hard time imagining what esoteric situation I would want to know the exact time of a contact trail. Frame storage would give an estimate of this anyway, which is all anyone is likely to mentally process anyhow given multiple contacts, overlapping bars etc. This seems like more or less useless information at the expense of turning the screen into a mess. Especially now that the radar detects air to air missiles which seems highly unlikely except at very close ranges. I read the part on how TWS handles track files and your certainly right that DCS has this wrong. Has it been reported? I dont think this would help the situation in search however, only TWS.

Image removed due to forum rules - Bignewy According to that manual the symbology of aged hits should look like this, not merely faded hits. this would be far easier to distinguish

According to the F-20 utility manual available online, the radar should be using frame storage not merely time. The F-20 radar is extremely similar to the F-18. If someone has a better source of information, please provide. The F-20 has target history options of 1-4, and it states that if history is 1 "only the present target is displayed. With number 2 the most recent target position is also shown. Each higher number presents an additional target history trailing image at reduced intensity." This clearly is frame storage like every other aircraft and not time.

Ok so upon further investigation I have figured out what my problem is. As you said, the radar has no frame storage and instead just used time. Is this correct? If so where is a source on this? Every other radar system I have seen allows the selection of the number of frames stored, not a timer. Case in point, I found out that the reason I am seeing so many trails is because at lower settings the radar sometimes picks up the contact twice due to overlapping bar scans, and this becomes worse as range drops for obvious reasons. If the timer is set to a more useful setting, say 8 or 16, you end up getting a cluttered mess because it holds onto every contact until that contact has been on screen for the allotted time. This results in a ton of redundant contacts, and higher timers that work well at medium ranges produce total chaos up close. In addition there is the whole issue with the track files you mention. If this is correct its one of the silliest choices in radar design I have personally ever come across. Also I get that this is from a game, but the fact that its different makes me wonder who has this wrong. This is from the janes F-18 manual. According to this, the aging setting is based on frames, not time. This seems far more reasonable, and I wonder if ED has possibly misinterpreted whatever sources they are using for modeling the radar. Or maybe Janes had it wrong, but this would certainly be a strange design decision. Also the "time" selections for the F-18, 2,3,8,16,32, are very similar to the frame storage options available on other jets (such as the F-15, real world data).

I am not referring to the track files here, as those only apply to the HAFU symbols in TWS or LTWS. The raw hit storage as currently implemented is not just based on time. They have added a frame storage option that is similar to the F-15 or F-16, except it cannot be adjusted. Imagine a 4 bar scan with 8 second timer at 140 degrees sweep. Raw hits are represented by bricks, and older bricks fade out over time. When the timer hits 8, it wipes everything, apparently track files included. Frame storage greater than one means that raw hits will stay on the screen even when there are newer ones. If you had a frame storage of 3, up to 3 frames of hits would be shown at different levels of fade. This creates a mouse trail effect. Because the frame storage is set rather high and cannot be adjusted, everything stays on the screen until the timer is up. So every single hit gets duplicated multiple times until they are all wiped. So with 8 seconds you are going to have two sets of bricks on screen for the same aircraft at any given time. This clutters the screen incredibly. Ideally, like every other plane in this game and others, we would either have control over the frame storage or it would be set to one with the timer set relative to the scan time needed to complete a full frame. So the radar would show a contact, and this contact would simply fade slowly so that it remains on screen until the new scan starts and the updated hits are shown. Right as the new hits are shown, the old hits would be deleted, preventing the mouse trail problem.

The radar now has a frame storage feature that causes each radar contact to have a stream of faded contacts behind it from previous hits. For some reason, there is no way to control how many frames are stored, unlike other us aircraft. Additionally, there is a separate time setting that wipes the entire radar picture. Based on how other radars in the game work, the current implementation in the F-18 seems unlikely. The radar frame fade on old bricks seems to have its own time settings, but those get over-ridden by the timer setting if the time is lower than whatever the frame store time is. So at low timer settings, the frame storage is pointless because the radar gets its entire scan wiped in a time less than the scan (for example a 4 bar 140 scan with 2 or 4 second timers) If the time is set to 8, 16, or 32 seconds, the extremely long radar frame storage causes the entire screen to be saturated by old contacts. This makes it extremely hard to interpret the display. There is no way to set the radar up in a reasonable way. If the timer is set too low, the screen is erased so fast its hard to keep track of targets. If the timer is set higher, the radar becomes so brick saturated that its unreadable. What would be desirable, I find it hard to believe the real jet does not do this, is to have the frame storage adjustable so that the frame storage can be set very small (1-2 frames) but where the timer to wipe the display is set to a time equal to the scan time of the current bar and azimuth configuration. This is how it is on other jets. On jets that do not allow adjustment of one of these settings, it is set so that the above condition is the one implemented.

Thanks

After 2.7, I notice that TWS manual no longer slews in azimuth for some reason. Additionally, the radar is now picking up every single air to air missile cluttering the radar screen to near uselessness. Exacerbating the missile tracking clutter is the fact that the way the F-18 handles frame storage seems to be extremely odd and nothing like the other jets in DCS. Its also unlike any description of radar operation I have read in manuals or videos of certain radars in operation. RWS track bricks fade slowly after contact. Ok. But now they also have a completely uncontrollable frame storage option that appears to save about 3 frames, causing every single contact on the screen to have a screen cluttering trail running behind it. However, the timer function is still controlling the actual time the bricks stay on screen. So if you dont turn the time before track delete up, the radar wipes the screen too fast to be useful except at very narrow and very fast scans. If you turn it up, the brick fade time combines with the timer to produce massive trails analogous to mouse trails. Its seems as though we now have a double effect that is detrimental to radar usage. And then on top of this the RWS bricks are still being shown behind TWS HAFU symbols, making it hard to read anything on screen. I find it very hard to believe this is how this radar is supposed to work.

A better analogy would be getting rid of battle rifle and a sub machine gun for an assault rifle. There is a reason the army doesn't have 500 kinds of gun anymore. There is a reason we have main battle tanks and not light, medium, heavy, super heavy, and tank destroyers and assault guns. We should have specialized tools, but generally only when the differing roles so extremely do no overlap that it's utterly necessary. You do not want redundant systems, especially if they require the rest of your force to even facilitate their role. Having this many types has caused nothung but problems. Amraam, lite ting, and datlink were all significantly delayed because of the need to factor in making them fit on runt planes like the f16. I would make rather have diversity of weapons, which provides far more multi mission ability than different airframes do broadly. Multiple redundant types only makes this harder. Furthermore the Navy has been demonstrating for some time that you don't need a different airframes for every little role.

Not saying Navy and AF planes don't have substantiallly different needs. But the hornet was not originally designed with those in mind. If you had a land based hornet before the changes made so it was suitable for carrier use, there is no major different between a 18 and 16 in general terms. Yes they perform differently, but you certainly wouldnt buy both. The point is there is no reason to have planes with majorly overlapping capabilities. A single multirole jet for the Navy and a single one for the AF is sufficient. The idea that we need a special gadget to min max every role is why the air force still can't get rid of things like the A10.

The hornet wasnt designed for the Navy. Both it and the F-16 only existed because a certain fool named Boyd semi-illegally started the LWF without actual approval. He was actually only supposed to be researching the concept and and actuality took the money he was given and had two aviation companies start developing the planes. The F-16 only got picked up by the air force because it was under budget pressures and Schlesinger brokered a deal where he guaranteed the USAF could have a ton a planes to fulfill their force size dreams if they agreed to shut up about the Eagle and but the LWF. The navy, which had been on the losing side of the budget battle for some time, later snatched up the Hornet because it couldn't get funding to design something better and because the F-14 had been also so budget hamstrung that it wasnt the plane they had truely wanted. That isnt to say that the Navy didnt need a slightly different F-35, or that it was the Marines stupid VTOL obsession that caused more trouble than it was worth(on that I agree). But there was absolutely no need for either LWF except for export. Both services desired, and would have been better off with a single multi role aircraft. But unlike every other service branch the aviation community has never been able to figure this out because there are too many people who love their pretty airplanes. The ideal would have been a multi role Eagle and Tomcat. The 35 might fall victim to this same crap all over again. Rubbish narratives about specialized planes, dog fighting, etc.

What none of the naysayers seem to understand is how the costs of things like this actually work. -F-35 is expensive to operate and its operational rate is low: This is how it has been for every single US warplane. All the legacy jets were like this during their initial employment, some for a decade after coming out. The reason the operational rates are low is because the plane is new and maintainers have less experience, and MAINLY because they have so few planes. This means that the cycles of maintenance vs training vs deployed planes are shorter, and thus operational rates fall. -F-35 program is most expensive ever! : Yes if you compare it to a single other aircraft. More F-35s were planned to be procured and its development was more complex because it had to fill many shoes. A more reasonable comparison would be combining the cost of all the teen series fighters together and comparing that to the F-35.

I there is a general misapprehension of what primitive means in terms of the radar in these aircraft. Track While Scan correlation logic and track memory are not particularly advanced capabilities. They certainly provide the high level of functionality required for a pulse doppler aircraft radar, but everyone seems to forget that these kinds of capabilities are literally 40-60 years old. If the real AWG-9 functioned like the one we have in game, than no one would ever have considered it capable to performing its design mission. It would not even have been suitable for fleet defense agaisnt missiles or bombers. The current in-game radar cant seem to keep a track to save its life even under the simplest of conditions. It cant seem to correlate tracks properly, and this is probably part of why the OP noticed that the radar never seems to require a lost track. Do some reading on how track memory works or how TWS track correlation works. I highly recommend Skolniks radar handbook or Stimsons Introduction to Airborne radar. The aircraft computer basically needs to calculate the statistical distance of received contacts from previously known ones by comparing them based on weighted parameters of said tracks etc. You dont need a mainframe to do this. Consider that while your home computer is orders of magnitude more powerful than the computers in a F-14, it is doing something like this while running the rest of the DCS game and whatever else you have running in the background on your PC.

Not really. The chaff would slow down rapidly below the Doppler gate and be filtered out. The chaff would take a moment to bloom to have any effect, and by that time it would be too slow to matter. If by some extreme luck a chaff bundle bloomed, and happened to be in the resolution cell of the radar with sufficient velocity, it would be filtered out through the use of other gates. For example, there would be a huge spike in RCS too large to be a real target, and the radar would simply ignore it for the brief few moments its velocity was great enough to matter.

I redid the test without chaff and this appears to be the source of the problem as when chaff is removed i wasnt getting false targets. So the bug would appear to be related to chaff, as the AWG-9 should be filtering out the chaff via doppler and other gates.

This is from the "Beyond visual range" mission on PG that comes with the tomcat. I decided to do it after 2.7 to see if there was any improvement in the false contact problem. Tacview-20210422-180437-DCS-F-14B_IA_PG_BVR.zip.acmi I picked this mission because it is simple and only deals with two targets. Of particular note in this tacview is that the targets never enter the notch. There was much discussion before that part of the problem with the false contacts was how the currently implemented radar logic was dealing with targets as they enter the beam. That would appear to not be the entire issue, as demonstrated here. There are only two planes actually in the air in front of the radar. Yet somehow it has generated about 8 false targets with crazy velocities to the beam. One of the targets in the tacview does not even maneuver. The one that does maneuver only does a diagonal dive to the left while popping chaff. Closure velocity compared to ground speed is well above the velocity gate at all times.

My understanding is that the current issue where active radar missiles have no inertial guidance is due to the fact the Eagle Dynamics is redoing the missile API and decided to wait to fix this problem when the redone API is complete. This problem has now existed in game since autumn of last year if my memory serves, and it is not a trivial issue. It basically means that the main air to air weapons of most of the in game jet aircraft do not work properly. Worse still, this was something that was functional in DCS until recently. I get redoing the missile API, but why cant we have the inertial guidance for active AAMs reverted back to how it was until the complete API is finished? I greatly appreciate the tremendous efforts that have gone into revamping missiles in general over the last few years, but the lack of INS for such a long period is becoming very frustrating. Either way, my hope is that something is done sooner rather than later to address this problem.