Number481

I will agree and disagree with everyone in this thread *Saturation* (axis scaling) should not be hard to implement. It's supported in the Rhino telemetry software for the "Civilian sims" where the entire FFB implementation is handled by the application. *Curves* are a whole other animal. This doesn't bother me though since I generally believe curves are bad. Most people who are using curves should be using saturation/scaling instead. The fundamental issue here though is that there is zero relationship in DCS between the axis x/y and the FFB x/y. When you invert an axis, the "ffb stack" has no idea, so forces would be backwards until you also invert the "FFTune" for the same axis. When you set up saturation on the axis, you've essentially made the full physical range of the axis only produce some % of the virtual range... but the "FFB stack" still thinks its %100 stop to stop @Havner, I can show you a trick using the configurator software to produce a "saturation" of sorts. In configurator, simply manually increase the calibrated range the same amount both on the upper and lower ends of the range. For example, if your calibrated range was 1275 - 3000, you could manually increase the range by 200 on either side (1075 - 3200). This would cause the full physical deflection to only account for roughly %80 virtual deflection. *Edit* I'll add that you can dynamically push profiles to the device based on the aircraft you load into (using TelemFFB), so you could do this on the Apache, but not for others if you wanted.

As the guys said, it is working fine. Trimmer mode set to default, trim control bound in the settings. Initially there was no support so you needed to use hardware trim either in configurator or TelemFFB. With this last update (or maybe the one before? I wasn't paying attention), they added native support. Make sure you don't still have "sticky spring" (in configurator) or the spring override (in TelemFFB) enabled.

The only way is to *not* bind the trim button in the game (it only understands sprung joystick logic) and then use either the hardware trim in configurator or, if you are using it, the hardware trim in TelemFFB. If you have the trim button bound in the game it will double the inputs since it expects the joystick to be sprung and thinks you are going to let the stick go back to center after you have pushed the trim button.

TelemFFB to the rescue... null @Hiob, there's already a built-in profile in the current version of TelemFFB.

When the sim lacks direct telemetry for something (like afterburner actuation), this is when you have to dive into the world of looking at the model draw arguments (the objects that control the external visual rendering of the aircraft). *Most* aircraft use a common set of arguments for the afterburner... Though I can't say with certainty whether it is always 28=Right and 29=Left local AB_Right = LoGetAircraftDrawArgumentValue(28) local AB_Left = LoGetAircraftDrawArgumentValue(29) Value(s) will be 0.0 with no afterburner and 1.0 with full afterburner. As soon as either value comes off of 0.0, the afterburner is lit for that engine. You can open an aircraft in the model viewer and play with the slider for those arguments. You will see the afterburner visual model react as you would in the sim when in external view. null For single engine aircraft, you'll have to determine which value is actually used. The F-16 is '29', the Mirage-F1 is '28'. There's actually quite a bit if data you can source from the draw arguments (and the main panel arguments).. these are the hoops we must jump through to get at the data.

Your correct that the offset changes when returning to center, but that is in response to the unloading of the g forces. The center also moves when you load up the Gs, which is what causes the force to appear to increase. I don't know what monitoring capabilities you have with your stick, but pay attention to the center offset for the spring effect (ID:5) in this short clip. As I pull in the turn, you see the offset shift farther negative (forward) the harder I pull. When I return to center, the offset moves back towards natural center again. My point was that the oscillations occur because it is too sensitive with minor fluctuations in the G forces around 1G. There needs to be some sort of non linear factor applied to the force such that the generated offset between 1-2G is significantly less than the offset generated between 2-3 or 3-4.. that would eliminate a lot of the wobbly feeling around center. F4_bobweight_effect.mp4

Its not incomprehensible if you think about it, HB just needs to add some dampening/hysteresis to the center offset calculations around 1G to cut out some of the oscillations. . The shifting center is a mechanism to simulate the stick becoming heavier with G-loading. In general it works quite well, better than using constant force to achieve the same G-loading effect. The harder you pull, the further away it moves the center point, which has the effect of increasing the force you need to hold the stick in its current position. If you fling and let go the stick, yeah, it oscillates as the stick moves in response to the centerpoint offset changing, then overshoots, then tries to react to the centerpoint offset over-reacting because the stick overshot its center position due to inerta....

I'm new to the P-47 and this campaign. I've read the guidance on climbing with AI and can manage to (mostly) keep up during the initial climb. The problem I'm having is that after reaching cruising altitude, the AI never seems to reduce their unrealistic power settings. Mission 1, which I am still stuck on, the whole AI fleet is balls-to-the-wall all the way until the relief flight shows up. I can climb (mostly) with my flight up to altitude and be within range of catching up, but even if I leave the aircraft at 52/2700, cowl flaps closed, oil/turbo coolers neutral, cruising at 250mph IAS, the AI flights still outpace me. Occasionally I can close some of the distance if I under cut one of their turns, but as soon as I turn back to following, they outpace me once again. I've watched videos that are a couple years old of the flight in this mission where it seems the player is keeping up just fine wile cruising around 200mph IAS. Once the relief flight shows up and our flight heads off to RTB, it seems everyone slows down to a reasonable cruise speed and I am able to catch up. Of course by that time I am so low on fuel that I won't be able to make it home.

Keys are stored in registry.. you can modify most stuff via CLI.. https://mbucchia.github.io/OpenXR-Toolkit/cli.html

IMHO, the focus/peripheral blending is better. And, you have more control over the size and resolutions of each zone. But, unless you want/need to run additional OpenXR layers that conflict with native quad-view (like Toolkit or OBSMirror), or if you want to play other quad-view enabled titles, there is little other reason to migrate over today.

No worries dude. My original message was smart-a**ish in the first place. There’s so many many moving parts it’s hard to keep track of. I also admit that with QVFR being a more generic implementation than Varjo-Foveated, there is far more documentation to look through.

Its not though.. what you are experiencing is the g-force effects interaction with the lens effect... null

Apparently nobody reads anymore... https://github.com/mbucchia/Quad-Views-Foveated/wiki#dcs-world

If you can source a sheet of this microsuction "tape", it works really really well for sticking your pedals to a hard-surface floor. It's not tape at all, rather a microscopic suction cup surface that adheres like tape but is easy to remove/replace/clean and leaves no residue. It's the same stuff that Honeycomb uses on their mounts for the Alpha/Bravo controls, if you are familiar with that.. https://sewelldirect.com/products/airstick-microsuction-tape?variant=15164885270574 Amazon (US at least) has it, or you can try direct from Sewell

How handy are you? G2 speaker adapter: https://www.thingiverse.com/thing:5238887 And a remix of the above for the Index speakers: https://www.thingiverse.com/thing:5634650

Its normal for people not to like things they don't understand. OpenXR is a standard. OpenVR is a standard. SteamVR is an application. SteamVR supports both OpenXR and OpenVR. OpenXR Toolkit is a .... Toolkit. Written by a community member to enable users to tweak and tune and optimize to their hearts content. In no way, shape or form is it required.

@YumaThe issue is that DCS is applying effects to the focus view the same as it is applying them to the peripheral view, and the same as it would if it were applying them to just stereo view. This is a no-no per the Varjo SDK documentation and is the same reason that effects like Bloom and Lens Effects also mess with the focus display. https://developer.varjo.com/docs/get-started/Post-processing You can set Render Mode = 0, which will remove the effect entirely, but you can't only remove it for just the focus area. Just for @tacca's edification.. this has nothing to do with your mod. This is the 'issue' being referenced. null

I think you're over thinking it.. literally just turn the override resolution flag in OpenXR toolkit to OFF... then you're right back to what is set in VB (the next time you launch DCS). If you want to delete the value you have currently set when override is turned on.. delete the following entry from the registry settings for DCS Computer\HKEY_CURRENT_USER\Software\OpenXR_Toolkit\DCS World - 'resolution_height'

nullhttps://varjo.com/use-center/get-to-know-your-headset/getting-the-perfect-image-quality/ That's because you are "overriding it".. it is ignoring what VB is trying to use

Re-reading your message, I think I misunderstood what you're asking.. but I'll leave the below intact as well.. OpenXR Toolkit doesn't care what PPD VB is set to.. Whatever you set in VB is what you are going to get in the headset. *UNLESS* you override the resolution in OpenXR toolkit (this is not enabled by default, in which case OpenXR toolkit plays no part in the final resolution in the headset) Previous reply ~~~~~~~~~~~~~~~~~ Varjo Base still controls the resolution ('High', 'Highest', etc..) and you can see the actual peripheral and focus region resolutions listed in VB when you pick one of those presets. The peripheral and focal multipliers in the configuration file for the DFR layer is exactly that, a multiplier of the listed resolution in VB. If the resolution listed in VB when you set 'Very High' is 1140x1140 1908x1632, and you set both multipliers to 2.0 (dont do that though!). You would see VB report the resolutions as 2280x2280 3816x3264 once you start DCS Leaving the config file at 1 and 1 for peripheral and focal will give you the resolutions shown in VB by default for any given PPD setting

+100... I've tried all permutations of settings I can think of.... No mods MT Lighting.mp4

It's not just Caucases... here's a recording from a campaign mission in Syria Potato quality for upload size limit.... MT Lighting.mp4

Can you look to see what your \HKEY_CURRENT_USER\Software\OpenXR_Toolkit\DCS World registry setting looks like? If the nuke worked, it should be virtually empty (2 or 3 settings tops). If it is still full of settings, then it didn't reset properly.

Its even more noticeable in the headset Now, I don't want to give the impression that Tacview is this problematic across the board. It's really only an issue in cases with a lot going on. In a normal free flight scenario, or even on the Supercarrier PG cold start built in mission, I don't see a difference with Tacview enabled. Same goes for the 7905x -> X3D comparison. The more assets on the map, the bigger the performance improvement I got. But, in general free-flight, the X3D is pretty much on par with the X.

It probably varies based on the CPU, but you are right... 15 or even 20FPS when you're talking in the range of 180+FPS is not much of a penalty. However, I exclusively fly in VR. Even with the X3D and 4090, there are still situations that bring the system to its knees. There is one campaign (Operation Cerberus North) that is an absolute killer for me. Starting on the ground in Syria with a crap load of ground assets on the map is a painful experience. This is a 30 second capture in VR, just sitting cold and dark in the hangar at the beginning of one of the missions. You can see a test I ran with the 7950x before I upgraded for comparison (I never tested with Tacview disabled before the swap). I can assure you the ~15fps in this case makes an enormous difference.