streakeagle

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

First: hey there! been awhile since we flew together. But the odds of 2.7 fixing a bug that has been unique to the F-86 code for years is unlikely. However, they did do some sound updates, so let's keep our fingers crossed!

When real fighter pilots have dueled simulator pilots in real aircraft using "laser tag" for gun shots, the simulator pilots often beat the professional pilots. Pro pilot training doesn't focus purely on ACM and doesn't provide nearly the hours of practice sim pilot addicts have. As drones supplant manned aircraft, the simulator pilots are going to become the aces of the future when the drone tech provides comparable of superior air superiority options that are not constrained to human pilot limitations. i.e. no only having higher g limits, but also not having to spend weight and space on cockpit provisions.

I have the Warthog F/A-18 grip and have modified with an adapter to use it with the VKB Gunfighter base. I also have the Super Taurus/Super Libra combo because I couldn't buy the throttle separately at the time. I like several aspects of the WinWing Hornet grip over the TM version and could care less about the minor differences in weight and shape. But I didn't use the Super Libra for more than a week or two before putting my preferred VKB Gunfighter base back in service. So, I never encountered any problems with the switches failing or falling off that some people had with the Super Libra. I prefer the feel and functionality of the Super Libra over the TM Warthog, but still find the VKB is still far superior to the feel of the Super Libra. If I had upgraded to the Super Libra before buying a VKB, I probably would have never bought the VKB. If I could get an adapter to use the Super Libra grip on the VKB, I would prefer that grip over the TM Hornet grip. But as it stands now, when I want a Hornet grip, I swap out my MCG Ultimate for the TM Hornet grip with the VKB adapter as well as having the TM Warthog grip available for flying the A-10C and F-16C. I am very spoiled with all of my stick and grip options available, frequently swapping between the MCG Ultimate, F-14, and TM Hornet. I understand that I should be able to adjust the Super Libra to feel a little better and be more comparable to the feel of the VKB. But when I had it open, I didn't see any adjustments that would have reduced or eliminated the feeling and sound of shifting cams as the grip is moved across the center. But given all the grip options I have for the VKB Gunfighter, the Super Libra would have to not only equal, but somehow be significantly superior to make me give up the Gunfighter Mk II (with full Mk III upgrades) and all of the grip options I have available for it.