kablamoman

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).

Watch the video at timestamp.

Not sure if you missed the debate, but this has been brought up a lot, with 9L often taking issue with the assertion that wings detaching was a common outcome. You can look yourself at all the readily available guncam footage, and I have to say I tend to agree with him, as wings and structural elements are rarely separated unless there's some kind of ammo explosion (there are several guncams featuring FW-190s seemingly hit in the ammo storage, leading to wing-snapping explosions). Most guncams depict damage to oil and rad coolers, lines and hoses, with the resultant streaming fluids, or fuel tank/drop tank explosions and fires. It's relatively rare to see wings snapping -- go ahead and look for yourself. Where I think they can improve the most would be more dynamic and varied fuel fires (with progressive damage or explosion), ammo explosions, and perhaps a review and QA check of their pilot damage calculations, as it seems really rare for in-game pilots to get shot up even if the cockpit area gets raked thoroughly with incoming fire.

There's no question there's tons of room for improvement with the damage modeling, but ED have shown several times in the forums here that damage to wing struts is in fact modeled, and to quite a high fidelity indeed. Each strut has its own damage value, but it takes quite accurate and sustained fire from .50s to damage them to the point where they actually break. It does account for structural weakness and can fail if they become somewhat weakened by battle damage and then are subsequently put under load. I wish I could find the forum posts, as they had some really cool screenshots of their internal development tools for debugging the damage modelling. What they have really is pretty impressive, and I wish they would add to and expound upon it a bit more.

AV1 may be more limited in terms of processing latency. I think that may be why it's limited to a lower value. Could be that the SOC in the Q3 may be taxed a bit too much if the bitrate gets much higher. I wouldn't mind being able to eke out a bit more, myself, as down low to the ground it seems the codec (at 200 Mbps) starts to struggle to retain finer details with all the grass, tree and ground textures overloading it with detail, even at 72hz. I would rather not use H264+ as it brings with it more noticeable color banding with the color gradients (especially noticeable in the sky when looking up to the darker portions).

I do feel that the oleos have a bit too much give. Admittedly, though, the feeling isn't based on anything concrete, aside from it being pretty easy to damage the gear (presumably because they can bottom out a little too easily). If you ever find yourself taxiing, rolling out from a landing, or taking off, and have the gear warning horn suddenly sound -- congratulations, you've busted one of the mains.

@Victory205 Great video, thanks for sharing!

You don't fly coordinated solely by feel. There's a visual element to it as well (ie. rolling around a reference point) that with a bit of practice works really well in most DCS modules, just as it does in real life. Seat of the pants feel helps, as does becoming familiar with the required control pressures (pedal being coordinated with stick pressure and/or power changes), but if you're flying with proper technique and paying attention to your attitude and reference point, you can absolutely maintain coordination without using the ball in the sim, just as you would in real life flying.

My progression: HTC Vive -> Valve Index -> Bigscreen Beyond -> Quest 3 Quest 3 is definitely the best of the bunch, although lack of direct DP connection does hurt it a little. I think to make it competitive requires a good head strap and wireless via Virtual Desktop, which does mean added cost for the strap (and additional battery) and potentially network hardware to get you up to WiFi 6E standards. At that point you may want to look at the Pimax Crystal Light as the price difference won’t be that substantial.

@mbucchia thanks so much for all the hard work and innovation you’ve shared with the VR community over the years. For anybody looking to get set up with Virtual Desktop, visiting the VD discord is highly recommended: https://discord.gg/9tq9snWV A lot of information there to answer any questions you may have, as well as a list of known-good network hardware if you find yourself needing a new router or access point to get the best experience.

It sure would be nice if they could finally take a look at some of these warbird issues.

Would be great if they could take a look at this and really clean it up, as they've done such a great job otherwise.

Just experienced the new effect in the sim for the first time in the warbirds. Woof. I think it needs another look. It's not so bad when stationary and is pretty true to life, but as soon as you start to pick up speed it should start clearing off with the faster slip stream pretty quick. The effect we have now makes it look like the water has the viscosity of an oil, and even if you're flying over 300 knots it slowly moves back over the windscreen like it's molasses. On canopies with multiple sections the direction of the water flow doesn't line up either, and it will often be moving at what looks like 90 degrees opposed to the portion of the canopy on the other side of a frame. I think there needs to be way more variation in speed of the flow over the canopy, with the warping effect clearing off as the aircraft speeds up, trading off the shader warping effect for more impact effects. Unless it's a torrential downpour, even getting up to speed on the runway for takeoff should clear off the majority of it, with the water streaking slowing and collecting around canopy edges on the sides where the local airflow may stagnate a bit. The effect we have now would be more appropriate for catastrophic damage spraying engine oil all over the windscreen. Needs a revision pretty badly.

Just confirming that "Stores 2 SELECT" should be the proper bind, as @R.MES mentioned. Important to note that your CNM switch must be set to the neutral position (you can't have cannon or magic selected), otherwise it will override your 530 selection -- perhaps this is why you thought it wasn't working?

I have a center-mounted 20cm extension already but without FFB the F-4 stick simulation Heatblur has given us is completely broken. As others have pointed out quite accurately it behaves as if we are not interfacing with the control column at the stick, but as if we are reaching through the floor and applying force at some point behind the spring that couples the trim actuator to the stick. I am not necessarily against adding stick weight limits to total deflection or rate of deflection (as the 47 and 109 already model) and definitely agree that the F-5 wing snapping debacle was a problem. Those particular elements of the F-4 implementation I do not have a problem with (although I would prefer to fly without the stick force blending option, which when active, behaves somewhat similarly to IL-2). The problem is the assumption that a centered spring stick ends up meaning no grip at all. The stab is free to oscillate all over the place. I have got my name on the list for a Rhino and will look forward to trying other FFB hardware as well once they hit the market, but for now the non-FFB implementation of the stick in the F-4E is problematic at best, downright broken at worst (in my opinion).

Disagree with a lot of this, but not really the forum section to dig deep. Suffice to say that I would contend torque, gyroscopic and p-factor effects are there in spades (especially compared to the other sim). Prop wash is also present, with the ability to raise the tail off the ground at high power even when stationary on the ground. Whether these are hacked in effects, or part of a more robust simulation, I do not know. Ground handling itself is also much better than other titles, although I have some reservations about the spongy oleos in the new P-51 suspension implementation. I do acknowledge that it doesn't seem like control reversal with airflow reversal in a tail slide is modeled much, if at all, but you absolutely do spin like a top once you're near zero airspeed in a prop hang. I also question the lack of adverse yaw modelled in many of the warbirds (though it seems very present in the P-47). If you do have some input about the FMs, I think it would be great to post in the WW2 forum. I would love to see Yo-Yo address the handling in the tail slide, personally, and would find it very interesting if he engaged on some of the other points you mentioned. I really do think the comment about the FM is a non sequitur. Almost universally, other issues unrelated to the flight modelling are cited as reasons for preferring other titles. It is generally acknowledged, even by hardcore fans of the other sim, that the DCS warbird FMs are modelled with a much greater degree of fidelity and accuracy. With a fair bit of real-world experience flying, I certainly feel DCS' warbird offerings are modelled much more accurately than its main competitor (though as with any other internet random, feel free to take that opinion with a grain of salt).