FlyPT Mover 3.7.0.9

Strange, I have those cuts everywhere now.

Ok so one has to start a new config from scratch in order to avoid transmission issues

Hi @pmvcda and @SilentChill:
You are right, Insectatech is offline since a long time.
The reason why I talk about Insectatech is, that Insectatech was the creator of the custom-Odrive-firmware that was and still is shared here in the community.
Personal I use the official Odrive-Firmware for Odrive 3.6. There are some important new features like limiting the torque. Since the day I set this parameter, I never had an Odrive/actuator switching off and falling down

So I just fired iRacing up tonight with 3.7.0.2 and this is actually now workable! Kudos!
There still some of the existing bugs that are already known but OXRMC works! It is doing what it's supposed to be doing with OXRMC 0.3.8beta. Looks and feels solid, things are genuinely looking strong.

The issue with directs not outputing values from their source until you open them still exists, although I have more feedback here. So I opened up the directs while already connected to output but not to source and I used the sliders to move things around and they impacted the output on both my M4S serial and my Arduino Fan serial. But once I closed the directs and started iRacing and connected to the source the data wasn't sent from the directs until I re-opened their window with iRacing connected and running.

The issue with positioning of the fields when display scaling is not at 100% seems to have been resolved! It looks good at 125%. There are some text fields that are undersized for the text that in them, in the rig module:


Singularity angle, Angle to Ground And Actuators radius are cut off as well as Motion Algorithm.


Same with Heave in the Pose module.

I haven't looked in detail everything else, but reporting what I'm seeing.


Sound in iRacing still doesn't work without the NoSound option on the command line.

But overall this is great progress! I'm going to start looking at the safety fencing feature, probably a bit later in the week and see if I can increase the motion envelope of my rig from 15 degrees rotational and 100m lateral to 200mm lateral and 25 degrees rotational. This would be a massive change!

I'm also super excited about the washout filters that can perform washout with rotational/movement speed limits, once we have telemetry option I'll start modifying my profiles to see if I can incorporate them into my filter flow.

Question/ask: is there a way to also do the same on the onset of a filter? Ie. I'd like to add rotation mix from sway and surge but I want to limit the rotation rate so it stays under the perceptible limit.

So yeah, there is definitely a few rough edges that need polishing but 3.7 for my use case works almost as good as 3.5.3 with the few exceptions and I'm eager to utilize the extra features that are not available in 3.5.3 at all.

This is probably the most exciting time to be a FlyPT user since 2021 .

@SilentChill ,

Please try this (position and ascii, old decimal):

Use the checkboxes next to Start, Send and Stop please

You can also try bits if the above doesn't work
This would make sense because of resolution and the fact you have small movements

The output string format used to be clear and simple but IMHO it's getting more and more complex in the new release. The amount of options may ask too much of new users. Users shouldn't be forced to do programming/coding. This is an unnecessary source of possible errors. Simple typing errors can lead to invalid formatting strings. Those errors need to be catched by your interpreter. Decisions have to be taken what to do in those cases: throw an error message? ignore the faulty part and output the rest?

Suggestion:
How about replacing the three formatting strings with a single list view? Four "Add" "Delete" "Move up" and "Move down" buttons control number and arrangement of list items. Options are

• ASCII decimal or hex constant bytes
• Delays in ms (to replace extra start/stop sequences)
• Integer values of 1, 2, 3 or 4 bytes
• Floating point binary values of 4 or 8 bytes
• Floating point as ASCII string with x.y digits before/after decimal point
• ... (I don't remember all of them)

This way no parsing is required and it's impossible to enter invalid strings. (Of course, the software still needs the parser internally for converting old .mover files to the new format. But it has to handle the old syntax, only)

I'm going to disagree here. Most users either use a Thanos or Motion4Sim controller. So once their output modules are enabled, tested, and working this problem will go away for the majority of users.

The ones that are remaining and require the serial output option should have the know-how and understanding on how to produce a working data string for their esoteric custom solution.

The start, stop, repeating serial data makes perfect sense and should be the only three kind that ever gets sent, there is no case where we need multiple different serial data streams to be sent, and if there is a controller that requires such thing, then that should be reconsidered on the receiving end.

The problem that I see with the current UI is:
1) lack of clear documentation of the various types of data and their formatting. I didn't know that the number of < and > would determine the number of significant digits in a float until it was mentioned in this thread. The pop-up documentation does a decent job but it doesn't cover all cases. I'm sure this will improve
2) output formatting and legibility: the single row output just can't represent some of the longer strings of data in a meaningful way, the later bytes at not visible in the window. The various output formats are also confusing a bit but ultimately this does not impact the working of the software it is merely a tool to facilitate debugging.
3) bugs in the current implementation of some of those output types/strings. I think it's hard to test that they all work unless you have hardware requiring the specific type of format. I personally don't care that actuator turns in float are broken, my rig is not interested in that data and I couldn't test this even if I tried other than looking at the output data, which as you can see from #2 above is hard to decipher. I'm sure as bugs are ironed out and documented, things will get much better.

I personally think the current issue with the UI is that it gives to every option and he kitchen sink, regardless of whether you need it or not. I have to make an input for my turns signal per rotation and stuff even though my rig does not operate with those metrics. I should have the ability not to worry about things that are not material for my setup. I think plugins/rig profiles will do that so users won't have to do all this data entry.

However, I think it should also drive what you're allowed to use on the output window. If you never entered the turns you should not have it as an option to send in the serial data.

Again, I think what we're looking at is all the capabilities with all the options all at once which can be challenging for a new user. But once rig plugins and output plugins are implemented this will all go away and most users will never have to touch any of it.

As for importing old profiles and converting them, I don't think the juice is worth the squeeze. It might take me a few hours to get my first profile going on the new version from scratch (I already have) adding new sources and poses with filters is child's game. The only problem I ran into is changes on how some filters work or order their parameters in the new version but I would not waste time on trying to import old profiles.

I fully agree. I'm a programmer and as long as everything is well documented I can cope with it. I just thought that multiple users could struggle with this and I just wanted to share my idea. Of course, if I'm wrong and nobody wants or needs this it's also OK.

I can tell that this is nearly impossible IMO. New user must have a little bit of coding to get his things work. Once they are working, i am using the same code used in the 3.5.3 version with new 3.7.0.2,and it still work however may need some tuning in the flypt filtering. I just need to drag the rig correctly in the serial section, set the correct data type in the rig section of the flypt, and it's moving as expected.

@pmvcda However GT Sports still ain't working. But I would be happy to assist you for the GT Sports with some of my downloaded python files use to read the telemetry from the game,any time dude.
Thanks for keeping up with the community.

Also, we should all remember, this is beta test stage at this point. Most users just don't have the inclination to try this version if their current one is working. They would have to have an incentive to give this version a try, be it a new feature, or new sources, or new rig/driver option that is not present in 3.5.3. For folks that 3.5.3 "just works" have almost no incentive to try this other than "morbid curiosity" with all the cost and no benefits.

I'm trying 3.7 because of the new sunk platform pedal zone safety fencing feature. This feature for me is capability altering on my rig, I can go from 100mm linear and 15 degree rotational to 200mm linear and 25-30 degree rotational. This is a massive difference especially in flight simulation and traction loss (yaw) on racing.

For me step 1 is to get feature parity with 3.5.3 before I can get excited about the new features. 3.7.0.2 is pretty close to have that.

However, for most current users of 3.5.3 I would advise against trying this unless they have a genuine need or want to contribute and support the development for all.

Was going to talk with you...
So I tested GT7 on PS5 and GT6 on PS3 and they both work for me...

Did you try to set the IP of the playstation? I'm using 255.255.255.255, this sends everywhere.
You might have some protection on the firewall for that. Try to specify the playstation IP

@GTakacs ,@Aerosmith , @khairul nizam ,

I know it's not easy to use.
But for now, what I have is the fully customizable outputs.
I'm working on others to make it easier for other users so they don't have to touch the output string.
I made this on purpose, because there's still the possibility to have changes in the vars format. I doubt I will change, but...
Going forward I want to be sure the path is well defined.

User manual will include all the details on variables, operations and all that stuff for advanced users.
I'm also working on plugins and they will be active when I'm sure I will not touch any of those "definitions".
I want to keep variables and values with the same format across Mover, this means on the filters/operations and on the outputs strings for consistency.
Access to actuators seems more complicated now. In previous Mover we used a simple key for each actuator, now we should specify from where it comes:
A direct <D> or a rig <R>. And wich actuator if a rig? <R.A> and wich value of the actuator? <RA.P> for position <R.A.B> for bits ....

Same for poses:
I want pose zero <P0>, but I want the pose before filtering and cropping: <P0.PBFC> and I want sway: <P0.PBFC.SWAY>

We can change modules keys, but not the other ones, we would loose the logic and would be hard to select the value.

Variables now access devices also, so you can use:
Joysick with ID 4378 <J4378> and I want button 4 value: <J6799.B4>
Same for midis.

I'm not allowing keyboard in the vars or it could cause a lot of confusion in my opinion.
If you look at it, I also try to keep consistency with hot controls.
We can use hot controls to change the numeric up down parameters, checkboxes or buttons (right click on one to see).
The keys for hot controls use the same string as the key used in variables.

So, for now what we have is kind of the base of everything. Now I will develop simpler solutions for the users that don't care with so much detail (even so i know it's not an easy software)

For the string output, I thought of adding a step by step question system to help generating the string. I even started it, but it0s easy to make it complicated to.
Another thing is to ask the desired format when we drag and drop the values from the list on the right over the string field (this was already in the old Mover).
But for now, let's clean the bugs...

@pmvcda I totally get it!

I personally have no problems with having all the settings staring me in the eye, I know how to filter out the things that are important for my use case from the noise. Others may not be that fortunate.

I think having the display names for the modules user adjustable but locking the P0/P1,D0/1 etc. to be fixed should be perfectly fine. Most users wouldn't know what to do with that information and for the "programmer kind" it doesn't matter if they have to reference it as P0 or POSEMOTION and P1 or POSESUSPENSION. What I'm trying to say is I think you're trying too hard to cover all the cases which is extremely difficult and almost impossible to deliver successfully, let alone deliver it on the first try. So I would recommend that you lock the module keys and not allow them to be changed.

I honestly didn't even know that I could drag/drop from the nested variable list into the output section of an output module, I just hand typed it in . Another thing where you did something (added drag/drop feature) that is probably very little use to the average user and likely took significant amount of development.

I really wouldn't spend too much time on trying to sort out the serial port output string builder. That is a one time deal to set up. Most users will spend most of their time in the pose filters to tune those. That is where I think the focus should be, that is the bread and butter and the extreme power of Mover.

Feedback on that: the graphical representation of the input to output mapping only works if you don't use filters. Once filters are in the play the graphical representation doesn't really convey what the output will really do as it's only a simple input -> output mapping of a single value and not in the time domain. I have nothing in terms of how to improve it, I rely heavily on the synthetic input data, telemetry playback and the graph feature to visualize output, and 3.7 is a MASSIVE improvement there!

I indeed tried both those broadcast address and ps ip still it could able to connect. Are you sure you are pointing the port number correctly for the GT Sports?

Yes, I tested both sources and they work.
That is strange...

Don't make your case a generality, I'm just a good handyman, not a computer scientist, so facilitating the input data would be much better for accessibility, and creating an expert mode for people like you, not the opposite, otherwise this software will quickly go into oblivion.....

Yeah, very strange. Quiting mover, starting simhub it will connect straight away.
I've included mover into windows defender firewall. Thats it right? Am I missing anything regarding the firewall section?

I definitely did not try to make the case that "this is fine" I specifically called out that others might have a problem with it.

My point is that at this stage all the bells and whistles are visible and available, some are noise even for me because of the rig and driver I'm using. To pare down the settings you would either need a binary switch of "normal and expert" mode but I don't think that would drive the ideal experience. What would you consider "normal" and what feature would you consider "expert"?

I think the idea of providing pluggable configurations and modules is the way to go. That way if I am a rig builder I could make a "rig" profile that I can lock down, make all the dimensions fixed as they are defined for my rig and allow adjustments of items that I thing should be adjustable, like how big the pedal box dimensions are, if that is something that is user specific.

If I'm producing a motion controller, then I know what values are supposed to be sent to the rig via my controller so I can make a module that has all that hard coded and the user can only select whether they want to send belt data or not, and which rig they are using to control with my controller. Then I can lock down the rest of it and not worry about the user messing these up.

But the onus for these modules is not on FlyPT to be made, it's on either the manufacturer of a rig, controller, game, wind driver, etc.

Or you can either be the pioneer and build it for the hardware you have and share it with everyone or wait for the maker of your product to build it for their customers.

I don't think there could/should be a normal or expert mode, that does not compute.