DCS vectors for motion simulators

No, not at the moment. Maybe running some scripts that could block the export values.

Any updates on this? I'm looking to build a 6DOF simpit next year.

Pitch Problem solved

Heads Up Pilots!

With this Export.lua you can counter the Problem!

https://drive.google.com/open?id=1aEOug ... -S1ZP7Obx0

You can make forward / backward / inverted loops as you like,

For example, you can cancel the climb at 80° PitchUp,

You can even roll up at 90° pitch,

And it works! Have Fun!

Some small stutter and jumps are still there, plus you have to hit the vertical pretty precise (max. 5 degrees off the track), if not some strange things will happen.

But i guess that is all just fine tuning *ggg

Thanks for any help to that.

Heads Up Pilots!

 

With this Export.lua you can counter the Problem!

https://drive.google.com/open?id=1aEOug ... -S1ZP7Obx0

 

You can make forward / backward / inverted loops as you like,

For example, you can cancel the climb at 80° PitchUp,

You can even roll up at 90° pitch,

And it works! Have Fun!

Some small stutter and jumps are still there, plus you have to hit the vertical pretty precise (max. 5 degrees off the track), if not some strange things will happen.

 

 

But i guess that is all just fine tuning *ggg

Thanks for any help to that.

Wow thanks for that!

Can you explain how to use it?

Does it work with simtools?

Do we have to copy it in our current export.lua or do we use this in place of the original export.lua?

It should work for any tool, but you have to adapt it. This version works with x-sim. I don`t know how simtools work or what values are used and where. So best would be, that the simtools dcs plugin coder, takes this export lua and merge it with simtools. I can offer support for this for sure.

In General:

The value pitch_final and roll_final are used instead of mySelf.Pitch and mySelf.Bank.

1.

You just have to make sure that all needed values are avaible in the export lua. These are:

LoGetAccelerationUnits(), LoGetAngularVelocity(), LoGetADIPitchBankYaw(), LoGetSelfData()

2.

The time stamp:

local t = LoGetModelTime()

must be just befor the socket com starts

3. These things:

pitch_final = 0 -- Finaler Pitchwert absolute ohne invert

roll_final = 0 -- Finaler Rollwert mit Rollrate

roll_climb = 0 -- Steigerung durch Rollrate pro Frame

finalquarter = 1

t = 0

Must be in in the very top in function LuaExportStart()

Thats it!

Hi again guys!

I'm a little better educated than I was two years ago but most of this thread still makes my head spin! :lol: Please try to consider that I don't understand a lot of what we are discussing!

I'm wanting to send Ian (BFF) an email to see if he can improve this with the information here so I'm trying to figure out what to tell him and what info to provide.

I know this is the same kind of thing you were discussing here. If I fly inverted, and then push the stick left my simulator rolls the opposite way it should! This is the worst issue I've had yet, and even more of an issue with my interest in these new aerobatic aircraft modules!

So what I'm looking to try to solve is the errors when you roll past 180 degrees (inverted) or pitch past 90 degrees and invert.

Can you guys help me put together the info to send Ian on the problem and how to fix it? I believe the info I need is just above this post (Pitch_Final, Roll_Final, roll_climb) but want to make sure I send Ian all the info I can to help.

For roll cues, it seems to me that it would be good to have cues just for initiating and cancelling a roll, and just have it wash out while the roll rate is maintained. Stick left; sim rolls left then washes out. Bring stick back to center; sim rolls right, then washes out. Bank angle is much less important since in a coordinated turn you basically don't feel the bank angle anyway.

Thanks all!

Awesome thread !

Do you know where I can find more explanations about this and how it could work with Simtools ?

Thanks. :)

Rolluptito, truly great strides have been made in improving this situation over on the SimTools forums.

There are now two options for getting proper motion cues without the inversion issues etc. They also work "correctly" in that Euler angles are not misused by these plugins as they are in most hobby level softwares.

Here are the threads for the two things you will want to check out:

FlyPT Mover- This has a standalone DCS mode that doesn't even require SimTools, or you can use it with SimTools. https://www.xsimulator.net/community/threads/flypt-mover-interface.13464/

Dirty's Plugin- Eventually this will be another standalone software, but for not Dirty has made an export.LUA and a modified version of the standard SimTools DCS Plugin to remedy these issues. Dirty has probably the best understanding of proper motion cues for flight in the entire community. He is a genuine commercial pilot so he has a lot of real experience to draw from.

https://www.xsimulator.net/community/threads/experimental-dcs-plugin-ready-for-testing.13560/page-5#post-185166

and more in depth discussion of the how and why:

https://www.xsimulator.net/community/threads/writing-a-motion-cueing-software-from-scratch.13108/

Many thanks for your answer TripRodriguez. ;)

Happy to help! Maybe I'll see you over there.

The whole "Euler angles don't matter/gravity doesn't exist" discussion melted most of our brains when Dirty first brought it to us! I argued with him a bit myself but once I came to understand it, it was a revelation.

Short version is that you ignore gravity by not using Euler angles to drive the sim, but gravity is modeled as a 1G acceleration toward earth instead, compounding properly with all the other forces simulated to give the best results. This avoids a LOT of the false cues we've all been putting up with.

To open the box of Pandora´s box here again: It´s not about Euler Angle. Neighter about using them to achieve G Forces. Nor it´s about position simulation. Even with the best 6DOF Hexa and best Filters you´ll not get realistic G-Forces - not even a reduced realistic simulation of Gs. Reason is that most 6DOF are based on OnSet Cueing Effect. But OnSet Cuing works only very limited, it can not simulate constant forces. And OnSet Cuing can not trick your brain good enough to simulate big inputs e.g. for aerobatics oder millitary envelope.

So imho it´s all about simulating CONSTANT G-Forces and constant Roll-Rates! And it´s about the sense of balance (yeah good old position again).

This things can maybe achieved with new Concepts like this:

Every Force generating System has false inputs or missing inputs.

Mixing the different Force-Systems together can overcome allmost all issues.

E.G. just add a stupid belt tensioner (positive Gs) into a 6DOF Steward Plattform.

It´s a game changer for sure!! Suddenly G load is perceptible. Even with just 80pounds tension-force, it´s like a new dimension. And that is just the beginning: Think about torso tension systems, tactile transducer and 360° Systems.

So that´s my future dream of G Simulation :-)

Now we're talking:

The heave axis (12cm travelway) replicates very fine, fast and smooth Forces with almost no LPor HP Filters.

The Belt Tension replicates only constant and strong Forces (since it can't simulate fast Inputs).

This combination feel damn awesome!