Jump to content

Radar Frame storage cluttering screen


KenobiOrder

Recommended Posts

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.


Edited by KenobiOrder
Link to comment
Share on other sites

The raw hit storage is based on time, not frames. The extremely important issue is that the raw hit storage time is tied to how long trackfiles are maintained, which is entirely different and unrelated. This should be completely independent from the raw hit age out. That's simply a decluttering function, and should have no impact on the trackfiles.

 

A trackfile should instead go into memory on a "missed frame" type logic, eventually going into a flashing Memory phase and then deleting entirely. It has nothing to do with the age out time. A trackfile will delete just as slow or fast with a 2 second time vs. a 32 second age out time, because they have no connection. Basically, once the Radar has missed a trackfile in the scan frame, which will happen sooner for a small volume and larger for a bigger volume (since the duration of time it takes the radar to complete the full scan is dependent on size aka azimuth/bar), it declares memory on that radar trackfile. It will flash for a bit and then the trackfile (HAFU symbol) is totally deleted.

 

The trackfile memory also plays into MSI, also missing a ton in DCS right now. But basically, if you have a trackfile with just radar contribution, then the radar going into memory and deleting means the full trackfile is deleted. If, however, you had Radar and Fighter/Fighter (Link 16) contribution to a single track, then merely the radar's sensor contribution to the trackfile will be deleted, but the trackfile itself remains assuming the other contributor(s) are intact.


Edited by Jak525
  • Like 2
Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

As an interim workaround for the clutter until the trackfile memory and brick ageout is fixed, you can disable the HITS option to clear bricks out when using high ageout settings in TWS.

REAPER 51 | Tholozor
VFA-136 (c.2007): https://www.digitalcombatsimulator.com/en/files/3305981/
Arleigh Burke Destroyer Pack (2020): https://www.digitalcombatsimulator.com/en/files/3313752/

Link to comment
Share on other sites

4 hours ago, KenobiOrder said:

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.

 

I think I understand you now. The F/A-18 simply does not store bricks based on the radar frames. It's only time based. Yes, it stores hits from previous frames, but that's only coincidental. It stores the hits purely as a function of time.

 

If you want a smaller trail, set it to something like two seconds. That should produce only one hit per trackfile. HOWEVER, the problem here is that the trackfiles are currently tied incorrectly to the brick storage time and therefore it's incredibly impractical to use the radar with a low hit storage time.

 

What you should be able to do is set the storage to like 2 seconds and therefore have it very decluttered, and the trackfiles are unaffected and stay for longer. They should only start deleting when missed in a frame. (In fact, also, TWS is supposed to have a fixed hit storage of 2 seconds; furthermore you can hide hits by unboxing "HITS").

 

TL;DR the raw hits themselves are correct. The problem is the trackfiles. Please tell me if you think I'm still misunderstanding you though cause maybe I'm missing something here.


Edited by Jak525
  • Like 1
Link to comment
Share on other sites

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).

 

image.png


Edited by KenobiOrder
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

I have always wondered that why time based history instead frame. As the frame would make more sense as you understand it better.

 

But there must be some good reason for time based one? Like you can look the screen and see three blocks trail and think "that last one is 16 seconds old..." Do you could think speed or something for target based to that?

i7-8700k, 32GB 2666Mhz DDR4, 2x 2080S SLI 8GB, Oculus Rift S.

i7-8700k, 16GB 2666Mhz DDR4, 1080Ti 11GB, 27" 4K, 65" HDR 4K.

Link to comment
Share on other sites

The depiction of hits in that diagram is simply wrong. Diagrams are often not super accurate. The age out should not be a linear fade out though so that's a bit incorrect right now unless they did actually do this right, I haven't checked. There should only be full, 1/2 intensity, and 1/4 intensity. Depending on age out it's different. 2 second age out for example the bricks never dim to 1/2 or 1/4. It's just regular brick then gone. With 32 second for example though you'd see it transitioning from full, to 1/2, to 1/4 intensity throughout time.

 

Yes it is time based in the Hornet. There is no question about this. The advantage is that you can see where an airplane was a given amount of time ago. E.g. with a 16 second age out you know the "tail end" of the trail is where the plane was 16 seconds ago. Halfway through the trail about 8. A frame based storage is way different because depending on your scan volume the time a frame takes can vary greatly. Both work obviously as it's been implemented like that in other airplanes' avionics. But it's merely a design decision. That's how it works in the F/A-18.

 

The reason it's so bad to use is because trackfiles are completely wrong right now. If they worked right, this'd all make a ton more sense and be quite intuitive.

 

I am not one to say DCS is correct as is when it isn't. In fact if you look through the vast majority of my posts around here are explaining how things are wrong, lol. The brick aging, however, trackfiles aside, is correct. It's just overshadowed by the incorrectness of trackfiles.


Edited by Jak525
Link to comment
Share on other sites

6 hours ago, Jak525 said:

The depiction of hits in that diagram is simply wrong

Where are you getting that from. I have numerous similar documents and have never known any of them to be wrong.

 

6 hours ago, Jak525 said:

Yes it is time based in the Hornet. There is no question about this.

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.

 

6 hours ago, Jak525 said:

The reason it's so bad to use is because trackfiles are completely wrong right now. If they worked right, this'd all make a ton more sense and be quite intuitive.

 

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.

 

Link to comment
Share on other sites

15 minutes ago, KenobiOrder said:

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.

 

What's the f20 radar manual called again?

I just cant belive i missed such a document.


Edited by IkarusC42B Pilot
Link to comment
Share on other sites

1 hour ago, KenobiOrder said:

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.

 

For how bricks look - Real pictures of the jet and pilot input.

 

Design flaw? I mean youre free to critique the design of the real jet, but I'm telling you that's how it is, and if real pilots had a problem with it... I'm going to go off on a limb and guess it would have been changed.
 

It's been reported yes. It'd apply to both TWS and RWS. RWS processes trackfiles in an identical manner to TWS. The difference is that RWS intentionally hides some tracks on the Attack format - the logic for which is wrong in DCS right now. And also, RWS allows for a huge volume whereas TWS artificial limits it. TWS has Auto/Bias scan centering, SCAN RAID, EXPand, etc. Both RWS and TWS in the Hornet are what would be traditionally called "TWS".

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...