streakeagle

In the past week or so, I have witnessed a substantial loss in image quality and frame rates in the Reverb G2. When I dumb down my graphics settings to the bare minimum in DCS, I can get the fps to go up, but they are unstable and still go very low while dogfighting. In comparison, when I use the Quest 2, I can use the same quality settings I have always used, even a little better and suffer no performance losses: butter smooth and steady. I have not been able to isolate whether this is being caused by hardware , WMR, SteamVR, or DCS. For reference, I am using an AMD motherboard/CPU (Crosshair Dark Hero VIII and a 5800X), which easily could be the problem, except that it used to work fine a week or two ago. Along the way there have been Windows 10, nVidia, WMR, SteamVR, and DCS patches. This sucks, because normally the G2 gets the same or better frame rates than the Quest 2 with higher quality and equal or better stability.

Is that to say DCS is going to directly support Leap Motion and make it more useful in the future? In demo form, Leap Motion seems to nearly perfectly mimic my hands. But using all the crazy software implementations to get it into DCS seemed to lose precision and accuracy. PointCTRL beats Leap Motion with ease using an implementation style that is very close to what I hoped Leap Motion could accomplish: 1) Accuracy/precision, 2) turns off until I call it so that I can use my real throttle and joystick without accidently bumping controls. I just built a new PC with the horsepower to run Leap Motion with minimal impact on DCS performance. But I haven't tried it yet, because that was the least of my problems with Leap Motion. If it is integrated into DCS World in a way that surpasses PointCTRL with little or no performance penalty, that would be a great leap forward.

That has not been my experience. I have two of Andre's sim seat pads and both work fine. I haven't had to repair or replace anything yet. When Gametrix went out of business, I bought the 2nd seat to guarantee spare parts to keep the first seat running. But for the time being, both are 100% intact and I have been using them for years.

In another sim, when you hit the limit, the cockpit moves with you, i.e. you don't see any further movement displayed. A checkbox that enables limits but if off by default is the way to deal with motion sickness. Give the option to have limits without removing the option to have no limits, then everyone wins.

I have downloaded VKB software periodically over the years, but when I was trying to download the latest software for a new pc, it got blocked by windows 10. VKBDevCfg (v0.91.95) is identified as having a trojan: Trojan:Win32/Bomitag.D!ml

I have pilot body on by default and keep a switch mapped to toggle it if necessary. I much prefer to have the pilot body when available, but there are time when it is in they way of controls. The way to go on anything like this is to make it a checkbox option and have a toggle button. For some reason, the joystick mapping for toggling the pilot on the UH-1 was commented out. After every patch, I have to make it active again.

I have the Quest 2 and Reverb G2. When my G2 needed to be replaced under warranty, but was gone for 2 months due to supply shortages, I had only one problem flying with the Quest 2: battery life. But upon getting the G2 back, the gain in clarity from the higher resolution with equal or better frame rates was amazing. I have a new PC with a 5800x cpu on a Crosshair VIII Dark Hero motherboard waiting for m2 hard drives that should arrive tomorrow. For the moment, I am stuck with my old 1080 gpu, but I plan to get a 6800 xt or 6900 xt if the supply ever catches up to the demand. I understand I may have issues with the Reverb G2 similar to the problems in the original post. But having seen the difference between the two headsets, I won't give up without a fight. I love the G2's graphics.

I tend to stay away from laptops because I go for upgradeability, air flow, and oversized power supplies, but a top end gaming laptop would make this whole setup so small and light. One more way to make it more portable is to build a custom wooden frame chair that can fold flat. The ability to fit the entire setup into a compact car's back seat or trunk and be able to set it up and take it down in 5 minutes is extremely useful.

F-86: function default_3_position_tumb(hint_,device_,command_,arg_,cycled_,inversed_, arg_value_, arg_limit_,turn_box_) F-5: function default_3_position_tumb(hint_,device_,command_,arg_,cycled_,animation_speed_,inversed_,arg_value_,arg_limit_,turn_box_) They are the same except for the extra "animation_speed_" in the F-5, but look at the calls for the 3-way switch instances: F-86: elements["Rockets_switch"] = default_3_position_tumb( _("Rocket Release Selector Switch, SINGLE/OFF/AUTO"), devices.WEAPON_SYSTEM,device_commands.Button_9, 751, false, nil, nil, nil, {-90,180,0}) F-5: elements["PTR-TMB-LVP-GUM-MSL-CAM-343"] = default_3_position_tumb( _("Guns, Missile and Camera Switch, GUNS MSL & CAMR/OFF/CAMR ONLY"), devices.WEAPONS_CONTROL, weapons_commands.GunsMslCamr, 343, nil, nil, nil, nil, nil, {0,90,0}) I don't know if there is a difference between how "false" and "nil" are decoded, but that is the only difference I see.

Open beta 3-position switch definition for the F-5: function default_3_position_tumb(hint_,device_,command_,arg_,cycled_,animation_speed_,inversed_,arg_value_,arg_limit_,turn_box_) local cycled = false if cycled_ ~= nil then cycled = cycled_ end local animation_speed_ = animation_speed_ or anim_speed_default local arg_value = arg_value_ or 1 local side = {{BOX_SIDE_Z_top},{BOX_SIDE_Z_bottom}} if inversed_ then arg_value = -arg_value side = {{BOX_SIDE_Z_bottom},{BOX_SIDE_Z_top}} end local arg_limit = arg_limit_ or {-1,1} return { class = {class_type.TUMB,class_type.TUMB}, hint = hint_, device = device_, action = {command_,command_}, arg = {arg_,arg_}, arg_value = {-arg_value, arg_value}, arg_lim = {arg_limit,arg_limit}, updatable = true, use_OBB = true, cycle = cycled, animated = {true,true}, animation_speed = {animation_speed_,animation_speed_}, sound = {{SOUND_SW1}}, side = side, turn_box = turn_box_ or nil, } end Open beta 3-position switch definition for the F-86: function default_3_position_tumb(hint_,device_,command_,arg_,cycled_,inversed_, arg_value_, arg_limit_,turn_box_) local cycled = true local arg_limit = arg_limit_ or {-1,1} local arg_value = arg_value_ or 1 local side = {{BOX_SIDE_Z_top},{BOX_SIDE_Z_bottom}} if inversed_ then arg_value = -arg_value side = {{BOX_SIDE_Z_bottom},{BOX_SIDE_Z_top}} end if cycled_ ~= nil then cycled = cycled_ end return { class = {class_type.TUMB,class_type.TUMB}, hint = hint_, device = device_, action = {command_,command_}, arg = {arg_,arg_}, arg_value = {-arg_value, arg_value}, arg_lim = {arg_limit,arg_limit}, updatable = true, use_OBB = true, cycle = cycled, sound = {{SOUND_SW0}, {SOUND_SW0}}, side = side, turn_box = turn_box_ or nil, } end

Open beta red cover definition for the F-5: function default_red_cover(hint_,device_,command_,arg_,animation_speed_,turn_box_) local element = default_2_position_tumb(hint_,device_,command_,arg_,animation_speed_,turn_box_) element.sound = {{SOUND_SW3_CLOSE, SOUND_SW3_OPEN},{SOUND_SW3_CLOSE, SOUND_SW3_OPEN}} element.side = {{BOX_SIDE_Y_bottom},{BOX_SIDE_Z_bottom}} return element end Open beta red cover definition for the F-86: function default_red_cover(hint_, device_, command_, arg_,turn_box_) return { class = {class_type.TUMB,class_type.TUMB}, hint = hint_, device = device_, action = {command_,command_}, arg = {arg_,arg_}, arg_value = {1,-1}, arg_lim = {{0,1},{0,1}}, updatable = true, use_OBB = true, sound = {{SOUND_SW3_CLOSE, SOUND_SW3_OPEN},{SOUND_SW3_CLOSE, SOUND_SW3_OPEN}}, side = {{BOX_SIDE_Y_bottom},{BOX_SIDE_Z_bottom}}, turn_box = turn_box_ or nil, } end

I have compared old and new clickabledata.lua files for the F-86F as well as compared the F-86F to the similar, but fully functional F-5E. What I see is that ED made substantial changes to their scripting of clickable controls. It appears that they have added more parameters. Perhaps when this was done for the F-86, there were typos on all the red switch covers and/or covered switch definitions. For example, here is are old definitions for the F-86: elements["Rockets_switch_cover"] = default_red_cover (_("Rocket Release Selector Switch Cover"), devices.WEAPON_SYSTEM,device_commands.Button_10, 750) elements["Rockets_switch"] = default_3_position_tumb(_("Rocket Release Selector Switch, SINGLE/OFF/AUTO"), devices.WEAPON_SYSTEM,device_commands.Button_9, 751, false) Here are the same elements in the current openbeta F-86: elements["Rockets_switch_cover"] = default_red_cover (_("Rocket Release Selector Switch Cover"), devices.WEAPON_SYSTEM,device_commands.Button_10, 750, {-90,0,0}) elements["Rockets_switch"] = default_3_position_tumb(_("Rocket Release Selector Switch, SINGLE/OFF/AUTO"), devices.WEAPON_SYSTEM,device_commands.Button_9, 751, false, nil, nil, nil, {-90,180,0}) Here is are similar definitions from the open beta F-5: elements["PTR-CVR-LVP-GUM-MSL-CAM-342"] = default_red_cover(_("Guns, Missile and Camera Switch Cover, OPEN/CLOSE"), devices.WEAPONS_CONTROL, weapons_commands.GunsMslCamrCover, 342, nil, {0,90,-90}) elements["PTR-TMB-LVP-GUM-MSL-CAM-343"] = default_3_position_tumb(_("Guns, Missile and Camera Switch, GUNS MSL & CAMR/OFF/CAMR ONLY"), devices.WEAPONS_CONTROL, weapons_commands.GunsMslCamr, 343, nil, nil, nil, nil, nil, {0,90,0})

All it needs is a detachable extension on the base for locking a set of rudder pedals in place at the right distance.

It is nowhere near the top of my list. But if it is done right, I will gladly buy and fly it. I strongly prefer older "steam gauge" aircraft to MFD/AMRAAM era aircraft.

The latest update gets rid of the horrific baked in reflection texture and replaces it with a very transparent texture with just enough dirt to see the glass. This eliminates the need to install a "clean glass" mod, but almost completely eliminates any visible reflection / glare. A great solution for playability but perhaps a disappointment for those that liked the baked in texture. For multiplayer, this is even with the F-86 and much more fair whether it is realistic or not. Maybe it could be more realistic, but overall I find the new default texture to be an improvement over both the old default and the clear glass mod.

The G2's only real strength is resolution/image quality. But owning and using the Oculus family (CV1, Rift S, and Quest 2), it turns out my biggest problems in DCS VR are resolution and image quality and the G2 is a big step above the Quest 2 which is a big step above the Rift S, and the CV1's image quality was so low, I only flew VR 50% or less of the time. I have Onward, a VR FPS game, on both the PC (SteamVR) and Quest 2. While Onward looks so much better on the G2 for clarity, especially for spotting and aiming at distant enemies, its controller tracking performance is just plain bad in comparison to the near-perfect tracking/function of the Quest 2 controllers. What would it take to get a PC VR headset with both the best image quality and the best hardware/software combination? No single PC VR headset I know of is superior across the board. Each model has its tradeoffs. The Quest 2 wins in so many ways: wireless in standalone mode is now practical with the PC if you have a decent modern WiFi6 router. The tracking is great. While the image quality is noticeably inferior to the G2, it is still decent compared to most and at its price level, it really hard to beat. But for DCS, I can only fly so long before I kill the battery and to extend battery life, I would have to ditch the link cable and get a good WiFi6 router. But the G2 looks so much better and generally fits a lot better with much less discomfort over hours of flight. However the G2's lack of a battery life limit is partially canceled out by the tendency of either SteamVR or Window Mixed Reality having a glitch that crashes DCS World. Give me a Quest 2 with the G2's image quality and at least twice the battery life when using the link cable, and I would be pretty darn happy. As much as I would like to try even more VR headsets like the Index and PiMax, I have better things to spend my money on like a new PC and/or GPU.

If you save the current stick profiles, you can drop them into a new install. Whenever you fly a plane for the first time, you load your current profile with the saved profile. This also works if you for any reason have multiple sticks of the same type. DCS will create a separate profile for each one, but as long as you have one good profile of exactly the same type of stick, you can load the good profile to instantly map a new stick.

Ultimately, I want native VR frame rates (90 fps for my G2) AND maxed out graphics quality settings. But if I can't have both, I will take either one. If I could keep the 45 fps I have now and max out quality settings, that would be great.

If you have some basic wood working tools, you can make your own very quickly and easily. I started out making individual blocks, but ended up making a single large piece of scrap wood into a stand for all of my grips.

I have a Reverb G2 and will take any performance increases I can get. I will try this out.

The fact is, many other gryo sights are in the game and work better than the F-86 sight. I understand that some say the in-game sight was programmed for the ballistics of the faster bullets available in Korea while the in-game bullets are the lower velocity WW2 standard. If that is true, that fact alone would make the sight inaccurate, especially as the range increases. I can use the manual gyro sights on the P-51 and MiG-15 with no error when in a steady state and the range is dialed in correctly. The F-86 should work just as well except that I don't have to dial in the range, the radar does it for me, presumably faster and more accurately than I can manually. So, why does is a later, more advanced sight less accurate than earlier gyro sights in this game? If there are documents to show this was the case, I would accept that. But the documents I have read said that the problems with these sights were more of reliability: they failed often and were maintenance intensive. But the pilots who liked them found them very accurate when they working correctly.

I was forced to use the tray tool a long time ago when the failure rate got too high. I have sound cues enabled, so if it crashes, I don't get the cues (i.e. mic click static), then I hear the beep it makes when it first starts up, then I can use it again. I don't have a prompt, it does everything automatically.

Do AMRAAMs kill aircraft with a very high PK? Is anyone piloting them? Can they be lobbed at tremendous ranges? They get midcourse updates, but are autonomous. The aircraft is merely the first stage of a two-stage SAM. If you don't think an F-15 can be automated in the near future to rival if not beat human pilots, you don't understand where the technology is now and where it will be in the very near future. I expect drones will still be manned/monitored, but if jammed, they will at a minimum defend themselves and try to get back into comms range or fly home and depending on the situation may go offensive against their last designated target and/or the source of the jamming. I am not eager to see pilots replaced, but it is a matter of time before the drones, piloted and/or automated, will make up the bulk of the forces. What an AI controlled aircraft needs is cameras / sensors in all directions and the processor power to understand and correlate that information in a way that is comparable and/or superior to human pilots. When it is there it will mix with dogfight AI that was just recently demonstrated to consistently beat the best real pilots in a simulator environment, where the only key difference is that the AI gets fed perfect information for making decisions. I am not in the loop, but I am sure there are some DARPA type people that are much further along with this kind of tech than is publicly admitted. The very old F-15 IFFC/Firefly system was a basic integration of flight controls with fire control. When the pilot pulled the trigger, the gun didn't fire, it gave the computer to fly the aircraft and fire the gun and it worked exceptionally well. Imagine where the tech is now.

I have flown in real life and I drive cars with lots of glass every day in bright sun. Certain angles can make reflections/glare a problem, but at most angles, the reflection is transparent enough that you don't even notice it unless you focus on it. Dogfighting would be impossible if fighters were blinded in such a wide range of angles and lighting conditions. To approach undetected "out of the sun" required careful flying in a very steady position to blind the opponent but not shadow the sun. The MiG-15 has a baked on reflection that becomes opaque much of the time. If that is the "realistic" just like "real life" solution, why don't all of the official ED aircraft have the same problem and not just the MiG-15bis? Why am I not blind in the F-86 which was made in the same time frame by the same group: Belsimtek. Use a consistent technology to get the best result and apply it evenly. The MiG-21 was another aircraft that had a canopy that could hardly be seen through, especially through the gunsight. The MiG-21bis finally got a clear canopy. If it can't be realistic due to game engine limitations, then I will take 100% transparent over 95% opaque every single time.

Burgess Meredith played the F-86 pilot and Lee Majors played the car driver. Despite the low-budget quality and writing, I enjoyed this movie. I loved the actors and the F-86