FlyPT Mover 3.7

Yes right, the yaw, pitch and roll will not be coherent with the motion compensation if you use the Logistic filter on the actuators.

Nevertheless if I understand the concept of the pre-follow feature, It could maybe exponentially go off as you approach the edges. It it’s a linear scaling (missmatch in the center position as well), I can’t see what benefit we can get out of it. For sure I am missing some information.

I strongly doubt what you’re claiming now.
I am not talking using logistics on actuators but on the dofs in the pose modules

Avoids abrupt stops when actuators reach the limit for high speed actuators

Ok

https://www.xsimulator.net/community/goto/post?id=250673#post-250673

Watch this:
Pre-Follow 0.5. Motion is stopped although the actuators didn’t reach their limits:

@Marco Annunziata and @hexpod ,

How the motion alghorithms work:

#1 Keep moving actuators with available range
The rig tries to acomplish the desired pose. If the actuators are out of rang they stop at the limit, but others keep moving.
This way Mover doesn't know the rig real pose and keeps sending the desired pose to the motion compensation (big problem here)

#2 Stay on last good pose with transition
When one actuator goes out of range or the rig is in risk of singularity, she stops moving.
When she goes back to a pose inside it's the limits she moves to that pose with a transition to avoid sudden jumps (ok, there's a bug there causing some problems - related to transition reset)

#3 Follow pretended pose
We have a pretended pose (the pose we request) and the real rig pose.
In #1 it would be 1:1 but when out of range, I don't know the real rig pose
In #2, I know the real rig pose, but she stops moving when out of range
So here in #3 what I do is reduce the rig movement in all the dof's until she's on the limits. This causes an effect of following the pretended pose.
The parameter I have is there to allow this effect to start sooner. For example with just heave and a value of zero when out of range the rig has almost no movement. If you increase the value the rig decelarates sooner giving you a sensation of more range.
But this also induces false cues since it affects all dof's not only the one changing.
We can say, the far we want the pose slower the motion like a logistic.

Conclusion, none is perfect, the ideal is to use poses that you are sure they never reach the limits.
Alghorithms #2 and #3 are slower compared to #1 (iteration for a valid pose)

Using filters in the actuators directlly, causes the same problem of #1, we don't know the resulting pose.
To avoid the problem of fast actuators reaching limits to fast, the better solution is to use #3, it's like a logistic on the rig (all poses simultaneouslly).

Yes, values to big cause that effect, it should be a max of 0.25 maybe less
Try 0.1

Or maybe you are already out of range

Was waiting for that one.
So, there where to many fields... In my mind let's remove it because that way they use the filters and can put a crop with different values for both sides.
I did it because the idea is to achieve a rig setup and don't touch it much, specially on the limits.

But if you think it's better to bring them back, ideal is to have 12 fields, one minimum and one maximum.
Got asked multiple times for different values there.
If they come back it's a popup window or the UI goes crazy.

I’ll go to the monastery and think about it for 7 days before I open it again.

Don't, I was there for a long time and came more confused ...
Those transitions in #2 are making me crazy, I'm looking at the code right now and see what I might have changed...


Oh, MSFS is solved, but for now with the dll next ot the exe

Take it easy. You corrected this once and it was bulletproof, (too bad you didn’t saved this branch). so there is no reason you can’t do it again. Leave it for later.

I think with the new safety fence for interference with a volume the issue of limiting my rig in the rig module is greatly diminished so I would have no real need for that going forward. Additionally I can do the crop filter to accomplish the same so I would say leave it off the UI for now.

I would look rather for what you already added but took another build for development. - not for you might have changed.

Mover 3.7.0.1

Download link in the first post of this thread.


iRacing (new source)


KayakVR (new source still WIP)

Please enable telemetry in the game menus.

Zusi 3 (new source still causing some problems - it's a train sim)

To enable telemetry, on the Zusi3 menu do:
Configuration -> Settings -> Sending interval
Increase the frequency by lowering the value (0.001 is 100Hz - Zusi3 never reaches such value but will get maximum frequency).
Also check to autostart the server.

MSFS 2020
Was not working due to compilation problems.
Had to leave the dll's outside of the executable for now.
Please keep SimConnect.dll and Microsoft.FlightSimulator.SimConnect.dll in the same folder of Mover.exe.

GT6 GTSport GT7
Swapped the ports. I think they where wrong but did not test.

Other bugs:
Solved bug that was leaving the main window out of the desktop when screens changed.

Sorry, updated the last post with missing info.

Thank you!
Could you briefly comment on those two new features?

FS2020 seems fine.
Can I ask for DCS support in the next one? Seems dead for now.

Did you apply the patch?
On the source you have a button for it and can also start dcs from there (pen and joystick icons)
The lua file changed.