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