dharmab · April 18, 2023 03:11
diff --git a/rant.txt b/rant.txt
 Jak: Hornet rant was last updated 25 August 2021

 Trackfile ranking. First, MSI trackfile rank processing is wrong. The L&S/DT2 designations are affecting trackfile rank which is incorrect. They only affect priority, which is different.

 Rank is only changed by relative position/velocity and friendly/unknown/hostile ID. It's a general indication of the threats targets pose to you. The bugged behavior results in an L&S/DT2 designation essentially 'rupturing' through all ranks and bumping them up, which is wrong. Friendlies should also not have a visible rank.

 The L&S star and DT2 diamond can be thought of as going on top of the rank number on the HAFU, hiding it but not really changing it. The rank is still there and unchanged. For example: trackfile with rank of 4 is designated as the L&S. The star symbol replace the 4. It's still rank 4, and therefore the ranks of other tracks aren't affected. (edited)
 [8:00 PM]Jak: Priority. This then ties into HAFU display logic. The top eight priority HAFUs are always displayed. The 2 low priority trackfiles (priority 9 and 10) should be displayed as + symbols. In an older software, the low priority tracks were just displayed as regular raw hits, which is how it is in DCS now. However, in both versions, DCS is wrong because the L&S/DT2 designation causes 10 tracks to display, due to the incorrect modeling of rank/priority. This is incorrect; only the top 8 priority get displayed with the 2 others hidden as + symbols, unless cursored over or designated. (edited)
 [8:01 PM]Jak: And then that ties into priority. The priority of a trackfile is an under the hood, not directly seen property that is SEPARATE from rank. Whereas rank number is a constant thing, unaffected by L&S/DT2 status, the priority changes based on pilot inputs. (The rank is only changed by the ID of the target or them maneuvering to hot/cold etc.)

 The actual priority logic is the L&S > tracks under AMRAAM attack > the DT2 > all other tracks, by rank. (edited)
 [8:03 PM]Jak: So if there is no L&S, no DT2, and no tracks under AMRAAM attack, the rank and priority of the tracks would be coincident. In all other scenarios it would not be. For example, if you designate the #4 ranked track as L&S, that would make it priority 1. However, rank, which remember is separate from priority, remains #4. Of course, the number 4 on the HAFU would be hidden by the L&S star symbol but it's still #4 rank.
 [8:03 PM]Jak: This all applies to both TWS and RWS, mostly noticeable in TWS.
 [8:04 PM]Deleted User: jesus christ
 [8:04 PM]Deleted User: Jak legit we need to get you a blog. im not even complaining, i love it, but we need this shit chronicled where it wont disappear

 2

 3
 [8:04 PM]Jak: MSI trackfiles in general. Generally Multi-Source Integration (MSI) is exceptionally messed up. Display of tracks with regard to rank and ID and designation is inconsistent among the Az/El, Attack, and SA formats. They should be identical targets. One picture, three "views" basically. This makes everything endlessly un-intuitive when it's not right.

 It should also be possible to designate non-Radar trackfiles as the L&S. Furthermore Radar trackfiles should have a circle inside the main HAFU shape indicating that there is Radar contribution. This is so you can easily tell which MSI targets are seen by your own radar. (edited)
 [8:04 PM]Chimp 1-1 | Mongolokopitenko: HUSH KODIAK
 [8:04 PM]Deleted User: no i fuckin love it i dont want it to disappear in the general
 [8:05 PM]Jak: Trackfile memory. Another highly important (if not most important) and wrongly done part of trackfiles is the way they are deleted. In other words how you "lose" targets.

 The incorrect way it works now is that radar trackfiles are maintained from the last time they are detected to a time in seconds defined by the age out setting on the Data sublevel. This is totally wrong.

 The age out time only affects the display of raw radar hits (bricks). Trackfiles should have a frame-based logic. A radar trackfile is declared to be in "memory" once the radar has completed some frames without seeing it. This means it takes longer if you have a bigger elevation bar/azimuth setting.

 Once in memory the HAFU symbol flashes, rather than "fading away" in opacity. This memory condition lasts for a while (depending on scan volume and distance) before the track is deleted or "lost" for good. Of course if the Radar sees it again before deleting then the memory condition is cancelled and you're back to normal.

 If there's more than the Radar contributing to an MSI track then only the Radar contributor circle flashes in cases where just the Radar has gone into memory. This would be like if you had a Radar and F/F track. If the F/F part is still fine then only the Radar circle flashes and not the full HAFU.

 As for nonradar trackfiles or just the nonradar elements of them, there is similar logic for it all, and it gets slightly more complex with more sensors involved. (edited)
 [8:06 PM]Jak: . (edited)
 [8:07 PM]Jak: . (edited)
 [8:07 PM]Jak: RWS mode. Next, RWS mode. It is entirely incorrect with regard to when HAFUs (trackfiles) are displayed on the Attack format. (edited)
 [8:08 PM]Jak: Recall in TWS, we always see HAFUs for the priority 8 tracks and a + symbol for the 2 lowest priority. If HITS is boxed, we'll see up to raw hit symbols as well under the HAFUs. We also see all hit symbols not correlated to existing trackfiles, the 'unfiled targets.' (edited)
 [8:08 PM]Jak: In RWS, in DCS, the logic is fucked. Here's how it should work:
 [8:09 PM]Jak: The RWS display is largely dependent on the LTWS and MSI options in the DATA sublevel. Let's go basic first, and assume both LTWS and MSI are unboxed. (edited)
 [8:09 PM]Jak: LTWS Unboxed/MSI Unboxed. In this scenario, in RWS, ALL we see is raw hit symbols with no associated HAFUs. However, trackfiles are still processed just like TWS, we just don't see them, EXCEPT if a trackfile is designated the L&S or DT2. There's also an exception for targets under AMRAAM attack, if you're launching Memeraams in RWS for whatever reason. (edited)
 [8:09 PM]Seraph 2-1 | My BFF is a KC-135R: I really need to start flying the F/A-18 again
 [8:10 PM]Jak: In any of those 3 cases, the HAFU is forced in RWS ontop of the bricks. So basically you have all raw hits except your priority designated L&S target and DT2 target (if you designated them at all). (edited)
 [8:10 PM]Chimp 1-1 | Mongolokopitenko: damn Jak
 [8:10 PM]Jak: If you put cursor over a hit in this scenario, no trackfile is displayed; you do however get the altitude of the hit to the right of the cursor. (edited)
 [8:10 PM]Chimp 1-1 | Mongolokopitenko: that was more than I could handle
 [8:10 PM]astromonkey: Or we could just get BMS if we wanted a completed viper
 [8:10 PM]Chimp 1-1 | Mongolokopitenko: I'll be careful next time I ping
 [8:10 PM]Seraph 2-1 | My BFF is a KC-135R: Yeah, BMS is $7 too
 [8:10 PM]Chimp 1-1 | Mongolokopitenko: most of it went over my head
 [8:10 PM]Jak: Next, in RWS, again let's assume LTWS and MSI unboxed for now, if NO HAFUS ARE DISPLAYED, the ACQ Point Cue cross is displayed
 [8:11 PM]Seraph 2-1 | My BFF is a KC-135R: Jak needs to get his own subreddit
 [8:12 PM]Jak: The ACQ Point Cue indicates the position of the priority one trackfile if its HAFU is not displayed. This scenario would exist if no L&S, no DT2, and no AMRAAM is in flight. In that case the cross is there to let you know where the hidden priority one trackfile is. If an L&S exists, the priority one track would be displayed because the L&S is always displayed in RWS. Thus, since the point cue cross is only displayed when the priority 1 track is not, the cross wouldn't be there if an L&S is designated, because the L&S is both always priority 1 and always displayed. (edited)
 [8:12 PM]Jak: Next, we'll get a bit more complicated with the LTWS and MSI options.
 [8:12 PM]Chimp 1-1 | Mongolokopitenko:  what have I done
 [8:12 PM]Jak: The LTWS option in DCS is extremely wrong and basically turns trackfiles off. What it should do is VERY, VERY simple
 [8:12 PM]Jak: LTWS off = cursoring over a hit shows you the hit's altitude. That's it. Very decluttered. (edited)
 [8:12 PM]Jak: LTWS on = cursoring over a hit displays the full HAFU trackfile symbol. Since RWS usually intentionally hides HAFUs, this is handy to display any HAFU you want without cluttering the display with every single HAFU (which is what TWS does). (edited)
 [8:13 PM]Jak: The idea of LTWS on/off is to declutter under the cursor if you truly only want to see the raw returns.
 [8:13 PM]Jak: Next, MSI option. This can be combined with LTWS on or off.
 [8:14 PM]Jak: With MSI boxed, what changes is that any trackfile with non-Radar contribution is displayed on the RWS format as a HAFU. This means for example if a trackfile is both Radar and Link 16, it's displayed as a HAFU. If a trackfile is Link 16-only, it's also displayed as a HAFU. This makes the RWS display much more similar to TWS. The big difference is trackfiles that are Radar-ONLY are still not displayed, unless, recall from a second ago, they are designated as the L&S or DT2, or they are under AMRAAM attack or, again recall the LTWS function, if LTWS is on, the cursor is put over them.

 To be clear both LTWS and MSI options are display toggles only, for the specific scenario of the RDR ATTK format in RWS mode. In TWS mode, or in any mode on the SA or AzEl, they have zero affect. (edited)
 [8:15 PM]Jak: A few other matters:
 [8:15 PM]Jak: Attack format options should be cursor selectable. Currently only a few are. (fixed) (edited)
 [8:15 PM]Jak: SA format cursor should look like the Attack format's. Mach and altitude shouldn't be on the cursor, but on the HAFUs just like on the attack and az/el.
 [8:17 PM]Jak: RWS centering. you should be able to scan center in RWS on the Attack format just like in TWS MAN. (edited)
 [8:18 PM]Jak: @Chimp 1-1 | Mongolokopitenko I think that's it.
 [8:19 PM]Chimp 1-1 | Mongolokopitenko: I uh
 [8:20 PM]Chimp 1-1 | Mongolokopitenko: I feel worn
 [8:20 PM]Jak: I haven't mentioned any of the un-implemented stuff, like say Spotlight or Velocity Search. I have only ranted about the things that are already implemented, and yet incorrect (edited)
 [8:20 PM]Chimp 1-1 | Mongolokopitenko: https://tenor.com/view/willem-dafoe-laugh-crazy-car-close-up-gif-12180194
 [8:20 PM]Chimp 1-1 | Mongolokopitenko: I think ignorance is bliss
 [8:20 PM]Jak: It truly is (edited)
 [8:20 PM]Chimp 1-1 | Mongolokopitenko: how can I ever jump into DCS again
 [8:20 PM]Chimp 1-1 | Mongolokopitenko: it's a fantasy game at this point
 [8:21 PM]Jak: Now you know how I feel
	Jak: Hornet rant was last updated 25 August 2021

	Trackfile ranking. First, MSI trackfile rank processing is wrong. The L&S/DT2 designations are affecting trackfile rank which is incorrect. They only affect priority, which is different.

	Rank is only changed by relative position/velocity and friendly/unknown/hostile ID. It's a general indication of the threats targets pose to you. The bugged behavior results in an L&S/DT2 designation essentially 'rupturing' through all ranks and bumping them up, which is wrong. Friendlies should also not have a visible rank.

	The L&S star and DT2 diamond can be thought of as going on top of the rank number on the HAFU, hiding it but not really changing it. The rank is still there and unchanged. For example: trackfile with rank of 4 is designated as the L&S. The star symbol replace the 4. It's still rank 4, and therefore the ranks of other tracks aren't affected. (edited)
	[8:00 PM]Jak: Priority. This then ties into HAFU display logic. The top eight priority HAFUs are always displayed. The 2 low priority trackfiles (priority 9 and 10) should be displayed as + symbols. In an older software, the low priority tracks were just displayed as regular raw hits, which is how it is in DCS now. However, in both versions, DCS is wrong because the L&S/DT2 designation causes 10 tracks to display, due to the incorrect modeling of rank/priority. This is incorrect; only the top 8 priority get displayed with the 2 others hidden as + symbols, unless cursored over or designated. (edited)
	[8:01 PM]Jak: And then that ties into priority. The priority of a trackfile is an under the hood, not directly seen property that is SEPARATE from rank. Whereas rank number is a constant thing, unaffected by L&S/DT2 status, the priority changes based on pilot inputs. (The rank is only changed by the ID of the target or them maneuvering to hot/cold etc.)

	The actual priority logic is the L&S > tracks under AMRAAM attack > the DT2 > all other tracks, by rank. (edited)
	[8:03 PM]Jak: So if there is no L&S, no DT2, and no tracks under AMRAAM attack, the rank and priority of the tracks would be coincident. In all other scenarios it would not be. For example, if you designate the #4 ranked track as L&S, that would make it priority 1. However, rank, which remember is separate from priority, remains #4. Of course, the number 4 on the HAFU would be hidden by the L&S star symbol but it's still #4 rank.
	[8:03 PM]Jak: This all applies to both TWS and RWS, mostly noticeable in TWS.
	[8:04 PM]Deleted User: jesus christ
	[8:04 PM]Deleted User: Jak legit we need to get you a blog. im not even complaining, i love it, but we need this shit chronicled where it wont disappear

	2

	3
	[8:04 PM]Jak: MSI trackfiles in general. Generally Multi-Source Integration (MSI) is exceptionally messed up. Display of tracks with regard to rank and ID and designation is inconsistent among the Az/El, Attack, and SA formats. They should be identical targets. One picture, three "views" basically. This makes everything endlessly un-intuitive when it's not right.

	It should also be possible to designate non-Radar trackfiles as the L&S. Furthermore Radar trackfiles should have a circle inside the main HAFU shape indicating that there is Radar contribution. This is so you can easily tell which MSI targets are seen by your own radar. (edited)
	[8:04 PM]Chimp 1-1 \| Mongolokopitenko: HUSH KODIAK
	[8:04 PM]Deleted User: no i fuckin love it i dont want it to disappear in the general
	[8:05 PM]Jak: Trackfile memory. Another highly important (if not most important) and wrongly done part of trackfiles is the way they are deleted. In other words how you "lose" targets.

	The incorrect way it works now is that radar trackfiles are maintained from the last time they are detected to a time in seconds defined by the age out setting on the Data sublevel. This is totally wrong.

	The age out time only affects the display of raw radar hits (bricks). Trackfiles should have a frame-based logic. A radar trackfile is declared to be in "memory" once the radar has completed some frames without seeing it. This means it takes longer if you have a bigger elevation bar/azimuth setting.

	Once in memory the HAFU symbol flashes, rather than "fading away" in opacity. This memory condition lasts for a while (depending on scan volume and distance) before the track is deleted or "lost" for good. Of course if the Radar sees it again before deleting then the memory condition is cancelled and you're back to normal.

	If there's more than the Radar contributing to an MSI track then only the Radar contributor circle flashes in cases where just the Radar has gone into memory. This would be like if you had a Radar and F/F track. If the F/F part is still fine then only the Radar circle flashes and not the full HAFU.

	As for nonradar trackfiles or just the nonradar elements of them, there is similar logic for it all, and it gets slightly more complex with more sensors involved. (edited)
	[8:06 PM]Jak: . (edited)
	[8:07 PM]Jak: . (edited)
	[8:07 PM]Jak: RWS mode. Next, RWS mode. It is entirely incorrect with regard to when HAFUs (trackfiles) are displayed on the Attack format. (edited)
	[8:08 PM]Jak: Recall in TWS, we always see HAFUs for the priority 8 tracks and a + symbol for the 2 lowest priority. If HITS is boxed, we'll see up to raw hit symbols as well under the HAFUs. We also see all hit symbols not correlated to existing trackfiles, the 'unfiled targets.' (edited)
	[8:08 PM]Jak: In RWS, in DCS, the logic is fucked. Here's how it should work:
	[8:09 PM]Jak: The RWS display is largely dependent on the LTWS and MSI options in the DATA sublevel. Let's go basic first, and assume both LTWS and MSI are unboxed. (edited)
	[8:09 PM]Jak: LTWS Unboxed/MSI Unboxed. In this scenario, in RWS, ALL we see is raw hit symbols with no associated HAFUs. However, trackfiles are still processed just like TWS, we just don't see them, EXCEPT if a trackfile is designated the L&S or DT2. There's also an exception for targets under AMRAAM attack, if you're launching Memeraams in RWS for whatever reason. (edited)
	[8:09 PM]Seraph 2-1 \| My BFF is a KC-135R: I really need to start flying the F/A-18 again
	[8:10 PM]Jak: In any of those 3 cases, the HAFU is forced in RWS ontop of the bricks. So basically you have all raw hits except your priority designated L&S target and DT2 target (if you designated them at all). (edited)
	[8:10 PM]Chimp 1-1 \| Mongolokopitenko: damn Jak
	[8:10 PM]Jak: If you put cursor over a hit in this scenario, no trackfile is displayed; you do however get the altitude of the hit to the right of the cursor. (edited)
	[8:10 PM]Chimp 1-1 \| Mongolokopitenko: that was more than I could handle
	[8:10 PM]astromonkey: Or we could just get BMS if we wanted a completed viper
	[8:10 PM]Chimp 1-1 \| Mongolokopitenko: I'll be careful next time I ping
	[8:10 PM]Seraph 2-1 \| My BFF is a KC-135R: Yeah, BMS is $7 too
	[8:10 PM]Chimp 1-1 \| Mongolokopitenko: most of it went over my head
	[8:10 PM]Jak: Next, in RWS, again let's assume LTWS and MSI unboxed for now, if NO HAFUS ARE DISPLAYED, the ACQ Point Cue cross is displayed
	[8:11 PM]Seraph 2-1 \| My BFF is a KC-135R: Jak needs to get his own subreddit
	[8:12 PM]Jak: The ACQ Point Cue indicates the position of the priority one trackfile if its HAFU is not displayed. This scenario would exist if no L&S, no DT2, and no AMRAAM is in flight. In that case the cross is there to let you know where the hidden priority one trackfile is. If an L&S exists, the priority one track would be displayed because the L&S is always displayed in RWS. Thus, since the point cue cross is only displayed when the priority 1 track is not, the cross wouldn't be there if an L&S is designated, because the L&S is both always priority 1 and always displayed. (edited)
	[8:12 PM]Jak: Next, we'll get a bit more complicated with the LTWS and MSI options.
	[8:12 PM]Chimp 1-1 \| Mongolokopitenko: what have I done
	[8:12 PM]Jak: The LTWS option in DCS is extremely wrong and basically turns trackfiles off. What it should do is VERY, VERY simple
	[8:12 PM]Jak: LTWS off = cursoring over a hit shows you the hit's altitude. That's it. Very decluttered. (edited)
	[8:12 PM]Jak: LTWS on = cursoring over a hit displays the full HAFU trackfile symbol. Since RWS usually intentionally hides HAFUs, this is handy to display any HAFU you want without cluttering the display with every single HAFU (which is what TWS does). (edited)
	[8:13 PM]Jak: The idea of LTWS on/off is to declutter under the cursor if you truly only want to see the raw returns.
	[8:13 PM]Jak: Next, MSI option. This can be combined with LTWS on or off.
	[8:14 PM]Jak: With MSI boxed, what changes is that any trackfile with non-Radar contribution is displayed on the RWS format as a HAFU. This means for example if a trackfile is both Radar and Link 16, it's displayed as a HAFU. If a trackfile is Link 16-only, it's also displayed as a HAFU. This makes the RWS display much more similar to TWS. The big difference is trackfiles that are Radar-ONLY are still not displayed, unless, recall from a second ago, they are designated as the L&S or DT2, or they are under AMRAAM attack or, again recall the LTWS function, if LTWS is on, the cursor is put over them.

	To be clear both LTWS and MSI options are display toggles only, for the specific scenario of the RDR ATTK format in RWS mode. In TWS mode, or in any mode on the SA or AzEl, they have zero affect. (edited)
	[8:15 PM]Jak: A few other matters:
	[8:15 PM]Jak: Attack format options should be cursor selectable. Currently only a few are. (fixed) (edited)
	[8:15 PM]Jak: SA format cursor should look like the Attack format's. Mach and altitude shouldn't be on the cursor, but on the HAFUs just like on the attack and az/el.
	[8:17 PM]Jak: RWS centering. you should be able to scan center in RWS on the Attack format just like in TWS MAN. (edited)
	[8:18 PM]Jak: @Chimp 1-1 \| Mongolokopitenko I think that's it.
	[8:19 PM]Chimp 1-1 \| Mongolokopitenko: I uh
	[8:20 PM]Chimp 1-1 \| Mongolokopitenko: I feel worn
	[8:20 PM]Jak: I haven't mentioned any of the un-implemented stuff, like say Spotlight or Velocity Search. I have only ranted about the things that are already implemented, and yet incorrect (edited)
	[8:20 PM]Chimp 1-1 \| Mongolokopitenko: https://tenor.com/view/willem-dafoe-laugh-crazy-car-close-up-gif-12180194
	[8:20 PM]Chimp 1-1 \| Mongolokopitenko: I think ignorance is bliss
	[8:20 PM]Jak: It truly is (edited)
	[8:20 PM]Chimp 1-1 \| Mongolokopitenko: how can I ever jump into DCS again
	[8:20 PM]Chimp 1-1 \| Mongolokopitenko: it's a fantasy game at this point
	[8:21 PM]Jak: Now you know how I feel