thank your for your nswer, I will do like you, If I have more info from the developper I will tell you
ditto. as of right now my FFB is just a regular joystick unless iām playing DCS then it comes alive
Hello everybody,
during the developers stream of April 2026, Martial Bossard mentioned that force feedback is already here (also for PC), that the challenge is getting the hardware to speak the sims FF language, because there is no standard for force feedback.
I am a bit puzzled about Martialās answer. There must be some misunderstanding. The USB PID standard is published since 1999. Can somebody please clarify this for me?
Martial also mentioned that they are working with joystick manufacturers on the communication between the sim and the joystick. Where can we find this documented? All of us, makers, that implemented the PID standard in our devices would have no problem implementing the communication between msfs and the joystick. Just please let us know how the protocol looks like.
Best regards,
Cristian.
yeah i dont get this either. DCS world works just fine with all sorts of FFB joysticls. even my old Sidewinder FFB II works perfectly in DCS world.
There must be at least one: Microsoft produced their own force feedback joystick, and very good they were. Other brands of software seem to have no problems with hardware support, including supporting Microsoft hardware.
First of all I do not have a FFB Yoke yet. But my understanding is that f.e. the Brunner FFB Yokes are working already since FS2020.
And on top what I do not understand is what is the difference between FFB Yoke/Stick and f.e. a 3 or 6 DOF Motion Rig?
Am I wrong assuming the motion rig reacting to turbulence should be somehow the same as a FFB Yoke reacting to turbulence? There needs to be a software interpreting the values received from the Sim and translate them into movements.
What is the difference between the two reactions? And why does it seem to be an issue for FFB Yokes but not for motion Rigs?
Sorry if this questions sounds stupid. I am not a developer, no need for a super detailed explanation, I am just curious and would like to understand the underlying principles.
Just as an example in my motion system, I can feel the vibrations of the engine, I can feel the effects of a heli shaking of moving in or out of ETL.
Same for turbulence aso.
As much as I share your wish, I have to disagree with you: FFB in flightsim has never been mainstream; speaking as a 40yrs old (just for perspective). There was not that much hardware available and at quite high prices; and I donāt remember of that much support on the sim side either.
The racing guys is another story; maybe because it was a lot easier to integrate (just one axis, basically, and probably simpler physics) and maybe the market was bigger (?).
There was a time when it was quite affordable and selling well. Itās a shame itās become way more niche and expensive since then. Iād love to dust off my Sidewinder FFB and use it with MSFS, but from everything Iāve read so far, it doesnāt work all that well with the various 3rd party utilities.
I can answer this, i have both
FFB and motion rigs are very different but they both need external software.
Motion software just reads the accelerations and velocities of the aircraft body and moves your cockpit along with that. Any turbulence would come along with acceleration data.
Force Feedback software tell the FFB hardware how much force there is on the control surfaces. In planes thatās the ailerons and elevator, in cars its the steering gear. For games that support it like DCS or most racing games, its possible to not have any external software, as the game sends the standard DirectInput API commands to it.
Imagine a small GA plane. At rest, there is no airflow over the control surfaces, so the stick has free movement. At cruise speed, the air is pushing hard, so it takes more force to deflect the stick.
Currently MSFS does not have any FFB support. That means hardware makers such as Brunner or VPForce need external programs to read the airspeed, density and other sim variables to calculate and change the spring force and center position of the controls. Also these external programs (optional for DCS and other FFB supported games) can mix in acceleration, gear/flap movement, and engine/rotor rpm to provide some more simulated vibration feedback.
Ok, thank you for your reply. Just to confirm I got this right. The benefit of having MS doing the calculations is you could get rid of the external software, at least to some extend.
And you would avoid potential lagging due to a potential delay in communication between MS and the external software.
Correct?
But would you not have to run an external software anyhow that controls the hardware and to make some adjustments? I assume a Boing would require different FFB as an Airbus.
Or a Cessna 172 would need different FFB as f.e. a Skyraider with much bigger control surface.
I mean I do run a external software for my motion rig anyhow. Did I miss something?
The problem is how stick trim forces are generated. Itās rather different between a spring centred stick vs a FFB stick (or real life).
Letās look at the pitch/elevator axis (and in a conventional, aerodynamically stable airplane, like a Cessna 172 for example).
In real life (or with properly im implemented FFB in the sim), pulling back on the stick will always increase the angle of attack/raise the nose. Pushing the stick forward will always decrease angle of attack/lower the nose. If you let go of the stick without trimming, the stick will want to go back to its original position - and so will the airplane (it will eventually return to the orignal angle of attack/pitch attitude). The elevator trim is used to keep the stick in a new position after a change without constantly requiring you to apply a force to hold it there. Thatās where spring centred setups run into a problem as the only position where they will stay on their own is in the centre. So the sim has to trick you when you trim the plane: instead of removing the forces necessary to keep the stick where it is, it will make you move the stick until itās centred.
Example scenario: Slowing a plane down 30 kt while maintaining altitude.
Reality: Reduce power, gradually pull back on the stick, then use elevator trim (nose up) until you can let of the stick and it stays in the new position (farther back than before)
Sim with spring centred stick logic: Reduce power, gradually pull back on the stick, then use elevator trim (nose up) which will raise the nose even further requiring you to ease the stick forward until itās in the centred position where the airplane is now ātrimmedā.
This logic is why native implementation is better: 3rd party FFB programs have to try to reverse engineer the spring logic and bypass it. This will always lead to problems and innacuracies.
I used my favourite MSFFB2 stick (Iāve got three) until quite recently when I switched to a Honeycombe Yoke.
The stick still works very well in the sim just using the ādefault springā setting but it would be fantastic if native ffb support was brought to the sim.
I think the hardware market would explode if they brought it back.
The 3rd party āsolutionsā are a complete waste of time imo.
The benefit of coming directly from the sim is that it might be possible to get direct force measurements on the control surfaces, from all those fancy CFD flow graphics that they show off. Also, if the sim knew a FFB joystick was in use, then the trim axis could be decoupled from the pitch axis and the spring center point could be set directly.
Thereās no worry about lag.
In DCS each plane outputs 100% when the force is whatever maximum the plane developer determines. For MSFS currently, the control surface force is āguessedā with airspeed and density calculations. Obviously with fly-by-wire and hydraulic systems the stick force felt is not what the control surfaces are feeling, so there are parameters for that. When the sim/plane provides the FFB, they would take that into consideration.
External software would then be required to translate the ā100%ā data output into a motor torque; The way VPForce does this is with 2 software components- A firmware configurator (sets gains on motors, and does not need to run in the background) and a live telemetry app. So you could load the firmware profile, set gains, and be done with it. You would need different firmware profiles for each plane, which depending on the strength of your motors and what the dev determined ā100%ā to be, you adjust how it feels with your equipment.
The live telemetry app can switch firmware profiles based on the loaded plane.
For a long time the only FFB device was a Sidewinder, so there didnt need to be much in external configuration software, because everyone had the same thing. But now with new devices having much stronger motors and different extensions, some form of external settings are necessary.
Thank you @smitty9792 and @haslepat, I think I understand now the benefit of having this as a native function implemented in MSFS.
I appreciate your time and effort to explain this to me!
