correctly based on time Target Ageout Time - Correct or Wrong?

[Rhinozherous]

Hello!

I watched this video where he talks right in the beginning about the Target Ageout Time for Bricks and HAFUs:

https://youtu.be/0tisJn9naSE

Is this "correct as is" or is it really wrong implementation and will it be corrected if it is? (Or is it already corrected, as the video is a few months old)

Thanks!

[Tholozor]

MSI trackfile memory mechanics aren't implemented at the moment, so it's still tied to the aging setting.

[BIGNEWY]

Hi, 

What we have in game is correct, it is based on time, not based on the number of complete frames. 

thanks

[CaptPickguard]

I feel honored to have been cited, but I am absolutely not an expert! When I created the video I was incorrect in my assumption that the bricks were timing out based on number of sweeps. They absolutely timeout based on time.

The issue I was actually alluding to was not, however, how the bricks timeout, but rather how that setting affects trackfile deletion. As a general rule for myself, I never delve into official documentation, so I'll let someone actually familiar talk about this particular issue.

[Hulkbust44]

Hi, 
What we have in game is correct, it is based on time, not based on the number of complete frames. 
thanks

Then what is the basis for the time a track is held in DCS?

[Swift.]

On 6/25/2022 at 8:44 PM, BIGNEWY said:

Hi, 

What we have in game is correct, it is based on time, not based on the number of complete frames. 

thanks

Just clarifying, you mean the aging for the bricks is correct?

The track memory logic is still WIP last I checked.

Edited July 12, 2022 by Swift.

[BIGNEWY]

In the available docs we have on this, it indicates that it based on time. If you have unclassified information that it should be different feel free to PM me. 

thank you

[raus]

@BIGNEWY I think there are two different topics being discussed here:

- time vs frames: you have explained your docs say the setting is time-based rather than frame-based. Point taken. Personally, I think it is correct. 
 

-Meaning of the setting: here comes the controversy. Current implementation makes the time for both brick aging (persistency) and track „lifetime“. The opinion we are expressing -and cross-checked with Hornet pilots and other SMEs- is that it should apply to persistency of the bricks on screen, but not to the underlying track lifetime, and we should not have bricks fading constantly across the DDI, not to lose tracks if the tracking volume is big. 
 

some feedback/status about the second point would be greatly appreciated

Edited July 13, 2022 by raus
Typos