Aquorys

PB is prebriefed mode and has the longest range, because it assumes that the coordinates that were entered are very close to where the SAM's radar actually is. You will have to follow the cue on the HUD for the missile to be able to reach the target if you're firing at maximum range. RUK is range unknown mode, works pretty much like prebriefed, but due to the larger search area, the indicated range is smaller than with PB. EOM is equations of motion mode and allows you to fire off-boresight (e.g. you can fire while flanking the SAM site), and the range indicated is calculated depending on your aircraft's attitude, and obviously even less than in range-unknown mode if you're e.g. flanking the SAM site, because the missile will have to turn towards the site first, which costs energy, and as a result, reduces range. Hope that helps.

I don't have it on an axis, I have antenna position up / down functions mapped to two positions of a hat switch on the throttle

Yes, but that wasn't my point. The problem is that the coverage suddenly went from e.g. 7k - 45k to -99k - -70k at the same distance when I switched from TWS to RWS or vice versa. What it should do is e.g. go from 7k - 45k to 3k - 57k or something like that, because RWS vertical coverage is larger than TWS vertical coverage (unless you intentionally changed it). That kind of change would be expected, but the antenna moving to a completely different attitude just because of the mode change every time doesn't make any sense. This seems to be a regression in the sim, older versions didn't do that.

With the current version of the F-16, I have seen the altitude coverage jump to useless values when you go from RWS to TWS or vice-versa, so you should frequently check whether it still makes sense. I had it set to e.g. something like ~7k-45k in TWS, and when I reset the radar to RWS, it jumped to -99k to -45k at the same range, which obviously doesn't make a whole lot of sense. Seems to be a bug. Some change would be normal, as you'd typically use RWS set to B4 and TWS set to B3, so TWS covers a smaller vertical area.

I have seen so many AMRAAMs fail and do absurd things that I'm just going to say almost everything about them appears to be broken. The most recent example being an AI Su-33 at Mach 0.7 that successfully dodged 6 high-energy AMRAAMs that were fired in ~5 second intervals. They frequently fail to guide right after having been fired, even just into the general direction of the target, although they should, even if the aircraft that fired them magically disappears a second later. They already have all the necessary information to guide to a point where the target will end up if its vector doesn't change. They practically don't work at all if they're fired from high altitude at low altitude targets, even with guidance to active range (which is one of the most well-tested scenarios in real life, because that's how long-range tests are done). They almost always fail to hit the target if the target dives, apparently because they predict an intercept course that's a mile below ground level (that's not how vertical missile guidance works). They frequently fail to fuse even when they pass so close that they almost collide with the target aircraft. They lose track against notching targets virtually always (although it's pretty well known from the reports of Serbian pilots who where shot down by AMRAAMs and survived during the Yugoslav wars that AMRAAMs are extremely resistant to notching). They reach the target area and choose implausible targets (for example, you guide them to active range, so the missile has up-to-date information on where the target is, but instead it chooses a friendly that's 4 miles further east, going the opposite direction at twice the speed and 10k ft lower, a change in target position and vector that's physically impossible). In multiplayer games, it becomes even worse, because even if the missile tracks correctly, at some point the target can just jump away hundreds of meters, probably due to latency, flight-path updates being applied too late, etc., and the missiles are not updated in the same way (could be that the target coordinates for missile guidance comes from the client, but target coordinates come from the server, and it all desyncs sometimes due to latency, at least that's what it looks like) - obviously making it impossible for the missile to hit the target that's now suddenly somewhere else. The outcome reflects this too, the rate at which AMRAAMs intercept successfully is quite low, even if you only count textbook-quality shots. What's funny but irritating is that arcade-game-like shots are actually somewhat more successful (e.g. same altitude or below, level flight and head-on deployment) than more realistic ones (e.g., higher altitude, higher speed, positive V/S, head-on deployment). Even first generation AMRAAMs achieved a kill probability of better than 75 percent in the less than ideal conditions of the real world. If you replicated all those shots in DCS with the way more modern C-5 that's supposed to be modeled in the game, I would not be surprised if less than 25 percent of them hit. End of rant, as it is probably pointless anyway. I mean, it's been like that for how many years now? We are never going to get AMRAAMs that actually work, and the reason in this case is probably ED insisting on trying to model too much realism into them without knowing how. Virtually everything about missiles is classified. Noone, literally noone, is ever going to tell ED any specific numbers and formulas concerning the guidance principles, trajectory algorithms, fusing logic, radar characteristics, warhead effectiveness, etc., just not gonna happen. The story of realistic AMRAAMs is over before it begins.

I often experience the same problem, and I suspect that it is a bug in the graphics engine of DCS, as it appears to happen only in DCS. I am using an Oculus Rift S connected to an nVidia RTX 2070 Super. A single high-latency cycle seems to be enough to cause this problem, possibly caused by something taking too long in DCS, or maybe just accessing a swapped out memory page or bad scheduling by the OS kernel. I tried setting DCS and OVRServer64 to realtime priority, which seems to improve things a little bit by making latency spikes less likely, but it is not enough to prevent the problem (unsurprisingly, as general purpose OS kernels like Microsoft NT are not hard-realtime capable, and it also would not have any effect on any latency problems caused in DCS itself, such as some piece of code taking too long while holding synchronization locks). Try this workaround whenever it happens to you: Fly your aircraft out of any danger areas, put it on autopilot, take off your VR headset and put it on the desk. You have to leave it there long enough for it to reset itself (I think it's about one minute). Then just put the VR headset back on, and you're back in business with 40-80 fps. Works for me almost every time. Not a real solution, but at least you don't have to leave the mission, so I guess it's better than nothing. Temporary fix request: As this seems to be some problem of the engine, as long as there is no real fix that prevents the problem from even occurring, I think the best workaround would be some hotkey that allows users to cause the engine to cycle through the same program functions as when triggered by the VR headset going offline and online again.

There are a couple variables involved here, e.g. your speed, range and angle to target, muzzle velocity and the ballistic coefficient of the projectiles. If you're flying level or nose-down towards a target and then start pushing further nose-down, your point of aim on the terrain will obviously move towards you, but at the same time, your distance to the target decreases and your vertical angle towards the target increases. Both those factors cause the point of impact to shift upwards (compared to the point of aim). It will depend on how all those variables play together in deciding whether your shots will hit high (and thereby also further out) or low (and thereby also closer to your aircraft). Add in some more variables that may or may not be simulated for gun projectiles in DCS, like wind, different air pressure/density at different altitudes, humidity, temperature, etc., and it'll get really complicated.

Here are some track files showing a simple demo scenario. Target drone at 31k ft. ASEC demo level flight.trk I'm flying level at 30k ft, ~370 kt, firing at 29.8 nm, missile impact after ~50 secs at ~690 kt / Mach ~1.7 ASEC demo intercept cue.trk I'm starting at 30k ft, then follow the intercept cue, ~370 kt, firing at 29.8 nm, missile impact after ~50 secs at ~690 kt / Mach ~1.7 ASEC demo firing solution.trk I'm starting at 30k ft, then fly into my guesstimate of where I think the missile would want to go, which is about 30 degrees up, ~370 kt, firing at 30.2 nm, missile impact after ~50 secs at ~860 kt / Mach ~2.3 I noticed that the intercept cue also seems to do something weird in general, because it constantly directed me to descend, although my target was head-on and above me from the start and maintained a low positive V/S. ASEC demo level flight.trk ASEC demo intercept cue.trk ASEC demo firing solution.trk

Yes, or to be more precise, the small circle (aka ASC) inside the large circle (aka ASEC, or ASE circle/cue) should indicate the course to intercept the target while you're not within the dynamic launch zone. Within the dynamic launch zone, it should switch to indicating the aircraft's ideal attitude for the missile firing solution. Edit: The current behavior appears to be that it always works as it should only outside of the DLZ

The ALT REL ("alternate release") button (right above MASTER ARM) currently doesn't do anything. Should be quite easy to implement - same function as the WPN REL button on the stick.

Tested with DCS 2.7.6.13436 Current behavior: The ASE cue seems to point into the flight path of the target aircraft Desired behavior: The ASE cue should point into the ballistic trajectory that the AIM-120 wants to maneuver into after launch, so that the pilot can put the aircraft in an attitude where the missile will not have to maneuver after launch For testing: This is most obvious for high-altitude long-range missile shots, e.g. head-on, both aircraft at 30k ft altitude, distance ~30nm. The small circle will be displayed at the bottom of the large circle, indicating that the pilot should point the aircraft's nose down, but after the missile is launched, it will immediately pitch up about 30 degrees. Therefore, the ASE cue should show the small circle in the middle of the large circle when the aircraft is pointed into the ballistic trajectory of the missile, instead of into the flight path of the target aircraft.

Just tested with DCS 2.7.6.13436: Current behavior: MASTER ARM switch position has no effect on the selective jettison function Selective jettison function jettisons stores, including tanks, immediately when WPN REL is depressed GND JETT ENABLE switch has no effect on the selective jettison function EMER STORES JETTISON jettisons stores immediately when the button is pressed Emergency jettison does not work if MMC or ST STA are not powered (but see comment wrt. various F-16 variants further down in this post) Desired behavior: Selective jettisoning of stores (via SMS, S-J, WPN REL or ALT REL) should require MASTER ARM in the ARM position. Jettisoning fuel tanks from stations 4 and 6 using selective jettison should require a 1 second hold of the release button. If GND JETT ENABLE is in the ENABLE position, all jettison functions should work on the ground / with weight on wheels (selective jettisoning on the ground still requires Master arm in the ARM position) Emergency jettisoning of stores (via the EMER STORES JETTISON button) should require a 1 second hold of the button. Note: You may also want to check some more details, depending on which exact variant of the aircraft you are modeling. There are some details that differ, especially for emergency jettisoning, with regards to MMC & ST STA on or off. On some variants, EMER STORES JETTISON will temporarily power the MMC and ST STA / SMS systems to perform the emergency jettison function.