Aquorys

tl;dr: The problem is caused by an uncommanded realignment of coordinate systems by DCS, explanation below. I could reproduce the same problem that I had with intermittent tracking problems by taking the headset off, waiting for it to reset itself, and then putting it on again. In both cases, the position tracking is lost intermittently and later reestablished, and the effect on the head position in the cockpit is the same. There are two sets of coordinates, one in the game world and one that is reported by the VR headset. Let's call the head position coordinates in the game world [Hx, Hy, Hz] and the VR coordinates [VRx, VRy, VRz], and let's assume that the normal head position in the cockpit is at coordinates [Hx=0, Hy=0, Hz=0]. For a normal cockpit view in VR, whatever coordinates the VR headset is reporting when the player's head is in its normal position must be aligned with the game coordinates. This is also essentially what the "View - Recenter VR headset" function does. In my case, the VR coordinates for my normal head position in the cockpit are roughly [VRx=-0.17, VRy=-0.315, VRz=-0.589]. These coordinates are aligned to [Hx=0, Hy=0, Hz=0] when everything is working properly (in other words, [VRx=-0.17, VRy=-0.315, VRz=-0.589] == [Hx=0, Hy=0, Hz=0]). Here is a picture of the initial position in the cockpit, with VR coordinates [VRx=-0.17, VRy=-0.315, VRz=-0.589]: Then, whenever the position tracking is lost, the headset stops reporting any (valid) coordinates. When the position tracking is later reestablished by the headset, the headset starts reporting valid coordinates again: As it can be seen in the picture, the coordinates are again very close to the ones that were reported before the position tracking was lost intermittently. Therefore, one would assume that the head position in DCS should be roughly where it was before the intermittent tracking loss. But this is not the case, because DCS has realigned the two coordinate systems so that [Hx=0, Hy=0, Hz=0] == [VRx=0, VRy=0, VRz=0], which makes no sense, because there is no reason to assume that the headset coordinate system has changed. This is easily confirmed by moving away from the normal player position to reposition the VR headset as close as possible to [VRx=0, VRy=0, VRz=0], which looks pretty much like a normal cockpit perspective again: The solution to this problem is to change the DCS VR code so that no uncommanded realignment of the two coordinate systems is performed. PS: As for why the headset would even lose track when it is not being taken off, just because its cameras can't find enough "trackable objects" and "corners", I can't tell - that thing has accelerometers, gyroscopes, a magnetometer, and several cameras. The cameras should be used for finding the initial position and for the correction of gyroscope drift, but the headset should otherwise mainly rely on inertial sensors and should easily be able to go for quite a long time with minimal drift without using the cameras. I have used gyroscopes under way worse conditions (high acceleration, high vibration environments) and I would expect them to fail maybe every 4 years, not 4 times in 30 minutes. How the headset developers managed to make these sensors less reliable by a factor of roughly 5 orders of magnitude is beyond my imagination.

I just found this thread from 2019 that seems to describe the same problem, or at least a very similar one. I have to say that I find it very frustrating that obviously nothing was done over the course of the last 3 years to fix such an obvious programming error.

Without any apparent reason, the head position suddenly jumps to a different and nonsensical location in the cockpit. This seems to happen with all aircraft (so far, I have tested with the F-16 and the Su-33), and the location that it jumps to is the same every time, but is a different for each aircraft (e.g., into a forward-left position of the cockpit in the F-16, straight forward way in front of the HUD in the Su-33). The position jump is not relative to the current head position, it is absolute, meaning that even if I intentionally reset my headset position so that I end up in a different position in the cockpit while flying, I still end up in the same location after the sudden jump. I tested this by resetting my position so that I would fly the aircraft from behind the seat (as if I were in a backseat). On average, it happens every 10 minutes - sometimes it would happen twice per minute, sometimes it would work for 20 minutes before failing again. The headset is an Oculus Rift S. To rule out the possibilty that this is yet another problem of the extremely buggy Oculus drivers, I flew a turboprop around for over an hour in the same region in another flight simulator, but encountered no VR problems at all, so I am convinced that this bug is in the DCS VR code. I first encountered this problem a couple days ago, so it may be caused by one of the last updates. I tried "recenter VR headset", resetting the camera position, saving the cockpit angles, and a few other view-related things, but all to no avail. I have attached a video capture of what the problem looks like. TrackingFailureShort.mp4

I have only the F-16, Ka-50 and Su-33 (besides the Su-25T and TF-51D that come with the initial installation of the game). The F-16 is what I fly the most by far, and then sometimes the Ka-50 for helicopter missions. I fly the Su-33 every now and then for fun, probably more in singleplayer than online, and only occasionally the Su-25T and the TF-51D. The TF-51D is especially fun to fly every now and then, it's just such a hard contrast compared to the rather modern jets. I also fly other flight simulators though, and I probably fly the Beechcraft King Air and the Airbus A-350 most of the time.

That's a pretty cool story. Whenever you wanna try multiplayer, I'll be looking forward to flying with you. My personal recommendation for a smooth start would be the 504VFS and 162nd Vipers servers, or if you want to get into flying combat missions, the 4YA servers. You'll probably find me on one of those every now and then if you wanna drop by and say hello. Cheers!

For those who might find it interesting, two former fighter pilots, Maj. CW Lemoine (aka "Mover", former USAF F-16, USN F/A-18, USAFR pilot) and Maj. T. Hartsock (aka "Gonky", former USN F/A-18, USAFR pilot), are currently doing a series of YouTube videos where they react to and comment on various scenes of the movie. I highly recommend watching it, besides being very entertaining, I guess some of you geeks will enjoy some of the more technical comments of two guys who know what they're talking about. Here is a link to the playlist. It seems there will be one or a few more videos published soon to complete this series, so you should probably check again in a week or so.

1.) That is false information. "Because of the design of the optical system, the AIM-9B was strictly a tail aspect weapon, as it was blind to anything cooler than a tailpipe. The modest 11 deg/sec seeker tracking rate limited the weapon to non-maneuvering targets. All seeker electronics were built from vacuum tubes. A hot gas generator provided actuator power for the nose canards, and was limited to a 20 sec burn duration before exhaustion. Unlike other missiles of the day, the Sidewinder did not employ active roll stabilisation (via gyros and differential control input), instead employing rollerons, ie slipstream spun metal discs embedded in the trailing edge of the wingtips, which acted as four tiny gyros stabilising the missile mechanically. The engineer who thought of that certainly earned his paycheck." - Source (the author of this page has published multiple peer-reviewed journals in the subject area of air defense) Infrared guided missiles reached IOC in 1956, the first integrated circuits (ICs) were invented in 1960, and there were no IC microprocessors available until 1971. The designers of this microprocessor (Hoff, Faggin and Shima) were 12, 8 and 6 years old when the first IR guided missiles were tested, so I am pretty sure they weren't secretly building microprocessors for the military back then. 2.) Here is a documentary video made by the Technical Information Division, NAVAIR Weapons Division at China Lake mentioning that the Sidewinder could be locked onto ground targets - the original question of this thread - I have linked the time, but in case it doesn't work, it's at 35:20. 3.) This is how infrared missile guidance actually works, and it does not require integrated circuits, solid state electronics, microprocessors or software. All it needs is a sensor, a gyro, a phase detector, a couple amplifiers, servos and some rather obvious supporting parts like a power source. This description is from the original document describing the AIM-9B missile. This was originally a classified document (at the confidential sensitivity level), but it had an automatic declassification notice for 1978 on it, and the particular document that I copied this out of is also explicitly marked as having been declassified, so I think there should be no problems with posting it now. This document is from 1966.

I tried that a couple times, F-16 at slightly below M0.7 at the merge, 4xAIM-120C, 2xAIM-9X inboard, 2 wing tanks, 100% fuel, against a clean MiG-29S, M0.97 initial (energy advantage), 50% fuel, Ace AI, both at 25k ft. While the F-16 is a pig at that speed and altitude in this configuration, I was able to turn around and shoot the MiG at high altitude every time, using the 9X or an AMRAAM. I could not get guns kills, which is not surprising in this situation, but I got pretty close. I could get a guns kill without the tanks.

The original R-60 missile was introduced into service in 1974, and the software abilities that you are describing are way beyond the capabilities of any hardware or software that existed back then. Even almost 10 years later, in 1983, an IBM S/36, which was about 50% heavier than the entire R-60 missile, operated on 4 MHz and 1 MHz 16 bit processors, and a maximum of 2 megabytes of memory (more typically it had 128-512kB), with an entry price tag of about 20k US$. This was one of the most modern lightweight computer systems back then, and it was way too big and heavy to fit into an R-60. Now you show me how you're gonna run sophisticated target recognition software on that kind of hardware, and maybe then we can start talking about how you're gonna do that 10 years earlier with 10% of the weight, considering that back then, the Russians' computer technology was probably 10 years behind the Americans' rather than 10 years ahead. Besides that, the OGS-60TI seeker of the R-60 is a single color system, so there isn't even much of a signature coming from the sensor that you could feed to any kind of software for comparison to something in a database. So to sum it up, you are firmly in fantasy land with this whole idea. Besides the fact that the whole idea of only locking onto targets that are in some list is nonsensical, because it would render the missile unable to engage new threats until the missile were updated to include the new threats in its target list, neither of those missiles has such a list, because they didn't have the technology to recognize and differentiate target types. This is all still stuff from 1983.

Most people do the same thing in PvE (and the AI also tends to do that a lot), and it gets them killed very frequently. It's not a lack of maneuvering skills that gets them killed, it's a lack of applying tactics - not attacking with a tactical advantage, not knowing when to abort, not having any plan on how to get away again in the first place, lack of situational awareness, etc. Does not even need to be on flat terrain. Some coordination in your coalition would probably do the trick, so you can wash the opponents out of the mountain valleys. Or just some ground support in the scenario, e.g., simply a couple random MANPADS here and there that you can't see on the map, as it would likely be the case in real life, and there comes the BVR action that you were looking for.

It varies, this target was an AWACS, it couldn't do much to defend. The Ace AI, if I remember correctly, has perfect knowledge of the missile's state, so it definitely has an unrealistic advantage over human pilots. I guess the biggest problem with PvP in general is that most people are just lone-wolfing at ground level, basically dogfighting with AMRAAMs, a complete lack of any fear of death, absence of any realistic tactics plus some game problems that make various weapons way too easy to defeat, and you get the arcade-style low-altitude furball dogfight action movies that PvP servers are. I would not expect to see much realistic BVR action taking place on any PvP server. PvE against AI is probably more likely to let you take some BVR shots, but suffers from a multitude of other problems, from way too predictable AI behavior, nonsensical AI tactics on one hand to supernatural AI abilities on the other hand, so it does not really compare well to BVR vs. human opponents. I guess your best chance to practice somewhat realistic BVR combat would be to find a group of people with an interest in BVR combat tactics and their own servers and scenarios, so you can fly with wingmen who know some tactics and fight opponents with equal abilities.

There was a thread about it a while ago here. I also posted a comment with some screenshots showing ~40 nm hits using estimated loft angles. The computer says it's out of range, but I have done that mission a couple times, and they hit pretty much every time.

unless it's an Airbus

There isn't much overthinking in just keeping the AoA and the 2.5 degree line where they should be and then doing a proper flare and touchdown. We like to land properly, not just slam it into the ground somehow, we're Viper guys, we're not the Navy

I thought that nuclear power plants could be an interesting addition, especially if they are split into separate modules, like the reactor itself, the turbine hall, transformer station and maybe an admin building or storage facility. Maybe bigger cooling towers, or just use the ones that are already available in DCS. With a modular nuclear power plant, we could build nice looking multi-reactor plants and create missions that require hitting some specific parts of the plant without damaging the reactor core.

Yeah, does not need to get too crazy, because all those models and logic add complexity and reduce performance, but I think these additional infantry units could make sense: Rifleman - we have those already Automatic rifleman - Machine gun (M249, PK), more ammo, higher rate of fire Grendier - Assault rifle & grenade launcher, short range fragmentation damage ATGM - Probably go for 4th gen, Javelins & similar Designated marksman - Semi-auto rifle .308 or similar, range ~600-800m, better accuracy than rifleman Sniper - Bolt action sniper rifle, range ~1200m, high accuracy, low rate of fire Heavy sniper - Same as sniper, somewhat less accuracy, but can take out unarmored an lightly armored vehicles I think ALERT STATE red vs. green should make a difference. When green, they should all move at a similar pace, when red, they should probably crouch or go prone, be harder to hit and move slower. When red, snipers should be very hard to find by the enemy.

Yes. In a nutshell, with your TGP page on one MFD and your WPN page on the other, you mark a point target with your TGP, then lock the exact same point manually on the Maverick's WPN page, and then hit the OSB that says BSGT on the WPN page. The next time you create a point target on your TGP, your Maverick should point at it (or lock it, if it's an IR sensor model and you have selected AUTO on the TGP).

It's also worth noting that high speed on the wheels resets the pitch trim, so landing with a lot of pitch trim might not be the best idea.

I guess you are right for the Caucasus map, but in the entire sim, I think the longest runway is probably the extremely long (and normally inactive) 13/31 at the Groom lake facility in Nevada. I think the Persian gulf map also has several runways that are slightly longer than the one in Mineralnye Vody. The speed will vary depending on your weight, so it is quite irrelevant. As others have already said, the value that you are most interested in is your AoA. That's normal Most VFR landings in the F-16 are around 2.5°, because there is a dashed line in the HUD for that. If you are flying an ILS approach, it would typically be 3°. Some approaches may require a steeper glideslope, or a steep approach might be done for tactical reasons (or another reason would be a deadstick landing), so it's not a bad idea to practice those too. Personally, I fly 2.5° approaches at the upper edge of the bracket or slightly above, then pull back the throttle, flare and just wait for the aircraft to settle down onto the runway. For steeper approaches, I fly slightly faster and aim in front of the runway. Bringing the edge of the runway roughly in the middle between the flight path marker and the 2.5° dashed line until all three overlap is quite a good method to flatten out a steep approach before landing. For instrument approaches, just keep the flight path marker at the upper edge of the bracket and fly the glideslope and localizer. If you are off course, once the localizer indicator touches the flight path marker's circle, you should be within 5 degrees of the runway heading (plus/minus any crosswind corrections), or you will probably overshoot. Normally, you can just keep the flight path marker on the circle, and you can slightly lead the circle if it is guiding you to turn or pitch up/down. Once you are comfortable with the standard approach, and you're looking for some challenges, you can try some of these approaches: Novorossiysk 22 Gelendzhik 19 Khasab 01 Kutaisi west (in the city) from east Low visibility HI-TACAN 21L / ILS 21L into Nellis

Did you boresight it?

Personally, I agree, but I guess everyone wants something else. Ask a thousand people, get a whole bunch of different answers with regards to what they want to be done first. I think you underestimate the effort it takes to create any kind of game, much less a network-capable multiplayer 3D/VR high fidelity flight simulator. It's not as if someone could just sit down at their PC for a month or two and replicate something like DCS. Try recreating your own version of something as seemingly simple as Windows Solitaire or Pinball, and then let's talk again about how anyone is going to pop up on the market with something like DCS out of nowhere. That being said, I also understand your frustration with the current ATC system. Considering that the game has always been marketed as being as realistic as possible, I think the ATC should not have been as far off as it still is to begin with. And I don't even mean that it should have been smarter when it's still work in progress, but at least the phraseology could have been a bit closer to reality right from the start. The exact same functions could say "startup approved" instead of "cleared for startup", or "request clearance for departure" instead of "request takeoff". But again, in ED's defense, I will say that they are not performing worse than others. For example, take a look at this quite well-known MilSim game that also claims to be so very realistic. Being mainly an infantry simulator, you'd think they would start with realistic weapons, but guess what, magazines do weird things when you reload, rifle scopes behave kinda funny, and bipods don't work at all. Don't get me started on rifle cant and other ballistic problems. Compared to that, ATC actually seems like a smaller problem, I mean, at least your primary tools in this game, the aircraft, fly pretty well.

As the horizontal speed decreases and the vertical speed increases, you have to change pitch downwards for the AoA to remain constant

ECM and FCR should be irrelevant, you can normally fire AMRAAMs as long as master arm is on and they're selected. They don't require silent ECM or the FCR to be released. If they can't be released, that would probably be due to a problem with another system - spontaneously, I'd say, check DGFT/MRM override, A-A mode, SMS/ST STA, MMC, something like that.

The FUSELAGE switch controls the floodlight for the tail fin. The WING/TAIL switch, if BRT or DIM is selected, sets the brightness of the wingtip lights (that's why it says WING on it), and it turns on the inlet lights and the rear-facing light at the rear end of the tail fin (that's why it says TAIL on it), bright or dim respectively. If OFF is selected, it turns of the inlet lights and the rear-facing light, and transfers the control of the brightness of the wingtip lights to the FORM knob (and the FORM knob could then be used to turn the wingtip lights off). Just tested it, works normally, it's implemented. The formation lights are the red/green lights on the wingtips and the inlet and the various steady white lights on the aircraft. The wingtip lights never blink white, what you saw was the reflection of the anti-collision light. Note the label with the bracket around the FORM, A/C and ALL positions of the master switch that says COVERT. You didn't select the formation lights, you set them to covert mode. Same for A/C, it sets the anti-collision light to covert mode, but not the formation lights. Covert mode turns off visible lights, so it does exactly what the labels say it does. The FORM knob adjusts the brightness of the formation lights, and the brightness of the wingtip lights unless WING/TAIL is set to BRT or DIM. But that's how they work, it seems you just misunderstood some of the labels.

As I mentioned, DSMAC - it follows terrain by scanning the terrain and matching it to an onboard database that contains a map of the terrain (e.g., see here for some further information, and this is from as long ago as 1994, it was probably upgraded a couple times since then). It's been implemented on Tomahawks for decades. Hahahaha, yeah, I mean, I have to admit, I was being completely unreasonable concerning this suggestion, that would never happen! Chances are, if the Navy struggled to do the mission, some generals would still be sitting around a table trying to figure out how to get the Navy and the Air Force to work together, and meanwhile, the whole thing would get blown up by a handful CAG operators who'd pull up at the target location in a stolen Toyota Landcruiser