FlyPT Mover 3.5.3

FlyPT Mover Version 1.8 Beta

OK, here's a new build (works only in 64 bits processors).
Please read all the post!
It's working for me. But threads are a nightmare, specially with all the modules.
I still need to make some more reviews of the code.
So don't expect it to work right away.
Made some changes in Outputs that I could not test.
Idea is to get some feedback from the last changes before continuing the update.

Desired feedback on:
-Does it opens?
-Interface smoothness.
-Output speed and communication.
-Rig smoothness.

In my tests, calculation speed is under 0.1 ms even with a good amount of modules.
Unless I have made something wrong on the timer...
See image bellow:



So many modules, make interface updates slower, but that should not affect te calculation performance. At least significantly.
Hiding modules certainly helps.

There's some new features, that I already add in the background.
But latest requests are still to be done.

Soft start/stop has already some code made, but it's not working.

What was done:
For all the application:

-Revision to the threads and locks (needs testing, working for me).
-Memory optimisations (can do much more).
-Speed optimisations (can do much more).
-Added tool tips (only to a small part of the controls, and with English errors, sorry).

Main:
-Now clicking in the module square, shows and brings the module to the front.
-There's a new button (small square) on the upper right of the module icon. Clicking there, shows/hides the module.
-Square that indicates connection works also as a button, you can now connect/disconnect on that button.
-Right clicking over a module, now shows specific actions for that module on the menu.
-In tools, we can see the time needed for each UI update and for each Calculation update (UI=User Interface CA=Calculation).
-Solved a bug with ID generation for the modules.
Adding new modules to a loaded setup started from the last used ID, not from the bigger one found in the file.

For all sources:
-More efficient way of adding/removing gravity.
-TO DO: DIRECTIONS OF FORCES AND ROTATIONS NEED TO BE TESTED SO ALL BEHAVE THE SAME!

Loop source:
-By default, loops are now applied to rotation positions (there was no default).

Noise source:
-Timer with more definition.
Lowest time allowed is the time needed for each loop (but never under 1ms).
-By default, noise is now applied to translation accelerations (there was no default).

RFactor2 MMF source:
-Solved bug where we where not able to connect with RFactor2. Wrong name for the memory mapped file.

iRacing MMF:
-Some optimisation changes, could not test if it's working!

NoLimits2:
-STILL WITH PROBLEMS!
Communication works, problem is on the maths that get the rotations.

Poses:

Motion:
-Small optimisations.

Suspension:
-Removed flip. It's done in the gain, by using negative values.
-Solved bug that didn't allowed user to change dimensions (length and width where not changed in the calculations thread).
-Solved bug where output values shown in sliders where changed from the wrong thread.

RPM:
-Small optimisations.

Rigs:
-Added center of rotation on rigs definition.
Pose rotations are made around that point.
In the 3D view, axis show the point location relative to the rig.
This was already in code, but not in the UI.

Directs:
-Small optimisations.

Outputs:
-Removed old code that was duplicating calculations.

Viewers:
-3D with small optimisations.
-Graphics adapted to the threads. NEEDS MUCH MORE WORK!


Known problems/alerts:
-Many...


Download:
In the first post of the thread

Fought it was better to explain all the current problems:

Program was working OK, but it was to slow on the calculation.
That was causing problems on rigs that use fast actuators and interfaces, generating a pulsing movement.
To solve it, I had to put larger chunks of code inside another thread. In the end all calculations are made in that thread, but making it work for multiple modules and in conjunction with threads to get data from games and threads to output data to hardware.
Adding this to trying to put it working before vacations and errors that were already present, made it all went nuts.

Meanwhile, for the near future, I want to add new features, some already started:
-Soft start stop
-New rigs
-Translate forces in the motion cueing
-Make SimTools ordering optional in the motion cueing pose module
-Conclude the x-plane and kart kraft plugins
-Conclude the nolimits2 plugin

I will give it a test tonight hopefully, I'll let ya know how it is

I'll try the output somewhere before sunday ..

I'm going to begin testing 1.8 in less than 30 minutes, I just sat down to begin and my stomach informed me that it would not permit any testing until I ate some real food LOL. Hopefully pizza bagels will count as real food. =P

I'll be on the SimTools Discord if anyone wants to join me.

Seems like you squashed the big bugs, but broke the filters.

Desired feedback on:
-Does it opens? It worked for me with no problems.
-Interface smoothness. Seems good.
-Output speed and communication. Don't know how to check.
-Rig smoothness. Seemed good considering no filters but need filters working to say for sure.

All tests using DCS World direct mode
Bugs:
-Last ground cues persist through flight, last flight cues persist on ground, this one is a pretty big problem, I believe you said it would be an easy fix?
-All HP filters broken. Zero or near zero out value any time a HP filter is selected.
-LP filters seem to have no effect
-Sway and Surge are a bit slow and smooth with no filter. It works really well for me in flight the way it is now with no filters which is good, but may be an issue in different circumstances. If it's broken, I might ask you to break heave the same way! This could possibly just be my current settings.
-In Sway dropdown menu "logitudinal acceleration" must be selected for correct operation.
-In surge dropdown menu "lateral acceleration" must be selected for correct operation.

-For expected behavior from "mix sway in roll" a negative out gain setting is required (not sure if this is a bug or working as intended).


Feature Requests:
Cropped input values
Add Angle of Attack

After doing the testing on 1.8 I went back to 1.5 to try to get things working well enough to let my 92 year old Dad do some flying tomorrow. I just finished up tuning the Yak-52 and man that airplane, on a high displacement/angle Stewart rig with FlyPT Mover is an AMAZING experience. All I need is a harness tightener for inverted flight, right now I just fly with the harness real tight all the time and it helps with the immersion.

I've got some paint work to do so everything is presentable again, and then I'll have to post a new video. =)

Thank's for the feedback!

I think I found the filter problems.
New build coming today.

I didn't forget your requests.
The cropped input values are coming with a customisable filtering system. But first I need to solve all those bugs.

Sounds good! If you can easily fix the air/ground modes to zero out when it switches, that would be much appreciated. Right now the only way I can really fly is to turn ground mode off completely.

FlyPT Mover Version 1.9 Beta

What was done:
-Fixed filters, I think.
They where working, but loop was so fast that I had to lower the weight of the values 100x to have filtering.
-Changed the way the output thread works.

Known problems/alerts:
-Many...


Download:
In the first post of the thread

@hexpod, really it's looking funny, not to cry...
@SilentChill tested it and it's completely crazy!
Can't understand. In my last tests with the rig it's working fine. I think I'm going to test with another PC.

What do you need to test? I can try here for you as well.

Also, I went back and grabbed the example code you posted for the LUA for sending zeroes to the inactive air/ground module and I'm going to test it soon. -Update: your "something like" code for that seemed to work flawlessly, so I'd suggest adding it to the LUA included with FlyPT Mover
I'll attach the modified LUA here. I had to add .txt for it to upload.

Also, I got Dad on the simulator tonight for three hours of Yak-52 flying. =) He hasn't flown a real aircraft for nearly thirty years, so he really enjoys the motion sim in VR.

@Trip Rodriguez ,

Did you manage to try the new version?
Did it work?
Where the actuators moving nicely?

I will replace the LUA in the next build.

@Trip Rodriguez compress files into zip to upload them if they do not want to otherwise attach

Apologies my friend, last night I had promised Dad some flight time so I didn't get to try the new version yet. Unfortunately I'm busy tonight as well but I expect to do at least a thirty minute test of 1.9 and I'll post results.

Tomorrow night I should be able to get in at least six hours testing the newest version as long as nothing comes up.

Well, I wound up with no time at all to test last night, but I'm getting a reasonably early start tonight! I'm setting up the newest version to test right now and I'll report back with results.

Test results:

Sorry @pmvcda filters are still broken. They are broken a little differently though!

LP moves in jumps and if I recall correctly a filter value of more than 3 or 4 results in no movement at all.
HP still appears to have no effect regardless of value entered.

Also, the "out gain" value can no longer be typed in correctly. If you type 0.05 you get 50.000! Seems like decimal point can't be typed in and other strange behavior. You can adjust the value successfully, but you have to learn to outsmart it. =P

Additional note: Version 1.5 seems to work very very well for me. I do not notice any latency issues between game and motion sim when I test with sudden full travel roll inputs and other tests.

What do the performance issues @pmvcda is trying to solve actually affect? Latency in motion response, loss of performance (frame rate) in the game? smoothness of motion? What symptoms should I be looking for?

I can say that FlyPT Mover 1.5 works far better for me than anything else I've ever tried. I had latency complaints when I was using BFF, that problem is gone! Filter options are fantastic and super flexible, and the air/ground pose separation is a dream come true.

Thank's for the compliments.
Problem is the rate of updates in the calculation thread.
The version that works, has a 16ms rate. Never less.
The new Thanos boards can eat 2ms.
Reality is thay the calculations take less than 1ms, but since they are tied to the user interface, the updates go down to 16ms.
What I made is a different thread for calculations, but to make it we need to lock access to data.
Or calculation or user interface access data. If we don't lock and allow simultaneous access to read / write the data, values become corrupted. And results vary from one PC to Another.
In a simple application that's easy, but here with many modules types, it becomes more confusing. Also the "skeleton" is not the best and I think it's now needed to make some more profound changes.
Since I come back from vacations, I'm making it, but I also tried to contour the problem in the latest versions, but with the results we already know.

Friday I had a build I almost posted, but after some tests, it's just to forget.
New skeleton on the way, but it will take more time.
Please be patient.

Patience is not a problem! I can play with 1.5 for however long it takes anyway. In the meantime while you work I would suggest perhaps having the first post direct folks to use 1.5, with a note about the known issues including the 16ms thing.

Updated export.lua


-fixed incorrect labels (as seen in FlyPT Mover GUI) on lateral acceleration and longitudinal acceleration.
Note: I fixed only the default "option #1" code, I did not touch the alternative option #2 code

@Historiker I zipped it rather than add .txt That's a habit I have leftover from 20+ years ago when I considered .zip files a PITA. You are correct that it makes much more sense to zip it.
After you posted; it occurred to me that many people have "known file extensions" hidden so that could be a problem.