Delta134

It is not too violent and you can certainly easily stay connected. However, it should be improved, not removed. ED should either: 1. Provide 25 degrees of bank for the tanker and improve AI AAR capabilities while making sure the tanker remains level as well and/or 2. Make sure the tanker is able to fly its track properly at 15 degrees of bank Regardless, the way it is currently done is suboptimal

In my and my group's experience, 25 degrees wasn't violent at all. Only at roll initiation and rollout, the tanker had some minor trouble keeping altitude. I can't speak for the AI, however if that's the problem then the appropriate fix would be to improve AI AAR, not reducing tanker's bank angle. The 15nm racetrack in the track file is just so that it wouldn't take forever to start the first turn. The problem with the 15 degree bank is that the tanker has trouble reaching its required racetrack waypoint during the first orbit. When that's the case it can start doing weird circles or patterns (even with larger racetracks).

Update 2.9.11.4686 on the 24th of December 2024 featured the following change noted in the changelog: Since the update of 19th of February 2025 the KC-135 limits it bank angle to 15 degrees instead of the advertised 25 degrees (23 in actuality) upon being cleared contact. Now once again tankers are flying huge racetracks when refueling instead of the more manageable tracks with 25 degrees of bank. Track attacked. Simple 15nm racetrack setup for KC135. Issue become apparent at the first turn once cleared contact. kc135_bank15_rdyprecontact.trk

There is/was an initiative by ED to add liveries for the US and some other countries a little over a year ago. Sadly they've gone radio silent on this.

After firing an AIM-120 at a bugged target, the postlaunch time remaining is displayed on the HUD and FCR page. Once the missile has gone active, the "A" countdown mnemonic will change into "T" and the countdown represents the calculated time until the AIM-120 intercepts the bugged target. This is functioning as expected. However, upon the bugged target becoming a no-tack, the time until impact is removed from the HUD and FCR page. This is incorrect. If the tracked target becomes a no-track, the last displayed time remaining should be used to display time until impact. Track attached and supporting documentation sent to @BIGNEWY amraam_timeout_display.trk

Sorry? Why was this moved to the F-15C Wish List? This post is intended for the F-16C. Could the question please be answered? And just to clarify: this isn't a feature request. These are features that were outlined in the Viper Mini-updates as priority items some years ago. I don't think it belongs on a "wish list"

Hey @Wags Could you give an update on this project? I am eagerly awaiting the new default liveries

Hey @Lord Vader I am seeing the same issue and reproduced it with the following steps: ANT ELEV centered STT a contact that is not co altitude Break lock by flying contact outside of gimbal limits Antenna elevation is now not centered anymore despite the physical axis being at the center point This indeed results in the inability to use the full elevation range of the radar since the physical axis does not correspond to the center point in the simulator. ant_elev_center_bug.trk

The following features were mentioned in September of 2022 in the Viper Mini-Updates thread as priority items: Digital Maneuvering Cue (DMC) Loft indications (AIM-120 loft solution cue) IAM Loft Cue Adjusting AIFF and ROE Tree logic As far as I understand, these have not been implemented thus far. I understand current F16 development is focused on the Sniper ATP (and perhaps the DTC). But since these items were mentioned so long ago, I would like to ask where along the roadmap these features are planned to be implemented? Air-to-air datalinks and PRF tones were also listed in the aforementioned thread. However, these are on the roadmap for implementation after Early Access. For the features listed above this is not so clear. So clarification would be appreciated. That being said. After reading back through mini updates thread, I appreciate the work that has gone into the Viper. A lot of what was mentioned in the mini updates and roadmap (and more) has been implemented. I trust development will continue steadily and perhaps hopefully accelerate after some large development items have been addressed. Thanks.

Ah I see, you are correct. The HMCS specific chapter indeed suggest the radar is only commanded to radiate when TMS-forward is released. What might cause the confusion is that the ACM specific chapter does not mention this behaviour. After testing I am also experiencing the stuck NO RAD in BORE Slave after an initial lock. So there are in fact two problems: Holding TMS Up in ACM BORE SLAVE doesn't command the radar to NO RAD After an initial acquisition then debugging and trying to acquire lock through ACM BORE SLAVE again, the radar remains stuck in 'NO RAD' and it doesn't acquire a lock @BIGNEWY @Lord Vader could you please take a look at this? The workaround to getting Bore Slave to work again is by pressing TMS Aft several times until in 10x60 NO RAD, then going back to bore by pressing TMS Up ACM_BORE_SLAVE.trk

It's in the -34. I am not sure I can share it due to rule 1.16. Additionally, ED marked the thread correct as is now. If you have conflicting documentation I suggest you send it to a CM

Okay, let me phrase it this way. TMS Up should not command NO RAD in any way. TMS Aft has that function.

TMS Up Long slaves the radar to the HMCS when equipped. NO RAD is not supposed to show up. This was fixed in the lates update and included in the changelog:

If you want to check whether targets have been upgraded to systems track correctly, you can press IFF OUT to get rid of any TNDL symbology. That will solve a lot of the confusion regarding if TMS Right should cycle or not.

The update today seems to have brought back a previously known bug in the flight model. During landing any roll input induces exaggerated yaw coupling. I haven't tested it yet for slow flight with gear retracted. This is a critical issue, please fix it as soon as possible, thanks. See the attached track. landing.trk

That’s correct, I was looking at AN/APG-66 documentation. Good to know it is different for the AN/APG-68. @Frederfif you have a publicly available source for this, I suggest you pass it to @BIGNEWY In the end I wouldn't mind it being implemented either way. As long as it is consistent

Do you have a source for this? The documentation I have states TWS uses RWS scan patterns when no targets are designated (1, 2, 3, 4 bar 10°, 30°, 60°)

Hey @Lord Vader The purpose of narrowing the scan limits for a bugged or cursor target is such that the contact is scanned more frequently. In the current implementation these scan limits are kept even if you cancel all targets. Like you said you agree; what is the sense in that? The only compelling argument for the current implementation is documentation explicitly stating it is correct. Even official documentation might not explicitly mention what happens to the scan limits if a target is debugged (it may be regarded as obvious and thus not explicitly mentioned). If you claim you have this explicit documentation, fine. Otherwise, I would request you please refer to common sense.

Hello, a while ago I made the following bug report: I am happy to see this was (partly) fixed on the last major update. Thank you. The following part was fixed: Slewing away from Cursor Target does not restore scan limits. (now slewing away from a Cursor Target, thus making it a System Target, correctly restores previously set scan limits). However, the following issue remains: Once a contact has been upgraded to Bugged Target, upon downgrading the contact to a System Target again, the scan limits are not restored. See the attached track for a demonstration. tws_scan_limits_bug_2.trk

The functioning of the HTS is described on page 285-287 of the manual. Delay between the RWR and HTS can be explained by the Scan Cycle Time. The Scan Cycle Time can be decreased by disabling Threat Classes on the HAD Threat Page as explained on page 292 of the manual.

What's the status on this project? Can we expect the new default F-16 liveries anytime soon?

Thanks for the clarification

I think I may not have stated the issue clearly enough. In order to upgrade a System Target to a Cursor Target, one does not need to press TMS up. One simply hovers the cursor over the System Target. This correctly sets the scan limits to a 3-bar ±25° pattern. However, once moving the cursor away from the Cursor Target (again, no TMS down required) the target should be returned to a System Target and the scan limits should return to the original scan limits. In the track file I demonstrated this is not the case. I agree that in case of a Bugged Target (TMS up on a System Target) the scan volume should stick to the target and the scan limits are reduced. So to clarify: the issue is not the location of the scan volume (this should be centered on the Cursor or Bugged target) but rather the azimuth limits of the scan volume not being returned to the original as soon as the Cursor or Bugged target is returned to a System Target (i.e. the ±25° is not returned to the original) The issue particularly pertains to the following sentence on page 243 in the manual: Disregarding the issue due to the manual being work in progress is too easy. Please seriously look into the issue I am describing.

False targets seem to appear with the RF Switch in Quiet and Silent thus inhibiting the FCR from scanning. To me it seems logical that while the FCR is inhibited from scanning, it is impossible for any targets to appear. Is this intended behaviour? See the attached track file for a demonstration. First I demonstrate false targets appearing while scanning, then I move on to switching the RF Switch to Quiet and Silent. false_targets_without_radar_scan.trk