kablamoman

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

You no longer need the mods. They resolved the problem with the ram air binds and it works normally now.

It's not just the cockpit textures, but they fixed the geometry on the glareshield as well! Phenomenal work!

Seems to illustrate, once again, the problem of decoupling primary controls from pilot input in the manner that they've done with this module for non-FFB joysticks. Some kind of bellows blockage may be being simulated quite accurately in terms of how the feel force is being dynamically altered, but with that feedback sent into the control loop as a layer of stick deflection changes (and thus stab deflection changes) and the pilot being unable to directly interface with the pitch channel in a manner that can override or damp said feedback, the results as posted by OP speak for themselves. Here's the Emergency procedure taken from the flight manual, for reference. Good luck with number 5. Generally agree with you, but I think this statement is a bit of a non sequitur. People don't fly it for other reasons related to asset and DLC requirements, and a general lack of cohesion with the timeframe and assets in the face of pretty strong competition from another title that does those things particularly well. The warbird stuff is generally praised in terms of flight modelling, with very few exceptions (compared to that same competitor). There are a few cases like the aileron/stick center issue with the German birds that I would say come about primarily due to the limitations of modern input peripherals, as you said. Rather than try to alleviate the problem by implementing questionable modeling in software (which introduces its own set of problems, as we've seen with the F-4), they've retained the integrity of the control loop. I fly WW2 more than anything else and would characterize your example as pretty minor in terms of its actual impact when flying, while still acknowledging you're technically 100% correct about it being a real limitation in the sim's interface with home hardware. The real solution is of course FFB that can recenter your real-world stick dynamically and as appropriate.

Without an additional battery pack, only about 2 hours. I use the official “elite” head strap and it provides for an additional 2 for a total of 4 — there are a bunch of third party options that may give you more or less time. I have the link cable as a backup if I ever need power, but so far haven’t used it. The WiFi connection works great (the virtual desktop folks maintain a list of recommended routers on their discord), and many say it features less frequent problems than the link cable with the meta software. Probably a “your mileage may vary” kind of situation, but may be worth giving a shot. The app probably works best with a 4000 series nvidia card, as this allows you to use the AV1 codec (something meta over link doesn’t allow as of yet), for better efficiency/picture quality at lower bitrates.

Another option may simply be to go wireless. Virtual Desktop’s OpenXR runtime (VDXR) coupled with a WiFi 6 (or better) router means you don’t even have to bother with the Oculus software, and you’ll also enjoy not being tethered. For this you’d probably want a head strap with an additional battery, though.

Yeah you have to be pretty light on the brakes. I’m not sure exactly what is breaking but I suspect one of the oleos bottoms out and it ends up registering damage. You get the gear unsafe light and one side ends up sticking down and can’t be retracted, but otherwise seems to work OK and stays deployed.

The problem with the ram air control not working properly when bound to a key press was resolved quite a few updates ago, so you should be all good.

For what it's worth, this seems to be a problem with all of the artificial horizon gauges in the sim. There are fundamental flaws in how the instrument itself has been modelled, that are clearly separate from any suction pressure that may or may not be modelled into the simulated system (though I think looking at how the suction gauge is being modelled so that it provides realistic readings through various engine power ranges is probably a good idea as well). Here's another thread for reference, that examines the issue (a lack of self-righting tendency) a bit closer:

It would be neat if they had generic UI elements for instruments you could toggle on and off, scale, and overlay onto all the different camera views. Maybe one day.

If you pay close attention to whatever you’re using for an attitude reference (some element of the reflex gunsight usually works great for the warbirds), you can see it deviate left or right in yaw with speed, power and roll changes. When you know to look for, and actually see the deviation, it becomes pretty easy and almost second nature to correct. Helps of course to still glance down at the ball just to be sure you’re coordinated initially, so you know where exactly to hold it, but with a bit of practice you can do a surprisingly good job of flying with zero sideslip just by looking out the front. You can also use the k14 pipper (keep the lead computing element in line vertically with the static center reference) for a bit of extra help, too. I would recommend more focus be given to these techniques, rather than over-reliance on the inclinometer. I know it wasn’t quite the question being asked, but figured it may help some as it’s related.

This is the crux of the issue. In the non-FFB implementation every return to neutral is treated as if the virtual pilot has simply let go of the stick when it's returned to your physical axis center. In the video, the physical stick was held in place, and not allowed to "bounce", but the virtual response is as if it was. There is no way to "ease" your stick back as you would in real life, supporting the increased load of the stick until back at the trimmed stab position. Try as you might with your physical joystick, the simulation does not allow for it, and the stick, stab, and airplane along with it will bounce a bit in pitch before settling with every change in load. Conversely, the FFB implementation, as I understand it, allows for proper grip of the stick and thus control of the aircraft. This is also the reason for the strange "wet noodle" behavior of the stick when simply trimming, or when the stick is "dead" due to nil airflow to the bellows, as when you are on the ground or at very low speed. The simulation pilot essentially neglects to hold the stick where it's commanded, despite control forces being negligible. They did not mention that they made these pretty important (and wrong in my estimation) assumptions when telling the gentleman in this thread that it is "100% correct and intended" behavior in response to his obvious confusion. I'd really love to hear how you think I'm spreading misinformation. Any user can see the exact behavior I am talking about themselves by simply pulling and neutralizing the stick in the external camera, while they watch the stab wiggle all over the place. It is unfortunate that you seem to think I am pointing these things out in bad faith -- quite the contrary: I would love to see the module improve substantially in its non-FFB stick simulation. If you could put in a good word for me with Steam Support, I'd appreciate it, as I've already tried 3 times for a return (with the full intention to re-purchase if these problems are ever addressed).

How is it trollish to point out that the behavior of the aircraft is obviously showing that the stab and the stick are not under direct control of the pilot in the non-FFB implementation? The virtual pilot releases grip strength and allows the stick/stab, and thus the entire aircraft to oscillate freely about the neutral point in pitch. You guys keep asserting that the effect is only a visual artifact of the stick animation, but it is clearly not. I believe it is a pretty severe oversight. I paid for the module just like everybody else posting in the bug forum with feedback and suggestions.

squiggle.mp4 As depicted on the chart, we see this exact same oscillatory behavior on the aircraft itself when returning the stick to neutral:

What a coincidence then, that the stab and aircraft attitude bounce around and oscillate along with it -- not to mention the fact that the folks with FFB setups can easily control this behavior by simply gripping the stick and holding it in place.

Have you tried asking for help on the Virtual Desktop discord? This is their primary means of providing support. With regards to your first question: Quest 2/Pico Neo 3/Quest Pro/Quest 3 Potato: 1440x1536 Low: 1728x1824 Medium: 2016x2112 High: 2496x2592 Ultra: 2688x2784 Godlike: 3072x3216 (Quest Pro/Quest 3) I'm not much help for the second question, as I have yet to use the link cable myself. There is a new beta version of Virtual Desktop and the streamer app -- perhaps they are worth a try?

And made that much worse because Heatblur thought we shouldn't be able to hold the stick in place (you know, fly the plane by manipulating the controls) unless we have FFB hardware:

Probably won’t help a ton, but I do know that it’s definitely worse with just h264 (the banding gets more prominent). Sadly, it’s there even on the headsets I’ve used with display port, so I don’t think you’ll ever get rid of it.

It’s a side effect of insufficient color depth (8bit color) to render the smooth gradient. I’d you’re using virtual desktop you may find that if you encode with HEVC or AV1 (which use 10 bits) it may slightly reduce the effect. Sadly, because DCS renders in native 8bit color it’ll never completely resolve it. I get the best results (for eliminating this kind of color banding) on my quest 3 with AV1 and godlike mode, with “snap dragon super resolution” and “increase color vibrance” checked. I think the quest’s onboard chip may do some additional processing to the image that may dither or smooth out the banding a bit at those settings.

They’ve mentioned in other threads it’s a known issue and they’re working on options to improve it. It sounds like they’ve got a smoothing filter on the movements that interpolates between polled positions of the pilot head so you get a better animation. This necessarily introduces latency. They’ve talked about adding a mode that doesn’t interpolate and so would be a more instantaneous response, but at the cost of being a bit less smooth. All this to say, not to worry it has nothing to do with your system.

I see what you mean. Were you referencing maksim’s video on the ground when talking about spikes? I think that’s just the surface noise simulation being used on the ground to simulate roughness (not sure if it’s all maps) — I know ED was running into a problem with their new tire physics where smaller tail wheels were interacting with it adversely resulting in some erratic responses (bunch of crazy bouncing as the mosquito tail wheel ran along the surface). In the video it looked like it had a similar effect on the bobweight of the stick and it was going crazy in the absence of the bellows force or the limp pilot arm to balance or dampen its reaction.