FlyPT Mover 3.7.0.9

That would be cool. I wish there would be a simple way to control stepper motors through SMC3. SMC uses PWM and direction, but stepper motors are different, and looks like their drivers are different too, so not sure. But even with regular motors it would be great. FFB yokes are insanely expensive, they cost thousands. And unlike joysticks/wheels, it's not the rumble or surface or any violent forces that are needed - just an added resistance based on control surfaces deflection and speed, basically. Trimming is what makes a real difference in terms of realism (not just for fun). Right now there is no feedback on trimming- you just kind of guess and see when you are level. But in real life, you just trim out the forces on your yoke. It's not visual, you feel it.
The pendular yoke I did is so cheap and simple and works so well already/ Bungees are nice and much smoother than springs and there is no center notch. But if I run a single bungee cord around for both sides, fix it to the pulley (so the pulley acts as an arm in motion rigs) and control the pulley with a small motor, as long as the motor can hold it, it would move the yoke if you're not holding it, and create pressure if you do. A few centimeters of movement, with a sufficiently thick bungee would be enough. Do it for roll and pitch and there you go, FFB yoke for under $100.

Please add these variables from SDK page at the minimum:
ELEVATOR DEFLECTION PCT
ELEVATOR DEFLECTION
ELEVATOR POSITION
AILERON LEFT DEFLECTION
AILERON LEFT DEFLECTION PCT
AILERON POSITION
AILERON RIGHT DEFLECTION
AILERON RIGHT DEFLECTION PCT

These should give enough to work with.

I wonder how difficult would it be to program a stepper motor control Arduino firmware based on SMC3 but using a stepper driver... So FlyPT would communicate it the same way. Hmm...

Can we please focus on getting the bugs sorted out so we have at least parity with Mover 3.5.3 in terms of usability before we focus on adding new esoteric features for a one-off use case? I mean we all have our own cross to bear, and the feature we're asking for is the one and only important one, I do get that.

But I think let's get what we have fully working and polished before we start adding new and shiny things.

I think the new feature creep is what caused the situation that we have today where we haven't had a stable working release since 2021. Just too many new things going in that either worked for Pedro for his use case or were untested because Pedro was like "oh this is a quick and easy add, I don't have it but maybe will come handy in the future" and it went untested so we ended with the version that has a lot of new features/things but largely untested and definitely has bugs.

I can't expect Pedro to have the ability and time to test every single thing, but I would prefer to spend the next few weeks/months on getting 3.7 into a stable form where everyone can migrate over and abandon 3.5.3 as it has stability and feature parity with 3.7. Today that is not the case.

Don't worry, this is not a new feature request. All that's needed is just to add several vars to the MSFS2020 game source, similar to dozens that exist already, picked from the available SimConnect pool. It's probably a single line of code or a few cloned ones, so those vars would be available at the game source. That's it. Nothing in the core program needs to be modified, nothing debugged, the rest could be done with available functionality. It's a good time to add those vars because the software gets compiled anyway, so these could be slipped into one of the upcoming compiles.
I'm not going to post more about this anytime soon, now that Perdo is aware of those vars. I do agree that stability and migration to 3.7 is the top priority. For me personally, it's perfect timing, because I've started a 6DOF build. It would be nice to run it on 3.7 from the start...

It's done, 10 min.
If more are needed, just list them
Meanwhile, solved a severe bug in rotations. Lost one day with that one for two swaped values...

Will do a video.

3.7.0.3 comming soon?

get a DIY kit from vpforcecontrols.com to build the yoke, all the control surface math is figured out in their telemffb app

Today, just trying to enable rpm pose and some small bugs on file change detection

Hopefully there are field so that user can input port number of the gtsports, or user input field which port number gtsports is listening to the their source section.

Mover 3.7.0.3

Download link on the first post of this thread.

Changes:

Some more work on scale problems
Solved severe bug on rotations (now rigs can be rotated correctlly, same for actuators)
Example of a rotating slider hexapod mounted on the wall allowing full roll, could be interesting for inverted flight...


Added pose from RPM
Solved bug on rig motion alghorithm: Stay on last good pose with transition (see video on one of my last posts)
Other smaller bugs solved
Added new vars to MSFS2020

Others are still there, sorry.

VTOLVR is still WIP, no mod yet

GT games: (@khairul nizam)
Tested and they are all working on my side.
GT games use the following ports:

GT6: Mover receives on port 33340 and requests data on port 33339;
GT7 and GTSport: Mover receives on port 33740 and requests data on port 33739​

Those ports should be allowed on the firewall. Also check the anti virus, might be blocking Mover.
If you want to, try disabling the firewall and the antivirus to test.

Thanks, now I know what my next project will be after the 6DOF build is complete!

Downloaded and tested straight away. No success.
Nope, GT7 and GTSports doesn't share the same port number for telemetry. I can confirm that by checking on Sim Racing Studio and Simhub. GTSports listen to 33340, 33339 while GT7 uses 33740 and 33739.

See what I wrote.
3 and 7 differ on the ports. I'm sure it works. I tested GT6 and GT7 here, both working.
I will try with a borrowed laptop to see if I'm missing something.

What you can do is start GT first and only then connect the source in Mover. The problem might be there.
Will try to test again later, but the ports, I'm 100% sure they are correct or it would not work here.

Yup I saw. U wrote that 33340 and 33339 were use for GT6, not for GTSport as it should. I've disabled firewall, included it in exceptions, starts racing before mover, starts racing after mover. I see that you are tried on GT7 and GT6, not GTSports as you didn't have it. No problem. Didn't means to push on it. You already have put a lot of hard efforts. Thanks man.

Not on GTSports

Tested in GT6 and GT7
Can you test on GT6/GT7 or anyone else please
Need to solve this. Should be something basic...

Any update for the other bugs/features I mentioned?

Next on the list is:
Sound problem with iRacing (audio devices)
Joystick updates when plugged/unplugged (related to threads, should be simple and happening also on midi devices)
COM ports not showing some of the devices and not updating real time
Conclude the mod for VTOLVR, it's a pain with VR...
Try to get Thanos and Motion4Sim in next release (to many people using it)

Still have some of usb devices (buttons) being not recognized for some strange reason.

VPC - Rotor tcs or Cessna panel

In the old Mover did they show? With all the controls?

No, they were as well NOT recognized in 3.6 Beta