FlyPT Mover

„I don't get any info from P3D plugin for the wheel position. Is it implemented for P3D?“

Are you in P3d or xplane ?

ok I got it, I mixed you up up with @Olivier beaujoin - My fault.

1.)
I think, for flight simulation, you may want to use as source accelerations WITH gravity for all 3 linear movements AND "speeds" for all 3 rotational movements.
2.)
On every output I advise to put EMALP and check both mix checkboxes like you did
3.)
On every output EXCEPT both mix I advise to put EMAHP to wash it out otherwise you will be constantly hitting the limits

Edit:
4,)
On the mix channel put two or 3 EMALP in cascade to smooth the entry curve

Try to experiment with these new settings and report what you still need

Xplane!

Thank you so much! I will try and I let you know!

Hello Hexpod! I made changes as you suggested. The flight is much better. Heave, I still haven't found a good configuration, using the vertical acc with gravity. The landing is still varying much more if I come slow or fast, than the rate of descent, that is, if I touchdown 100 feet per minute or 400, it is not changing much. I don't know if having something exclusive for the wheels would be the case. In your case, do you feel this variation on landing, in relation to the rate of descent?

Il set the air -> ground transition to 0 (immediate) retweak your gains and see if it helps....

Thank you so much, again!

What gains should I decrease? What I said in the "transition" is that it changes the landing in the "longitinal" and not in the heave. Don't you feel that? If I land slowly, the impact is greater, but it should be in relation to the rate of descent and not horizontal speed, but I gonna try put it in 0.
What would "gain out" be? Should I change something there? And what gain are you suggesting I decrease?

@pmvcda , would you mind sharing your file for DCS? There is no example file and I think your sim is similar to mine, so, it would be a good starting point.

I you wish, ask @Gabor Pittner I shared a consistent « starting point » setting with him.

Tell me what type of plane are you using ? Stock 737 or zibo mode ?

Yes, 737 from Xplane default.

The reason I ask pmvcda is because he has a linear rig like mine. But, since I am looking for the forces and filters, beside the range, the rig has no real influence. @Gabor Pittner , do you have that starting files? Can you share it? It has nothing to do with me being lazy to look for the forces people are using. I want to start the right way, with a great file someone else worked hard to put together, so I don't have to do it myself. I will even thank you a lot for it.

Hello, I need War Thunder data output configuration file.

Hexpod, Zibo has a better telemtry?

From one version to another it was quite different. I guess they try to do a serious job. Just try it it’s free.

I was impressed by the lift changes according to flaps. It is fun. You really have to adjust your thrust in maneuvers at the low speed otherwise you get in real trouble.

Hello Everybody,

I've been using Mover on a Win7 PC since October last year and it is a great piece of software! (thanks FlyPT)

I've setup a new PC running windows 10, and finished installing Mover (2.9.9) + driving sims (iracing, Dirt Rally 1 + 2, Project Cars 2). Everything is working ok except for the Surge and Sway in Dirt Rally 1. The telemetry is being received as a source in Mover on UDP 20777 and is ok for pitch, roll, yaw and heave, but the Surge and Sway accelerations look like they are corrupted. The image below shows the Longitudinal speed and Longitudinal accelerations. The acceleration data just looks like random noise and doesn't seem to relate to the changing longitudinal speed. The problem is the same in both full screen and windowed mode.

Does anyone know what could be causing this problem?

[EDIT: Solved this problem - seems to be that UDP telemetry can become unstable if the game screen FPS is too high. Looks like the accelerations for surge and sway are at the end of the UDP packet and weren't getting transmitted correctly. Increasing the graphics options in Dirt Rally to reduce the overall FPS has solved this problem. This may also be the reason that some users have reported telemetry being unstable when using games in windowed mode.]

HI,

Was it running well in win7?
Some accelerations are calculated by Mover and that can be the reason. Seems the timer is causing troubles.
Try using a MALP filter on the acceleration, maybe with a value of 300 or more to get it better.
I'm going to verify it, but I had it smooth on my side from what I remember.
Another cause can be the cor value in the source, please verify if it's all at zero.

It was running ok in Win7. Had to use EMALP with about 300 to smooth it out in win7, but it was working ok. With the new installation on Win 10, the data seems to so scattered across +ve and -ve values that even with filter applied the accelerations just seem to shake the rig at random. Dirt Rally 2 is working well - the problem only seems to be in Dirt Rally 1. I have checked all the obvious things, reinstalled Dirt Rally, created a new setup in Mover, checked the hardware_settings_config.xml file, tried different UDP ports, used older versions of mover - I just cant seem to identify the problem!

One thing that did seem strange, the Distance to CG seems to amplify the problem. Normally I leave the Distance to CG = zero for all 3 directions in all the game sources, but with Dirt Rally 1 if I leave the values at zero, the surge and sway values stay at zero during the game (all the other telemetry is ok). If i put in a small value in the Distance to CG as per the image below, I get some data received for surge and sway, but the data seems wrong.

Hello @Pierre Lalancette, you can download the setup what @hexpod made in this post https://www.xsimulator.net/community/threads/flypt-mover.13464/page-58#post-196392
It's almost the best for F18, for me.

I've been thinking about the order the calculated dof values in mover are applied to a platform. Currently the order is fixed like that: yaw, roll, pitch, translational dof's (heave, surge, sway, for these the order doesn't matter). Now I think it would be good to have a second set of the rotational dof's that would be applied AFTER the translational dof's. Think of this scenario: Driving on a horizontal long straight track with a car with constant acceleration, so all dof's are zero except surge = 5m/s^2. Using "Mix surge in pitch" you use the pitch the simulate the constant acceleration, so calculated pitch is for example 10deg. Now you get some heave from the game. With the current order the heave will be applied after the pitch, so it will not be a vertical movement, but a 10deg tilted movement, whereas it should be a purely vertical movement because the "real" pitch of the car in the game is still zero. So I think the pitch/roll that are used for tilt coordination should be applied last, thereby not affecting the "real" pitch/roll. It maybe even useful in some scenarios to have total control of the order, i.e. you could define it to be "yaw1, pitch1, heave surge, sway, pitch2, yaw2"