kablamoman

Aside from a select few to whom they’ve shipped some preview versions of the headset, I don’t think it’s been shipped out to customers yet. I think I’m supposed to have the one I ordered shipped out in June. I think the YouTube channel Voodoo DE VR included an FOV comparison in his early preview (included for comparison were his same results in the original BSB along with Q3 and Pimax numbers). Might be worth looking up if you’re curious.

Happy flying! I enjoyed the conversation and reading your posts! if you ever find yourself looking for a replacement for the x-52, VKB controllers gladiator series are pretty widely regarded as the best bang for the buck, it doesn’t have a dedicated throttle though (just a slider).

Then I misunderstood! I read your original post and took it to mean you were veering to the left prior to becoming airborne. Sorry about that!

Just to be clear, if you experience left yaw when you pitch forward to lift the tail in your takeoff roll this is gyroscopic precession. Pitching forward/lifting the tail would actually reduce the contribution of p-factor in this instance — resulting in a right turning tendency — as you are reducing the disparity of AoA and speed that the blades are experiencing between the left and right sides of the propeller disk compared to the more nose up three-point attitude. I am curious, are you maintaining a three-point attitude for the entirety of your takeoff roll? If so, I would suggest you transition to a more nose-low takeoff attitude earlier in your roll and work on maintaining directional control through that transition by easing the nose down smoothly and deliberately, with an appropriate amount of right rudder to compensate. The aircraft should lift off on its own in this attitude, and there should be very little contribution from p-factor for the remainder of your takeoff.

Hello friend, Have you ruled out the possibility that there is some other cause for the result that you're seeing? I do not find that P-factor is a significant contribution to left turning tendency in any of the warbirds in the sim. Nor should it be, really: Significant p-factor requires a higher relative airspeed than what you would typically see in the initial stages of the takeoff roll, coupled with a high angle of attack -- but once you've built up such speed, you're typically no longer at a sufficiently high angle of attack (assuming you are raising the tail) that the speed differential between the down-going and up-going (retreating) blades is enough to cause significant asymmetric disk loading. In the initial takeoff roll, the effects from the helical propwash should and do dominate, but not to the extent that it should overwhelm directional control with rudder, assuming your tailwheel is straight and locked. Have you confirmed your tailwheel is locked? Perhaps there is an issue with the control mappings of your rudder axis? Sometimes there can be double binds from other devices. There are also special options for each warbird module for "auto-rudder" and "takeoff assistance" in the main menu options you can double-check to make sure they are disabled and aren't interfering. As you pick up speed in the takeoff roll the next big left turning tendency would be from the gyroscopic precession when you lift the tail off the ground with forward stick. If this is the point at which you start to lose control and veer off the runway to the left, try easing the nose down a little more gradually so you have plenty of opportunity to react and correct with right rudder. It sounds like you should have a firm grasp on pilot technique based on your background, so I've included advice regarding technique for others that may be curious, but sometimes the "simisms" catch the best of us, so I would encourage you to double-check the tailwheel lock, special options, and control bindings. Keep in mind that many folks fly the module every day without running into the problem you mention, many of them also pilots in real life, either for pleasure or as their day jobs. Hope this helps!

Yes.

I believe so, but depending on the version of Vive they could be the older 1.0 base stations, which would limit you to a maximum of two in your room set up.

Each lighthouse is a self-contained little box you mount on a wall, ceiling, or even just put somewhere in the room. It requires only a power cable to an electrical outlet, and no data connection to your computer. It basically floods the room in IR light (works in the dark), that the headset uses to tell where it is in 3D space (it’s still inside-out tracking). Tracking with just one lighthouse is good, but you can add additional units seamlessly and it’ll allow for even more accurate positional calculations, and also make it less prone to occlusion. For the Beyond, as its surface area does not protrude beyond the sides of your face, like say, the Index, it is a good idea to have at least two lighthouses with at least one positioned some where behind, as you will be checking six and your head itself may block line of sight to the base stations. I personally noticed this being an issue with the BSB (when it wasn’t previously with my Index), but a reposition of the lighthouses resolved it. I moved on to a Q3 after problems with the first BSB’s optical stack turned out to be DCS deal breakers for me, and one of the things I really miss is the light house tracking (which really can’t be beat), in addition to the dedicated DP connection. Looking forward to giving the BSB 2 a go, as a lot of the reviews are saying the edge-to-edge clarity rivals that of the Q3! If so, I foresee my Q3 collecting a lot of dust.

@Aapje As mentioned by @actually_fred, every headset uses its own software to interface with the PC at the device driver level. Bigscreen, as it’s already using lighthouse hardware for tracking, has chosen to use Steam VR because a lot of the software-hardware interface work has already been done — and to a very high level of quality! OpenXR support is something that, in turn, interfaces with that software. Steam VR features native OpenXR support in the same way it has/had native OpenVR support. Headsets native to SteamVR have the benefit of a well maintained software suite on all fronts, especially compared to some of the smaller vendors, as was mentioned. You seem to be conflating the SteamVR interface with its older legacy OpenVR API and runtime, which, for non-steam VR/OpenVR headsets like the G2 or oculus headsets, presented the problem of basic compatibility and also performance because those headsets themselves had poor implementations of their OpenVR support. Open Composite was a wrapper that translated API calls to their native runtimes — but did not offer any kind of performance benefit for headsets that were already SteamVR native like the Index or old Vive headsets. The same holds true for the Beyond headsets, which use the Steam VR driver/interface, and which can use its native OpenXR support without the need for any kind of software wrapper, and so there is no negative performance impact. Once again, Fred has also demonstrated with an example of his personal experience as a dev and working through support channels, that Valve is one of the most responsive and engaged supporters of the OpenXR standard. If your reticence to the idea of “Steam VR” is borne out of your experience with a G2 or Oculus headset, I would appreciate you being up front about that, being open to learning a bit about why the same problems don’t hold true for native Steam VR HMDs, and to stop spreading misinformation.

@Aapje The user above did a pretty good job of explaining to you that Steam VR headsets like Index and Bigscreen’s offerings already run OpenXR natively. It’s not like using it with a Reverb G2 or an Oculus headset. If that is your experience and the reason for your comments, it may be understandable if you think SteamVR automatically means some kind of performance hit or less than ideal experience. Despite your misgivings Valve has proven to be a pretty good steward, and the very OpenXR support you’re calling for is already there and a direct result of their dedication and continued attention to PC VR. The experience with Steam VR and the Beyond is honestly pretty hassle-free and straight forward.

The 109 stick travel is limited by control loads at higher speeds, because of this you cannot as easily accelerate stall. Its slats also help. The 190s retain their elevator authority even at higher speeds, so you can pull enough to exceed the critical angle of attack, even if you’re going very fast. Stalling the wing is not a function of airspeed, though it is correlated. It is more properly a function of angle of attack. You must learn to fly with smaller deflections of the stick. I would suggest changing the curve value instead of saturation as you will achieve the same effect, while retaining full elevator authority. The take off flap setting on the 190 will also achieve a similar effect to the slats on the 109 and will help delay onset of the stall if you’re pulling too hard.

Doesn't really sound like compression artifacts to me, but hard to say without seeing it. The compression problems I notice, at least when using AV1, is that when the image gets a bit too detailed for the bitrate, you start to lose finer details, and textures start to look blotchy and blurry, or otherwise "softer" than normal, and you will even start to lose a bit of color in the scene. I tend to notice it most when flying at high speed just over the ground, with the grass and trees flying by -- sometimes the compression can't quite keep up, and tree textures become blotchy and the grass starts to blur lose a bit of its color.

Might be related — there’s been talk that the altimeter has been broken in the latest update. So it’s possible the indication on the gauge you see when it switches is an error. You could double check with the info bar to see the actual altitude.

Except when it involves holding the stick firmly in Heatblur's F-4E, apparently. Can't do much with the limp noodle arms they've given us all.

These were pulls of the stick, meant to show that when returned to center, the virtual pilot’s arm has been modelled in such a way that it’s as if they are letting go of the stick entirely (in the non-FFB stick implementation). This results in the stick and stab rebounding and oscillating around the trim neutral point, as if the pilot’s arm isn’t itself part of the system and there to damp it. To be clear, I had no problem with the coarse actuation of the trim last time I tried it, and the aircraft I fly currently requires similar, short clicks of the trim switch for fine adjustments. I think it’s smart of them to add an option for fine tuning the actuation duration for each command, as some joystick software may be holding the input longer than the physical press of their real-life switches. The point of my post in here was to point out that there are other more fundamental problems with the way they’ve decided to model the stick response in pitch that underlie the system and may make it seem extra sloppy when trying to trim. Indeed, you will see it wobble a bit with every change in pitch even when trimming — this may be accurate behavior if one makes the assumption that the pilot is flying hands off or with fingertip pressure, but not if they’re actually gripping the stick. The devs seem to have assumed that whenever your non-FFB stick is centered that you don’t want to apply any grip pressure to actually fly the plane, whether trimming for level flight (the nose bobbling up and down a bit could be considered a minor annoyance when trying to trim), or aggressively maneuvering (more of a problem, as shown in the video).