FlyPT Mover 3.7.0.9

Working on it, I want it to work on the next release... But it's getting complicated.

While we're waiting for the next release, one more for the backlog:
The poses/sources/rigs are not connected properly with lines in the graph all the time. So I "cheated" and basically I took one pose's output and applied as being the input to some variables for another pose. But this new Pose that is using both sources and other poses in its own poses does not get connected to anything in the graph at all and it also gets added to the graph in a weir location that may or may not show it on the display.

Overall I think the whole idea of a "Pose from Filters/Operations" is kind of unnecessary. I'd much rather have a "math" module that can take any variable input and output any variable and do whatever you want to do inside of it. It would be visible and connected in the graph to anything that it uses as the data source as the input and to anything that uses it as the data source as the output.

I'm still trying to understand the naming conventions that are used for poses/sources to access variables, are they all limited to S[n] and P[n] as their key ?

That wash... it's an experiment with high pass filters. Not good enough in my opinion

Nest suggestion item: I don't think displacement is the right output necessarily, especially for lateral moves. I think we should focus on speed rather than displacement. Right now, the speed of a movement is defined in the slope of the output displacement, which we have little to no control over in terms of time other than the simple DELTAMAX filter. But the key is that sometimes I would want the movement to go out fast while in others I want it to go out slow, almost imperceptible. This might be too complicated to do especially since we have no feedback from most(/all?) rigs. But maybe we could enter the rig's measured or defined speed and acceleration data which should be used to properly cue up motions.

It's because it's not washing out properly. Washout should be a constant slow rate below perceptible levels, not a decelerating movement.

Edit: Actually it should start slow and slowly accelerate below the perception level and do the same for the stop part.

You can change the keys on the modules:


The idea is:
S for source
P for pose
R for rig
D direct
...

That math you want is on my list. The pose is specially for my use and testing.
It's there for anyone wanting to try something

But you can use it for the math. Do it in swa and the use the var of that pose like P0.SWAY
(P0 can be waht wyou set, or use the one created bu Mover)

Agree, reason to have DELTAS in the filters.
The WASH should use them. Have some ideas but did not implement yet

That part on feedback is 75% done, hidden in the code.
The custom sources allow receiving whatever you want and with vars you can feed everything where you want.
That's one of the reasons I use the pose made of vars... ADD poses or calculated pose and feedback pose...

OK, so the modules can be renamed to anything that is capital alphanumeric value. I see you block adding spaces and special characters to the key value, but you don't block underscore "_". But you can't use underscore as it doesn't take and displays correctly anywhere else. So either block the entry of underscore or properly handle it.

I'm not sure if I understand, maybe you mean This to the right of the motion algorithm? It seems doesn't work

Ok, I have to make it better, but when yellow, it's because you have a bad char or a similar key already.
Need to block chars...

In the pose you have 7 gain, try with 1 and remove the actuators filters

Edit, yes thats that control

I think there is a bug with regards to variables:

I have Pose P0 and it's Heave value filter is set to: IF(S1.VER_A;>;0;ADD(VALUE;P0.HEAVE);0)

I would assume that this would mean that every time S1.VER_A goes under 0 it would reset the value of HEAVE and it would start counting up once it goes positive. But that is not what happens, it just keeps climbing every time VER_A is not zero. It does reset to 0 when VER_A is less than zero but it doesn't start counting from zero once VER_A goes above zero but from where it left off. I would think this is not the intended behavior here.

Finally, I am able to see GT Sports in the sources. Yeah, thanks a lot, Pedro. Must be an exhausting process..
Unfortunately I can't make it connect to the games. I thought it was because they have stopped the online service for gt sports, but I tried to use simhub to connect, and it's was able make a successful connection. Haven't tried other games from ps4 with the new mover. It could be because the port number embedded in the code wasn't the correct one for GT Sport?

If remove the actuators filters I lose the actuators maximum speed right?

Hmmm, i don't have gtsport neither the Ps4
Did you try gt7 or gt6?

Me dont have both either.. Lol. It would be great if I can enter the requested port number as in the f1 sources, since I saw my simhub listened to the port 33340 for gtsport. I dont see any other option than that.
I've tried forwarding the data from simhub through your custom udp, but the data seems unreadable/wrong formatting/data type.

Seems all actuator filters do not affect Motion Compensation and 3D view in any motion algorithm, maybe I am wrong about something.
(I deleted previous videos to avoid confusion on the YouTube channel. If needed I can upload any video that could help)

I think we are talking different things. Any filter on the actuator is not going to show on the 3d view.

This would require lots of calculation.
Thats why i say you should use the motion alghorithm to kind of logistic all the rig when reaching limits. With that you see the results in the 3d view and have vr compensation.

Actuator filters are there for simple actuators or experimentation or for who has no vr and wants to control motion in the actuators

Rig motion should be on the rig not actuators or motion cueing is useless.

I undestand what you want, to make it safer near the actuator limits, but with the motion alghorithm that's already there

Thank you Pedro for the explanation, now I've got it. You are right in my case the option "Follow pretended pose even if out of range", Now I understand what "motion algorithm" is and this feature is amazing! Well done!