FlyPT Mover 3.5.3

More than 10 years of effort, free software at a level rarely seen today, and thousands of direct responses to users on Xsimulator, and with that some people still think that the creator of FlyPT mover doesn't care about his users.......

How can I put it.... if I were the creator in question I would answer something, but it would be censored here....

In IT, when you create software of this level, you don't want to put out a draft to please a few impatient people; for that you need to have already done a little bit of IT to understand.

Working with several developers has nothing to do with working alone on your baby; plan the debates and respond to the developers plus continue to work on his software and all this in his free time.

I'm joining noorbeast, show us what you can do.... we can't wait!

For my part, FlyPT mover is already magnificent, and I prefer to wait patiently for the new Baby, I have complete confidence in his progenitor, he will be magnificent!

I'm interested to see what comes out too, and will share the results if we get something we can publish.
But, in case it helps right now, what I was thinking so far for heave (the Reid and Nahon approach) is covered very nicely in @Dirty s thread "Flypt Filter Research (or why doesnt my rig move right?)" (sorry can't link to it as I don't have enough posts).
I've realised thouth that we also need to look at yaw, for eg a helicopter when stationary vs in a coordinated turn

Just want to say that:

When safe I will publish a release, for now it's not safe.
Already had to rebuild my rig 3D prints 2 times because of tests. I will not say more.

I can give many excuses to take so long, but I know for those waiting it means nothing. Sometimes I'm also on that side so I understand.

Just want to say that to do this I need to have at least 2 or 3 hours without interruption to do it. And between job, familly and others, it's really hard to do it. Last months I'm working on it after 23:00 when others are sleeping, not every day but that's when I can right now and when I can concentrate on it.

It's almost there, but not yet.

I really don't think what I do or not do is relevant to the discussion but I do have my fair share of "IT experience". I work for a large corporation as a security engineer (predominantly endpoint security and certificate lifecycle management) and have over 20 years of software engineering experience. One of my company's main tenants is to "move fast". It used to be "Move fast and break things" but now it's "move fast with stable infra" given our size.

Another one of our tenants is to "assume good intent". My intent wasn't to bash, it's to point out that for a community that is based on collaboration and DIY, having a single point of failure and dependence on closed source may not be the best option moving forward. I already volunteered and offered help to @pmvcda via PM months ago and I haven't even got an ACK let alone material response.

"Software of this level" is everywhere in every esoteric weird nook and cranny of the world that you can possibly imagine. I have also contributed to many of these personally. I can also tell you that incremental, frequent, small releases is what allows people to "move fast" not building monolithic code in their own bedroom office with no chance of receiving feedback or support along the way. But again, this is FlyPT's show, their choice, I'm merely postulating that maybe the community should consider going a different way.

As to why haven't I written something then? Simple: I also have a life and the cost/benefit analysis does not render the idea plausible at my current state. And given the current state, where Mover is "good enough", I haven't found the need to invest my time into the process. Others have clearly thought otherwise and built their own motion cueing software already, ironically most chose to keep their also private and closed source. If and/or when I decide to do the same I'll be sure to put it on github for collaboration.

Thanks for the update, I can empathize with the limited resource and time constraint, I often have the same issues myself. I appreciate your efforts even if it sounded otherwise in my recent comments.

I too share these concerns.. I understand that there is more to pmvdca's life than this software! But, i wish he would take on a collaborator or 2, even in private, just so that just in case, god forbid, he gets "hit by a bus" that it will live on. Even having someone to bounce ideas off of or share in the tedious work would be helpful. At this point, it is the only software capable of running my rig and without it it becomes a very expensive and heavy paperweight, which at the time i built it, flypt updates seemed to happen quite often. As of now i worry that it will not be compatible with msfs2024 which is releasing in 2 months.

In case it helps anyone, and apologies if this has already been covered, I'd wondered about how to get 6-DOF yaw to still work when the aircraft was rolled to near 90 degrees. But it looks like although the yaw value in FlyPT is in world axes, and so would mix up world heading with what the pilot feels when rolled near 90, the "Yaw speed" is the angular velocity r in body axes. So using something in the yaw channel like EMAHP(EMALP(VALUE;50.000);500) with "Yaw speed" selected as the input will hopefully work when level on the ground but also when highly banked in the air. It's neat that there is this flexibility in FlyPT
Following @Dirty 's path, the EMALP acts like an integrator to turn yaw speed back into yaw position, and the EMAHP acts as a washout to bring the platform back to straight once the yaw acceleration has finished.
I've not had a chance to try this physically though yet as we don't yet have the hooks to send from FlyPT to our platform. Hopefully in the next fortnight.

try using Yaw Speed with:

WASH(EMALP(LOGISTIC(GAIN(EMALP(VALUE;100.000);5);15;0.25);400);50;1000;100)

with an input gain 0.3 and output gain 6.0 (adjust for your rig)

Beta really soon for all to try:



Decided to cut some features to have a release. They will come with the updates that will follow.
Many bugs that I hope to have some feedback/help to solve them.

Release: 20 September 2024, so keep an eye on it.

User manual will slowlly be updated to the new release. Priority is the bug squashing and implementation of the incomplete features. So it's my itention to have a good rate on the updates.

I think it will be better to have a new topic for the new release. There's many changes in filters/operations and actuators. Setups for old Mover are not compatible, but can be imported in a future release (feature to be implemented yet).

EDIT: Need to sleep, writed October and I meant September

Why not record a small test...

Oh no, more teasers. (I joke, I joke ).

Seriously though, I'm excited to give this, and any future beta versions a try!

So nice! can't wait to test. Thanks for all your work

Brief question: For me, Mover used to 'remember' the last used output COM port, so using Auto Connect on Mover startup would work as soon as the M4S controller was online. Now for several month, this appears to be broken. When I open the output module, "Port" will be empty. When I click the Port drop down list, the my default M4S port will show up and it is enough to just briefly move my mouse over it (without clicking) to make Mover connect.
Anyone else experiencing this? Is there any workaround?

I also have a small issue. When there is no internet connection FlyPT Mover throws an error message on startup saying something like "unhandled exception..." and some network related stuff. I think it tries to connect to some DNS service which fails. If I click on "continue" everything is working normally.

I use UDP output and because the simulator is located in a garage we sometimes don't have internet connected.

Another funny thing is that windows shuts down the Ethernet adaptor completely after two minutes when there is no internet and the controller is connected directly to the PC. The controller suddenly goes into offline mode and moves to the parking position in flight.

But I think this is a windows bug. It puts everything in power save mode which seems to be not in use but doesn't take UDP connections into account. This can be fixed by adding a network switch which forces the network adaptor to stay alive.

That's because Mover looks for updates, nothing special. It's just bad coding, solved for next release.
You should look at the power saving options in windows and use a profile that keeps the ethernet. For the sim, mine is always on, full boost >>>

That one is strange, I have to try.
In the next release I hope this is solved. But be ready for lot's of other bugs and some missing features at the start.

Thanks - I just tried again and I was able to "solve" it: I just created a 2nd output module with exactly the same parameters, selected the correct COM port from the drop down, checked the Auto Start checkbox et voila - with the 'new' one it is working now.

So something must have gotten 'stuck' - let me know if I can assist in debugging to prevent this issue from facing again with Mover 4.

Did the port change or the device name (due to updates on the firmware)?
Mover looks for that to find the serial.
Also, if it's not connected on startup it won't find it automatically.

Put the correct serial port and save the setup. This should solve the problem.

The port may have changed sometime, but that was never an issue before - I always did as you suggested, selected the new port and saved. But then some day it changed to the weird behaviour described above: I just had to unfold the dropdown list and briefly hover over the correct port with my mouse to make it finally connect. But - the selected port still did not show up in the port 'window', and I also could not select it from the list, hence there was nothing new to save. Really strange tbh.