streakeagle

I am using Virtual Desktop with the Quest 3. Virtual Desktop supports passing the hand controller data to the PC as if it is controller data. All I had to do to get this working was: 1. Enable hand tracking in the Quest 3. 2. Enable hand tracking in the Virtual Desktop Input settings (while in Quest 3 virtual space). 3. Enable hand controllers in DCS World VR options menu. I find it even more clumsy than the Leapfrog implementation. PointCtrl remains the most intuitive/reliable/precise means of operating controls while in VR other than using a mouse. Unfortunately, PointCtrl is almost two full years behind on shipping orders. So, I primarily rely on using real-world WinWing panels (flying by touch and muscle memory) mixed with mouse control.

While in the cockpit, you can bring up the options menu and this check box can be toggled.

I had that exact version in the mid-70s. Loved the Corsair II ever since.

How many more years before this long-standing bug is resolved? Just a little bump so it isn't forgotten.

The Forgotten Early Cold War servers have been around quite a while, so we have some idea how to troubleshoot problems. But in recent weeks, the main online public dedicated servers are causing frequent disconnects experienced by multiple people. The weekly co-op mission suddenly freezes, and everyone is disconnected. The server appears to be running ok without crashing, but the local network gets jammed. I also host dedicated servers with the same configuration. The only difference is that I add mods like the VSN F-4 and allow red side clients for PVP. I have suffered this same disconnect on my own network: i.e. I am using a separate PC as my client to join/fly on my dedicated server. The same problem has occurred at two physically different locations with different dedicated PC servers. However, they are both running the same missions/scripts: most missions have MOOSE, some have Skynet and/or MIST. The persistent PVE servers are also running SLmod, but the private weekly co-op server does not use SLmod. Today's co-op mission was using Liberation. Studying the logs from today after attempting to fly Liberations twice, the only abnormal errors I could find looked like this: 2024-02-25 21:38:08.047 INFO ASYNCNET (Main): onPlayerSlot(6, 485_2) 2024-02-25 21:38:08.048 INFO ASYNCNET (Main): rejected by onPlayerTryChangeSlot 2024-02-25 21:38:08.151 ERROR LuaHooks (Main): [string ".\Scripts\RPC.lua"]:53: bad argument #2 to 'format' (string expected, got nil) 2024-02-25 21:38:08.151 ERROR LuaGUI (Main): [string "./Scripts/RPC.lua"]:53: bad argument #2 to 'format' (string expected, got nil) 2024-02-25 21:38:12.575 INFO ASYNCNET (Main): release unit 2024-02-25 21:38:12.575 INFO ASYNCNET (Main): client[6] occupied unit 485_2 2024-02-25 21:38:12.704 ERROR LuaHooks (Main): [string ".\Scripts\RPC.lua"]:53: bad argument #2 to 'format' (string expected, got nil) 2024-02-25 21:38:12.704 ERROR LuaGUI (Main): [string "./Scripts/RPC.lua"]:53: bad argument #2 to 'format' (string expected, got nil)

At one time, this wasn't commented out. But for years now, I have to go back and fix the UH-1 joystick inputs after every patch. --{down = iCommandCockpitShowPilotOnOff, name = _('Show Pilot Body'), category = _('General')},

The show pilot command is available for key mapping only. So, every time DCS World is patched, I have to edit the AJS37 to allow me to map a joystick input to "show pilot". If this one thing was fixed, I would not need any custom inputs for the AJS37. This is what I have to paste in after every single patch: local keycommands = { -- Custom Controls {down = iCommandCockpitShowPilotOnOff, name = _('Toggle Pilot'), category = _('View Cockpit')},

I have always dragged AI down into mountain valleys to force them to either turn away or hit the ground when they are more maneuverable than my aircraft and on my tail. However, it seems that recently, whenever I engage an AI MiG-19 and get into a WVR ACM dogfight, the MiG-19 tends to go low and hit the ground or water almost every single time, especially as I convert into a firing position. Other AI opponents often go low, but don't often hit the ground unless they catch a tree or hill. I don't recall the AI MiG-19 hitting the ground this frequently.

I have gotten fairly proficient with the Mirage F1. But when playing the instant action dogfight practice mission, I could never beat the MiG-19 and almost always ended up with the MiG-19 on my tail in a desperate rolling scissors to avoid being gunned. If I tried to maintain energy or extend, I would get killed almost every time. I watched @CrazyGman's YouTube video on how to dogfight in the F1. Per the video, I edited the instant action dogfight mission to start the F1 with just over 2,000 kg of fuel. I started with 2 x Magic 1 on the wingtips and 1 x 530 on centerline. I burned up the 530 killing the MiG-23, then used the F10 menu to add the MiG-19. As I crossed 2,000 kg while engaging the MiG-19, I could now hold my own and force high angle-off gun passes. As I dropped below 1,500 kg of fuel, I could get behind the MiG-19 and eventually saddle up for a solid short range gun kill. I could not ever get a missile tone with the Magic 1. But until I cut the weight down, there was nothing I could do against an AI MiG-19. I don't know how practical it is to fight with the fuel so low. Maybe that's a better idea with the F1 EE and its refueling probe. But it was nice to beat a MiG-19 in a knife fight. I suspect a player flown MiG-19 would be harder to kill. The player can't cheat on aerodynamics like AI can, but a player can fly to the strengths of the aircraft and avoid tactics that would fail.

Yes, it does have problems. Every time I try FSAA in a dogfight, it gets ugly. But it looks so good taxiing around the airfield with almost zero shimmering or aliasing. There must be a way to get sharp images and minimize aliasing/shimmering in VR, but I haven't found it yet. Always a compromise between image quality, frame rate, etc.

As far as I can tell, there are no other mentions of the V3 in the manual (which is dated January 1975 Change 14 June 1990) other than the stick grip switch and the helmet off reset switch. But is it not a weapons manual, just a flight manual and it went through countless changes over the years. I agree that both functions are for the V3 missile/helmet sight system.

Here is an image from the same manual show the armament controls. It clearly includes the Reset Switch (V3) which seems to have a label including "OFF HLMT" which agrees with your assessment. But that would mean the other page showing the stick switch as a search light switch is wrong... it is possible they missed it since the other page shows the searchlight switch moved to the throttle grip. But the text description for search light operation still specifies the stick grip switch per the above illustration that was the next page after the text.

V3 is a revision number. I found other switches with the same label. A few pages later it identified the function of that switch as the Search light button. Interestingly enough, it also identified a button on the throttle as the search light button.

I was looking for a description of the V3 function control in the same manual, and found this illustration showing it as the searchlight button.

I was trying to see if this works tonight. Either I failed to execute this properly or it is still "pending". Based on repeated attempts, I would guess with 99% confidence that it is still pending.

I don't recall seeing this anywhere else. This is very similar to the F1 CE / F1 EE.

DLSS/FSR can reduce or even eliminate this problem. The way it "blurs" the image, it gets rid of most shimmering problems. Of course, DLSS/FSR brings its own issues, but give it a shot and see what you think. I am using an AMD 7900 XTX with a Quest 3, so I am using FSR. I have sharpness at 1.0 and scaling at 0.75. The main penalty is a slight blurring of textures, most notably cockpit text labels on control panels. There can also be problems with ghosting/blurring of some objects. But in the case of the Mirage F1, I get a nice HUD where I can read the compass and HUD pitch angles without zooming in.

I would love to see this aircraft modeled as well as possible in DCS World. That makes sense, as almost everything else in DCS World is the last/best variant rather than what actually saw extensive frontline use.

The B-52 we have in game is very different from the B-52 of the Vietnam era. Completely different engines, very different nose and tail. Yet, as an AI aircraft it looks and acts like a B-52, especially with period correct liveries. Overall, the airframe is the same. The A-7 was based on the aerodynamics of the F-8, but are physically totally different airframes neither one can adequately perform the others' role. The physical differences between the B-66 and the A-3 are minor for game purposes no different than the generations of the B-52. An A-3 in a B-66 livery orbiting near a Hanoi strike providing stand-off jamming would not be an obvious difference until you get close enough to see the tail and nose differences. The 3-view from a distance would be almost indistinguishable unless you could make out the engine pods. Right now, I am stuck with using an S-3 as a tanker/standoff jammer stand-in for the EKA-3 and the B-66. I would prefer to have both in the game, but the EKA-3 can be dressed up to act as a B-66. Whereas a B-66 was not a tanker nor was it carrier based. So, if I can only have one, I would gladly take the EKA-3 and happily use it as a B-66.

There are already multiple scripts available that simulate IADS to a decent level including shutting down radar when an ARM is in the air. Skynet is one of them, MOOSE includes a similar library, MANTIS. While a properly implemented IADS does a better job of engaging them enemy, it is also more vulnerable: the scripts tie in power, command & control, etc. So, you can degrade the IADS by taking out different components.

Adding enough EW modeling to support Wild Weasels isn't enough. By Vietnam, you need to model the effects of jamming pods, internal jammers, chaff corridors, and standoff jammers to replicate real-world combat results. ED's current implementation of the SA-2 produces exceptionally high kill rates. If you create a mission with realistic SA-2 site density, unprotected flights of USAF F-4s and F-105s would never have gotten through in the Rolling Thunder campaign. 1972 Linebacker I missions, which relied heavily on EW capabilities, would be impossible to model accurately. For now, the only way to recreate such missions is to use a lot less SA-2 sites and/or use scripting to simulate jamming, which limits SA-2 active operation. ED has quite a bit of work to do given their stated intention to model EW more realistically. While I am eager to see the results, I won't be holding my breath waiting for it. It could be years before tangible results are released into beta with most of the bugs worked out.

If I can only have one, the EKA-3B Skywarrior would be the best choice: it was a full-fledged tanker and doubled as a standoff jammer while orbiting near the coast of Vietnam: The EB-66 looked a little different, but an EKA-3B in USAF colors would be good enough for me:

The B-66 didn't just look similar, it was a direct derivative of the A-3 in the same way the F-4C/D was a direct derivative of the F-4B. Of course, the USAF made some alterations to suit its needs just as it did with the F-4. But they were just as much the same airframe as the F-4J and F-4E. Despite any differences incurred by USAF requirements, for my purposes they were the same aircraft employed the same way in Vietnam: standoff jamming. If DCS World provided an A-3 in its dual-role tanker/jammer configuration, I would gladly use it as a stand-in for the B-66. Re-skinned for USAF, it would be more than close enough.

If ED can reasonably model ECM/ECCM up to the 1970s, I would be very happy. Once the US took losses from SA-2s, jamming, chaff, etc. became important. Of course, the USAF and USN disagreed on the best way to handle the problem. Both used stand-off jammers in what was essentially specialized versions the same aircraft: the A-3 and B-66. But the USAF believed in using large, fixed formations of aircraft with noise jammers providing mutual coverage along with chaff corridors (like B-17s and B-24s with defensive guns). The USN liked giving each aircraft deceptive jammers and chaff dispensers. I don't know how far they are willing to go, but if they could model everything form Vietnam to the ALQ-101/119/131 series of pods and ALQ-100/126/135 series of internal jammers, that would cover my areas of interest.

Well, today's news informs us that ED is going to focus on improving electronic warfare. As such, there is surely a role for Wild Weasels like the F-4G in the future. The problem is how many years before this becomes a reality? DCS development tends to move at a glacial pace. I remember when the A-10C was coming out with the promise of a Nevada terrain with the F-16 and AH-64 just over the horizon. A lot of years passed before all of those things became a reality. I am not getting any younger.