Hornet radar bugs in 2.7

[Rissala]

There is actually 3 clear bugs in this short clip.

 

1st bug:
The TWS radar scan is not following the TDC as it should. It is behaving as in BIAS mode.

 

2nd bug:
The target is still getting impossible mach numbers assinged to it. Such as mach 100+.
 

3rd bug:
The target, while visible to the hornet radar, dissapears after a few seconds. It can be seen from the scope, that the radar is "about to lose" the target many times and after a few scans, it is lost. This is incredibly frustrating on MP.

(Bonus bug)
There seems to be a "brick" type track under the main TWS track altough there is only one out of 8 full tracks used.

hornet radar bugs_1.trk

[Hulkbust44]

There is actually 3 clear bugs in this short clip.
 
1st bug:
The TWS radar scan is not following the TDC as it should. It is behaving as in BIAS mode.
 
2nd bug:
The target is still getting impossible mach numbers assinged to it. Such as mach 100+.
 
3rd bug:
The target, while visible to the hornet radar, dissapears after a few seconds. It can be seen from the scope, that the radar is "about to lose" the target many times and after a few scans, it is lost. This is incredibly frustrating on MP.

(Bonus bug)
There seems to be a "brick" type track under the main TWS track altough there is only one out of 8 full tracks used.
hornet radar bugs_1.trk

As it should, or as it did? The TWS TDC behavior was wrong before, it was corrected with 2.7. To change the scan azimuth with TDC you need to use depress to tell the system to center the scan volume.

Sent from my SM-G955U using Tapatalk

[Swift.]

You will need to separate these out into individual threads if you want them to get reported.

no2, I don't think that behaviour is necessarily a bug. It sounds more like something that would happen from track ambiguities, and it clears up over the course of the frame time.

no3, So we are currently missing correct MEM logic for tracks on the hornets radar, but in the meantime make sure you have a long enough time set on the data page. If its shorter than the frame time the track will disappear before it has a chance to be detected again.

 

no4, not quite sure what you mean with this. It sounds like it might be ED finally implementing some proper stuff. Maybe a screenshot would help?

[Raven01]

I've also encountered multiple radar bugs with the F18 Hornet while in TWS mode. While testing certain missions I use as a baseline for air-to-air engagements (local missions, not multiplayer), several things are making it extremely difficult to engage multiple targets while in TWS mode since the 2.7 update.

 

Several other things I've noticed besides the ones mentioned by the OP:

1. BIAS mode seems broken, or at least extremely sporadic while trying to select from AUTO mode. This used to work well before 2.7. It seems to work without any target in range / scope but I cannot get it to work while engaged. Maybe I missed a changelist bullet...
2. AI targets seem to react immediately when firing AIM-120Cs in TWS before the missile goes pitbull. Confirmed both visually and in TacView. The cool thing is that it appeared as though I could see the enemy chaff on my radar; is this a new feature?
3. When firing 120Cs in TWS mode and slowly moving to offset right or left, or cranking to radar gimbal limits, the missiles will show LOST for a brief period and then finally re-acquire. Doesn't seem to make a difference whether you crank hard or gradually.
4. Similar to the 3rd bug mentioned by the OP, consistently losing a lock while cranking right or left (4-bar vertical scan, 40 degree sweep) results in 120Cs flying stupid. Usually the 120Cs end up heading towards outer space or attempt to acquire at a very late stage.
5. I believe one of the changelist items mentioned that the radar range on the Hornet was nerfed. This is evident in that you typically cannot get a lock past the maximum range of a 120C. Usually the first lock occurs when the target is in range to fire, again making it difficult to bug multiple targets before they enter max range. Why??

 

Overall I was happy with the previous TWS behaviour, it seemed to work OK except for the occasional issue where the scan would pause or lock up when cranking right or left. If some of the changes to the radar (such as MAN mode) fix behaviour to make it proper, then I'm OK with that.

 

IMHO, I would say the most annoying issues would be consistently losing the TWS tracks and the AI receiving a launch warning before 120s go pitbull.

 

Otherwise the new clouds, explosions, visuals, etc are stunning. Great work there!

 

I almost wish I could test alpha builds before they land in Open Beta.

Edited April 17, 2021 by Raven01

[Tholozor]

TWS BIAS is now a subset mode of TWS AUTO. With the L&S designated (or L&S and DT2) depressing the TDC will bias the scan volume centroid towards the position of the cursor, while forcibly keeping the L&S and DT2 inside the scan volume (the scan volume cannot be commanded so far as to cause either track to end up outside the scan volume). The previous modeling of BIAS mode was incorrect, and was more representative of the now-current TWS MAN, which centers the scan volume at the cursor position when the TDC is depressed. SPOT is the cursor-following mode.

 

AFAIK the AI have always reacted prematurely to TWS-launched Fox 3 prior to pitbull. The second I launch they start dropping chaff. Not a new issue as far as I know.

Edited April 17, 2021 by Tholozor

[dorianR666]

1 hour ago, Raven01 said:

The cool thing is that it appeared as though I could see the enemy chaff on my radar; is this a new feature?

no, its just the bricks working correctly now and having a trail

[Rissala]

3 hours ago, Swiftwin9s said:

You will need to separate these out into individual threads if you want them to get reported.

no2, I don't think that behaviour is necessarily a bug. It sounds more like something that would happen from track ambiguities, and it clears up over the course of the frame time.

no3, So we are currently missing correct MEM logic for tracks on the hornets radar, but in the meantime make sure you have a long enough time set on the data page. If its shorter than the frame time the track will disappear before it has a chance to be detected again.

 

no4, not quite sure what you mean with this. It sounds like it might be ED finally implementing some proper stuff. Maybe a screenshot would help?

"no2, I don't think that behaviour is necessarily a bug. It sounds more like something that would happen from track ambiguities, and it clears up over the course of the frame time."

you can see from the trak that it is clearly not the case

[Swift.]

7 minutes ago, Rissala said:

"no2, I don't think that behaviour is necessarily a bug. It sounds more like something that would happen from track ambiguities, and it clears up over the course of the frame time."

you can see from the trak that it is clearly not the case

I just watched your track, and as you said its clear what is happening.

 

The radar is generating the track after one hit, it initially shows with a high mach and then after the second hit (after 1 frame time, in this case looks like about 5 seconds or so) it resolves into mach 0.6

 

On the topic of frame time, as you have your radar set to 4 seconds and the frame time is about 5 seconds, you are actually losing the track every 4 seconds. This is why it keeps untargeting. Until ED fix the MEM logic, you will need to set the time to something longer than the frame time, in this case 8 seconds would do.

 

Additionally having watched the track, I can see that the brick hafu combo you are seeing is because HITS is selected.

[Martin88]

How do you set longer time?

[Hulkbust44]

How do you set longer time?

Radar-data-OSB 10.

Sent from my SM-G955U using Tapatalk

[BIGNEWY]

As mentioned above please report one issue per thread, and include the track replays with each showing short examples or any evidence to support it.

 

thanks