FlyPT Mover

We now have two sources for DCS.
An Air source that uses UDP port 4123 and a ground source in port 4124.

Add the two in FlyPT Mover and make specific poses.
The Lua file sends data to one of the sources only.
Inside the Lua, I make a test to the gear suspension. If there's info, data is sent to grounded source, else it's sent to air source.



Don't forget to replace the Lua script!
And be careful, to select only one source for each pose.
In the image above, one of the poses uses the two sources and in this case it's wrong, since we want to separate them.

Now that you have two poses, one for ground, another for air, go to the rig and select both on the right.
The rig now uses the sum of the two to generate a pose:

New SimTools plugin:



What is the difference?
It works and sends data in doubles to FlyPT Mover using a memory mapped file.
Install it just like the other SimTools plugins.

It's sending the 12 axis generated by SimTools:

- Axis1a, Axis2a....
- Axis1b, Axis2b....​

So now we can send:

- Sway
- Surge
- Heave
- Yaw
- Roll
- Pitch
- Extra1
- Extra2
- Extra3​

in it's "pure" value or mixed by the axis assignments:



The values show in FlyPT Mover this way:

- Lateral acceleration equal to Axis1a (-100 to 100 m/s^2)
- Longitudinal acceleration equal to Axis2a (-100 to 100 m/s^2)
- Vertical acceleration equal to Axis3a (-100 to 100 m/s^2)
- Yaw position equal to Axis4a (-180 to 180º)
- Roll position equal to Axis5a (-180 to 180º)
- Pitch position equal to Axis6a (-180 to 180º)

- SimTools Axis1a equal to Axis1a (-10 to 10)
- SimTools Axis2a equal to Axis2a (-10 to 10)
- SimTools Axis3a equal to Axis3a (-10 to 10)
- SimTools Axis4a equal to Axis4a (-10 to 10)
- SimTools Axis5a equal to Axis5a (-10 to 10)
- SimTools Axis6a equal to Axis6a (-10 to 10)
- SimTools Axis1b equal to Axis1b (-10 to 10)
- SimTools Axis2b equal to Axis2b (-10 to 10)
- SimTools Axis3b equal to Axis3b (-10 to 10)
- SimTools Axis4b equal to Axis4b (-10 to 10)
- SimTools Axis5b equal to Axis5b (-10 to 10)
- SimTools Axis6b equal to Axis6b (-10 to 10)​

So if you want "pure" sway, use 100% sway only in Axis1a. Make the same for others.
The values are received between -1 and 1 and multiplied by scallers to generate the values presented above.

If you want a relation 1:1 with the games, you have to use the following values in the tunning center of SimTools:



Any doubt, just ask!

Trip's "complete idiot's" Guide to getting started with FlyPT Mover using AMC1280USB: =D
I will add more if I find any other issues that I or others have getting started.

Connecting to AMC1280USB:

At least one person beside myself found that Mover wouldn't connect to the AMC. I found the solution is that you have to define the "Rig" before Mover can send values the AMC will recognize. Also, here is the correct output string for the AMC1280 for anyone having trouble finding it:

<255><255><Axis3a><Axis4a><Axis5a><Axis6a><Axis1a><Axis2a><0><0><0><0><10><13>

Yes, I should add it at the start...

@pmvcda So far everything seems to be working well! Bug is fixed.

I do have one question: Often I want to set so that any forces beyond a certain point are treated the same. I did this with the "tuning center" in SimTools, so for example I set maximum heave cue to 3G.

I'm not sure if setting the axis 'range' will have the same effect as applying a hard cap on the data before it reaches FlyPT, but I will try to test this.

This way I can adjust (just an example) so that normal heave cues feel good, but when a really big heave movement occurs in the game it still treats it the same way as 3G and feels nice. I normally do this with essentially all axes, so that I get nice cues normally without getting side effects of excessive cues in a dogfight, aerobatics, etc.

I believe this must be done on the input side to work properly. Do you have or plan any way to do this in games (especially DCS) that you have a direct interface with?

OK, bug report time! Overall FlyPT Mover is working great! All tests were DCS world direct mode, almost all were P-51

Desperately need a way to "crop" the signal before processing, like with SimTools tuning center. I need to be able to set a maximum where the value just stays the same after that. I was unable to achieve satisfactory results on many axes without this.

Ground detection: Fantastic setup, seems to work perfectly except for one bug. Using the rudder (UPDATE P-51 only) in the air triggers the "on ground" mode. Maybe because of the steering moving the landing gear? Did I mention this "ground mode" feature is fantastic? A whole new world for ground handling cues!

DCS "angular acceleration" do not produce any data. I had to use "angular speed" instead (for yaw and roll). I will PM you a LUA that makes angular acceleration work with SimTools DCS Plugin, maybe that will help you figure out the problem. I tried... but it looked to me like yours was the same.

DCS "angular speed" pitch doesn't work. I had to use the old fashioned way

Optional: I would really like a way to set "offsets" for the incoming data as well. In different words: make it possible to adjust so FlyPT treats an input value that is not zero, as zero. Example: Tail draggers generate 0.20 surge when parked due to the tail being down low. This results in too large a cue IMO, so I'd like to "offset" it by let's say -0.10

@pmvcda This is fantastic work! Really really great!

UPDATE: So far only the P-51 rudder triggers ground mode. Yak-52 and A-10C do not have that problem. Maybe a taildragger thing? I will try to test Spitfire next session.

Took a look at the script and the code.
There's some bugs with swapped values. I will correct them (in FlyPT Mover)
But the script is working.

There's no rotational acceleration export that I know in the Lua script.
Only speed.

Do you know where we can find a good reference for DCS export data?

Meanwhile, I'm adding altitude to the variables and correcting the order.
In relation to the suspension, I need more info about the variables. That reference would be good.

Ha, that's a good reason for the rotational accelerations not to work! The rotational speed works great.

For .LUA reference all I found was this. https://wiki.hoggitworld.com/view/DCS_Export_Script I don't know how up to date it is but what you have now seems to be working great so I wouldn't worry too much about that.

Is there any way for me to collect data for you on the landing gear problem with the P-51?

Above all else, don't forget we need a way to crop/limit the "in" values! This is of the utmost importance now IMO. The extreme out of range values cause big problems.

I'll be going to bed very soon, and unfortunately probably can't get on tonight until very late.

Trip

Thank's, I will add some more data to the sources.
And I'm adding a new Source.
A general one, that can be used to filter/crop the values from one source and create a new one.
In that source you can crop values with the Logistic filter if you want to.
I think I can make it for the next build.
I want to tame DCS!

If the new source lets me crop all the values going into "on ground" source and "in air" source I will be very happy. =) It is mostly important for "in air" but best to have the ability for both.

You are doing great on "taming DCS" so far! It is the best simulator in existence for helicopters and for flying airplanes "outside normal flight envelope" so it is a very worthy sim to support.

For DCS, anyone knows what key is what in LoGetAircraftDrawArgumentValue(key)?

Can't find anything about it! HELP!

Read this starting with 2nd post on the page and see if it helps:
https://forums.eagle.ru/showthread.php?t=197766

Searched everywhere...
Can't find anything, even in the installation folder!
Or I'm blind or they really need someone to join all the info, because it's a nightmare!

New script, keeps the same logic, but only using index 1 and 6. I think wheel 2 is the middle one?
But I made an alternative in the script, but that has to be changed in the script by comment/uncomment the code
You can select how you want to generate the output.

SOLUTION 1 what we already have
SOLUTION 2 sends a part of the output depending on the number of wheels touching .the ground.
What I mean is if no wheel touches ground, 0 for ground and 1 for air
If all wheels touch ground, 0 for air, 1 for ground
If 1 wheel touches and the other one doesn't touch, 0.5 for air and 0.5 for ground

The values sent to FlyPT Mover will be affected by this values
This might make transition better, but honestly, I start doubting of the wheel fidelity information.

I will pack it with the new build.
I also corrected a bug where I had roll in yaw... (that one was inside FlyPT Mover)

I'm working on the Source I talked. When it's made, I will post a new build.

If anyone finds more info about the wheels...
Or about the height to ground. (but wheels would be better)

@pmvcda Transition seemed to be good with first version but I will test both old and new.

Roll in yaw I noticed but didn't want to report the bug until I was 100% sure. It was only while in the air, not on the ground.

Looking forward to the new source.

Sent a PM with some bits of LUA that might help with the gear detection.

I was able to get flyable results by reducing "in" gain on all axes until they no longer went off the bar, then increasing "out" gain to compensate.

This is not a permanent solution though, I'm still very much looking forward to the ability to crop the "in" signals! Current solution still results in harsh excessive cues when using large control inputs.

I will try to test late tonight for the landing gear data on as many aircraft as possible.

OK @pmvcda I've got the answer!

TL;DR- I think all you have to do is ignore left rear wheel value. In DCS on all aircraft checked so far that value is steering instead of suspension travel.


Right Front and Left Front seem to be the main wheels suspension. Signal only when on ground.
Right Rear is the rear (or front) wheel suspension. Signal only when on ground.
Left Rear seems to be steering value- in flight rudder pedals move left rear wheel value and trigger "on ground"

One remaining problem, and of course it's my favorite aircraft in DCS. =/
Huey ground detection didn't work, and you probably can't fix it (DCS problem). The landing gear values do not change. They have values, but once those values are filled in the field they never change again. =(

I want to explain what I think is part of the reason I need to crop the "in" values.

I think that the "ramp" we make with the filter is skipped if the cue "ramped up" while it was out of range. When it gets into range it's past the ramp and we get a sudden bump. This bump is one of the main things I'm trying to get rid of (and it's looking great so far!).

The reason it goes far out of range is that I tune so that I get good cues in normal flight, so when I make big movements, with my "gain" settings etc. those go way beyond the available range for the DOF.

My solution (works with SimTools) is to cap each DOF at just a bit more than the highest I get in "normal flight". This way I get good cues in normal flight, and for big movements I get just a little bit more instead of a LOT more. Without cropping the "in" signal I don't think there is any way to do this, because I want the filters working with the cropped value.

FlyPT is working on a solution, but I wanted to explain to everyone and also FlyPT. I was thinking if the "new source" method is going to cost a lot in latency and you agree with my thoughts here I thought you might want to look at other (faster) solutions.

I am also in the process of trying to accomplish the same by drastically lowering the "gain" on incoming signals until they no longer go out of range, but I'm not sure that is an adequate solution that will allow me to make big telemetry value cues only a little bit bigger than normal telemetry value cues without negative side effects.

I am now in the tuning stage (and cosmetic work) with my sim. I've got the P-51 working pretty nice, these out of range issues causing bumps are pretty much the only problem I've got left. It's working great!

Oh, and FlyPT, as near as I can tell the original transition from flight to ground is pretty much flawless. I did some hard landings, bouncing one wheel etc. and man it felt amazing!

Trip

Thank's for the tests!
I had noticed that wheel changed value when we turned. Did not know about the number 4.

For the Huey, we might be able to use altitude to ground. I have it in the new build, and then we test the values.

Yes, I thought it was easier...
The entry gain affects the input value, but doesn't crop the value.
It's there, because we receive values in m/s^2 and we work everything from there to output in mm/s^2 (we have to fit those m/s^2 in the available range in mm of the rig)
I have other ideas, but give me some time to test.