FlyPT Mover

I increased the interval between calculations from 2.0 ms to 2.5 ms. That appears to cleared the serial port lag.

I am not receiving any telemetry from FS2020. Apparently FlyPT Move has no required setup for Fs2020?

When I connect with SimTools, a terminal window opens confirming a connection and the frequency of data being sent.

With FlyPT, I simply click the checkbox to connect, it turns yellow. However, all data shown in every data box in FlyPT during a flight is static. I must be missing an install, settings or config file? How do I configure PacketRate(Hz)?

Either you connect to Simtools with dedicated Simtools plugin or directly with Mover’s native plugin

I selected Mover’s native plugin from sources. Add->Source->FS2020 (SIMCONNECT). Is that the only thing I have to do? Here's my setup.

Yes, In my setup mover is hanging if I don’t disconnect the fs2020 source before quitting the game.

Try to start the fs2020 source once in cockpit. It works for me. You should see data coming in.

If this is not working try the opposite. First trigger the source than launch the game

I closed Mover completely. I restarted it whilst in the cockpit and clicked connect. Magic, telemetry is now being received! Thanks so much! I'll test this out fully tonight.

Is there any way to change the PacketRate? I know in the SimTools plugin->SIMCONNECT, my PC could only managed about 25Hz before dropouts started happening. I don't know if this is improved with Mover.

Anyway, FlyPT Mover looks fantastic. I can't wait to start tinkering with all its features.

Change interval loops in the serial output to change the interval between each send through the serial.
It's a multiple of the calculation rate.

If calculation rate is 2ms, using 5 there, makes interval 10ms

I think I need to change the frequency of telemetry sent from SIMCONNECT. Isn't it FS2020 with the problem? I'm experiencing the same issue I did with Simtools. Telemetry is received for 10 seconds then hangs for 20 seconds in a loop.

It wasn't until I got down to 25Hz that telemetry flow was sustainable. Despite my sim rig being able to handle 500 hz. How do I tell SIMCONNECT to send data at only 25Hz?

Unfortunately, changing interval loops doesn't appear to make a difference.

[edit: It seems to be pausing on the ground. In the air the telemetry seems more consistent. May be a different issue?]
[edit: Had a really good test session with no telemetry pauses. I took a file created by hexpod as a starting base for the filters. Thank you!]

Can we have a new filter? It is for simulation of lateral G forces by tilt, where we don't want the user to feel the transitions. I would call it "temporal bandpass" or TBP(VALUE;factor). It will act as a bandpass filter, but the limit will be the VALUE one second ago times factor, or TBP one second ago times factor, whichever is narrower. For the first second (initialization), TBP will buffer VALUE and output VALUE.

So it would need a buffer of one second for VALUE and TBP.

It will put a limit on acceleration, attempting to keep it under a perceptible threshold. Although an EMALP or MALP might also limit accelerations, they introduce delays and do not guarantee a max acceleration (they can still be sharp on reversals). EMABP would return to zero, which we don't want. So in stead of using moving average we use a buffer (+bandwidth) to get rid of delay and self centering.

Edit: Actually, one buffer will do: When VALUE stays inside of the band you buffer VALUE, when TBP is limiting you buffer the limit. Effectively, the buffer is a buffer of the filters output. The output will be VALUE, if it is within the band specified by the factor, or the limit one second ago times the factor in the direction of the input VALUE.

pseudocode:
buffer = buffer_fetch()
if ( abs( VALUE/buffer - 1) > factor ) then //is VALUE outside the band?

if( VALUE < buffer ) then

output = buffer * ( 1 - factor ) //output is lower band limit​

else

output = buffer * ( 1 + factor) //output is upper band limit​

else

output = VALUE​

buffer_update (output)
return output

That is just pseudocode for the core functionality. The buffering needs to be coded, the initialization is different, and it needs a functionality to limit reversals in direction to once the factor, above it would allow the whole bandwidth. So a direction of movement needs to be taken into account.

FS2020 SIMCONNECT is outputting some confusing "yaw speed" telemetry. When I pitch my plane forwards and backwards, yaw speed (from the SIMCONNECT module) is outputting a high value, clockwise and anticlockwise, in sync with the pitch forwards and backwards motion. This doesn't feel right at all. I thought for a moment it was some gyroscopic effect, but the plane is not yawing visually. So I've had to disable the yaw axis. The alternative is that I take the yaw angle and filter it to prevent rollover.

Is it possible that this a bug?

Yes, I can add it to Mover 3. I already implemented some temporal stuff in 4.0. Just need to copy it to 3.

Is anyone using the OVRMC output module for motion compensation? I've set it up as described in the help section. I aligned the center and axes of the virtual tracker with the centre of the motion rig.

However, when I test some heave movement, the compensation effect is moving the VR space in the x, y and z at once, equally. Obviously, this is not usable. Is there anything I can do to debug the issue or is there some setup I'm missing?

You can easily replace your CPU with a better one, but you can NEVER replace pmvcda !!!

If you are using steam base stations, there is a know bug which has not been fixed and it is better to use a tracker or controller, instead of the virtual tracker.
If WMR headset ignore me, I don't have an answer.

@VirtualObsession , it's difficult to help you in that matter if we don't know your environment. Are you within the Vive ecosystem, WMR or Oculus/Quest?
E.g., I use the Virtual Tracker with a G2 under the WMR openXR runtime.

Sorry, I didn't mention what my setup is. I'm using a Valve Index with two v1 basestations and Index controllers. Also, Intel 10700K, RTX3080Ti and 32GB RAM.

I understand about the bug. I'll continue with using an Index controller as the tracker. The Index controller appears to be much more immune to vibrations than my v1 Vive tracker.

I was getting a lot of OVR Motion Compensation crashes in SteamVR, but it appears more stable at the moment. Occasionally, the motion compensation decides to change coordinate space suddenly, leaving me rotated by 90 degrees in all axes and shifted metres out of the plane. That may be another bug. Also, I have to watch that the controller doesn't go to sleep, which it does often. I can just about manage though.

Double Check the axis. Longitudinal has to point towards you and lateral RIGHT if I recall well.

talking about the virtual tracker coordinates

You request data through dataref, am i right?
Another thing i have no clearly that is Singulary angle. I have already seen somewhere you said that is angle between platform and actuator? But what is angle between phatform and actuator? I cant imagine it. Can you explain it through some images?
Thanks for your awesome software

@Trung nguyen,

Look at this video


The angle is zero when the actuator axis belongs to the top platform plane.
You can see what happens in that situation
So it's the angle between the actuator axis and the top plane of the platform.

Can anyone update me on GTA V?
Haven't played it for about a year - that was with Knaufinator's Simtools plugin. Would like to use now Mover. But Mover's source module receives no data.
Is the hook maybe broken? Have currently ScriptHookV, ScriptHookVDotNet and GTAScriptHookPlugin installed, do I need all of them?
And is there a necessity for one installation, Steam or EPIC?
Thanks for any enlightment!