Experimental DCS Plugin ready for testing

@hexpod explained it further back as follows:

'I mean whatever you do inside the plugin, between normal and inverted flight we have 2G difference which seems perfectly logical.

Scenario 1 (starting with heave at 0)

Now, if you output in the plugin the vertical G with a “center value 0G”, (your platform will start cantered) and you will get -2G while inverted.

Imagine, in this case, if you scale your platform intensity -+ 1 you will get the motion scaled up to 1G in normal conditions. Than if you will do an inverted flight, your cue will clip and you’ll not get any heave motion. Everything below -1 will be skipped and will provide heave clipping cuts while going above -1.

Scenario 2 (starting with heave +1)

In this case you might want to scale your heave +- 2 and apply a High Pass filter (washout)

The washout will bring the heave to the center and you will have 1G travel up and 1G travel down. (I mean 1G room for normal flight and 1G room for inverted flight before Tuning Center will clip)

In this scenario you will still receive heave cues in inverted flight.

What do you prefer: scenario 1 or 2 ?

EDIT:

If you go with „Scenario 2“, it will reduce your geometrical intensity limit (axis travel) in the plugin.

Knowing that in this case your axis clips before the assigned max travel, you just have to exaggerate your 6-dof plugin’s heave travel in order to compensate your heave ability.'

Thank you for taking your time answering this. Now I need to spend some time understanding it hehe.

Ok, I have to make this fast but I will try to help.

Say you are sitting in a car, and the car is pointed up a steep hill. You feel like you are being pushed back in your seat right? But what is pulling you back in your seat? It's the fact that the 1G force of gravity is now being applied at an angle relative to you instead of straight down, and a portion of that force is now "backward" relative to you because Earth is no longer straight down from your butt.

Most hobby level sim software has dealt with this with Euler Angles instead of looking at what the G-force is and it's direction. it looks at the angle of the vehicle and moves the platform to a similar angle.

That's fine in some circumstances, but in other circumstances it creates some serious false cues. This is the problem everyone was having with DCS where rolling through inverted or pitching past vertical caused really bad things to happen.

Here's a perfect example: You roll your virtual airplane to an inverted position, perfectly upside down and fly straight. Now to return to right side up you roll right wing down (Note: this is always relative to the pilot, not the Earth, so rolling RWD when inverted actually moves the righ wing toward the sky). You will observe that the sim moves the OPPOSITE WAY it should! Why? Because instead of simulating a rotational acceleration it is trying to put the simulator into a position that correlates to the position of the aircraft. When you rolled right wing down from inverted you put yourself into a left wing down position relative to Earth and that is what the simulator is looking at!

The solution is to use rotational acceleration cues (with washout) instead of Euler angles. So the previous paragraph means that when you roll right wing down from inverted the cue will be 1G of force starting to pull you toward the left, just like the Euler angle method, but now you've got the rotational acceleration so the platform rolls rapidly to the right to cue the rotational acceleration of the right wing down movement. If you maintain a steady roll rate, aileron rolling around and around, the rotational acceleration cue washes out and the only cue will be the changing position of gravity which we use a slower cue for, but when you center the stick the stop the roll suddenly, the sim will roll quickly left wing down to cue the negative acceleration of changing the roll rate from whatever it was back to zero.

Now that's solved, but if you do an aileron roll (not to be confused with barrel roll) now you feel the proper cue initiating and stopping the maneuver but you aren't feeling the pull of gravity as the direction of Earth changes relative to you. In a barrel roll you don't feel that in real life, but in an aileron roll you do. The solution here is instead of the software looking at the Euler angle of the vehicle and trying to simulate that, you have it look at gravity from a proper scientific perspective where it's a continuous 1G force toward the center of the Earth. Now using that you can simulate things like being parked on a hill or flying in a straight line rolled 90 degrees and you will still get the expected effect, but you are simulating it correctly. Simulating the pull of gravity instead of the Euler angle will allow the various g-forces to interact more naturally and will eliminate many false cues. Here the example is pitching past vertical. When you pitch past vertical the feel of gravity pulling you backward will gradually ease off as you come inverted, then gradually increase as you come nose down from inverted. Using Euler angles the aircraft suddenly went from MAXIMUM pitch up, to pitch down and the software demands that the platform instantly return to at least level, usually even more. This results in a very sudden maximum pitch down cue that shouldn't be there.

If you want clarification please don't hesitate to ask, I'm trying to type this in a hurry so it's not as clear as it should be and might have mistakes in it, but hopefully you get the idea.

PS- To get rid of that heave axis offset you can put in a little bit of washout. This means if you are flying in a straight line (not turning) you will slowly lose the pull of gravity toward Earth, but that is something most pilots will rarely do, if ever. Make it super slow and you likely won't ever notice. Likewise if you are parked on a hill you will slowly lose the cue for the angle, and if you are in a tail dragger you will slowly lose the feeling of being tail low on the ground etc. The ideal solution there is to have zero washout when "on ground" is detected. This is possible with FlyPT Mover. I'm not sure about Nutkicker yet, but I'm sure Dirty will add it if he hasn't already.

Well thank you for this. Kind of impressed that you had to make it fast and this was the result. I'll have to work on understanding this, but as I'm a bit thick and struggle a bit with the terminology (have to google and understand the terms). Do not spend any time trying to explain it better hehe. I'll ask instead.

Now, I have gotten quite good settings for dcs witht the experimental plugin and its very enjoyable, but that is without using any form of washout at all. I'm going to try to experiement a bit more with washout now that I got a baseline that feels good. I use a 4 actuator prosimu rig btw. I've tried a washout of 25 and gain of 1, but can't really detect it feeling better. I up'ed the gain to 10 and my rig jumps all over the place.

Anyways, on with the experimenting!

Hello!
I have one question regarding setings in DCS! I have 3dof reality, and if you can't put your settings here? Thx in advance!

@PetroVitallini I realize you may already know this but just in case wanted to explain the purpose of washout filters.

The idea is to have the servos gradually return to center (ideally without the user being aware of it) so that the actuator is ready for the next move.

In many cases this isn't necessary, so be sure to evaluate your situation.

Let's say you pull back on the stick halfway and initiate a climb. We will look at only the heave axis for this. Now let's say that this motion used all of your heave travel so the sim is as high as it can go. Now you pull back the stick the rest of the way climbing even faster. Well you get no heave cue because the sim can't go any farther. If it had washed out after the first move it would have been ready to heave up again.

Not a great example but it's what I came up with on short notice. Anyway, use washout only where you find you need it. Washout falls under the category of "a necessary evil" so you don't want to use it when it isn't needed.

Also bear in mind though, that depending on your sim design, having the heave sitting at max for any period of time might mean that there is no actuator travel in one direction available for other different cues as well so don't fail to consider that.

Thank you for your input Trip. I'm aware of the possibility of clipping, but seeing you writing that washout is a necessary evil and that you don't have to use it opens up my way of thinking about this. I'm quite satisfied with my current settings, but I always wonder if there is some ultimate setting out there that eludes me.

Speaking of clipping. I've been wondering if it would be possible for simtools to make a log of dof and axis output. I have no monitors on my rig and use vr so its hard to observe the output screen. Somekind of logger that would log indefinately or in a set amount of time and present the percentage of clipping for an axis of dof at the end would be great.

Hi Folks
I have installed the plugin.
I have a 3 dof with roll , pitch and yaw
all works well, only the pich axis is a little bit stuttering when moving. How can i increase the accelleration on pitch axis? (Axis 2 in Simtolols)

Hey
Which value are you using to drive the pitch axis of your rig? Pitch (2nd collumn, angular rate lateral) or Surge (6th collumn, longitudinal acceleration)? Is the raw value that is exported from DCS also stuttering?

i use pitch
but i only tested 3 minutes then dcs crashed
but i dont think it crashes becaus esimtools i think my nvidia driver is outdated
i have
dof1 axis roll
dof1 second row pitch
dont tried yax axis at dof1 row 3

i test 1 axis after one
till it works

works on vr ?

thanks you very much noorbeast

@Dirty (and anyone else who knows LUA coding) is there a way to add/code variable motion data to simulate minor turbulence and buffeting when off the ground.
A series of random (programmable) accelerations and roll angles fed into the output stream when the weight on wheels trigger is zero would be awesome.

Variables that could be included in the LUA:
- max/min/avg displacements (velocities and angular deviations)
- max/min/avg time range between application of any given displacement
- max/min duration of applied displacement
- max/min smoothing value
- multiplier for the above values based on aircraft altitude and airspeed

A simpler approach might be to just 'record' a 2-3 minute stream of displacements for each output, and then add a factor for altitude and airspeed??

I can't code to save myself, but for one axis might look like this??
[[horrible, horrible attempt at trying to explain the variables to follow...]]

-- The process begins when the aircraft leaves the ground
check weightonwheels = o

-- 1) set time for next 'event' using randomizing function between max/min time periods
accelxtime.max = 15 //sets max time for force inputs (seconds)
accelxtime.min = 3
accelxtime.avg = 5
--factor for airspeed and altitude
accelxtime.asp = 0.95 //multiplier, arbitrary value corresponding to time between events shortens as airspeed rises, or if set at 1.0 means no change
accelxtime.alt = 1.1 //multiplier, arbitrary value... event timing increases as altitude increases (<1.0 = event times decrease)

-- 2) one the time has been set, it will be a displacement between the following max/min values
accelx.max = 10 //set the max acceleration value to randomly add to the aircraft when in air (in m/s)
accelx.min = 2
accelx.avg = 4
accelx.asp = 0.9 //multiplier, acceleration value decreases as airspeed rises
accelx.alt = 1.0 //multiplier, acceleration value stays the same as altitude increases

-- 3) the duration of the force will be
accelxdur.max = 1.5 //set the max displacement time (seconds)
accelxdur.min = 0.1
accelxdur.avg = 0.7
accelxdur.asp = 0.9 //multiplier, duration decreases as airspeed rises
accelxdur.alt = 1.1 //multiplier, duration increases as altitude increases

--4) the smoothness of the force (between a smooth 'bell' curve and a sharp square curve)
accelxsmooth.max = 1.0 //some shaping parameter
accelxsmooth.min = 0.5
accelxsmooth.avg = 0.9
accelxsmooth.asp = 1.1 //multiplier, smoothness increases as airspeed rises
accelxsmooth.alt = 1.2 //multiplier, smoothness increases as altitude increases

--) the force is applied and then returns to "zero"
re-run function

If the same function was run at the same time for the other axes it would definitely feel very organic, and give people the opportunity to find a turbulence regime that makes you really feel aloft in a sim that feels very much on rails.

Oh, and absolutely HUGE thank you for this awesome plugin. I literally spend hours and hours just flying around by myself without weapons, loving the experience that you've helped us achieve.
Thank you

Hey @DoctorD,

Thank you very much for the awesome compliment! Muuuuch appreciated

Creating your own motion can be a double-edged sword. I'm not saying that it shouldn't be done, just be aware that you might be buying into some potentially problematic artifacts.

First of all, I believe that the plugin should do nothing more than provide access to the raw data. The processing should be done in the motion cueing software. As tempting as it might seem, I would not want to code this inside the export scrip, but much rather have it as a proper module that can be tuned/altered/modified in the motion cueing software.

I know in FlyPTs Mover you can generate this kind of turbulence and from what I saw it works pretty impressive. I think (not sure though) you can even make it conditional, so that it only starts when certain values are exceeded. I have tested the stall buffet in @hexpod 's rig and my immediate reaction was: Wow, this is how it should feel!" Maybe @hexpod or @pmvcda can point you in the right direction how to implement it properly to have it only when airborne.

The other edge of the sword is that the motion you generate will only be present in the rig, but not in the visual! While normally we do everything to keep the visual and the motion as close as possible to each other, here all of a sudden you are intentionally introducing a disconnect between motion and visual. From just some general considerations, I would expect it to be the least problematic if used moderately in translations but very sparsely in rotations. In the end it will be a trial and error process anyways.

The silver bullet would be, if the steady background turbulence of flying came directly from the interaction of the plane with the atmosphere. AFAIK it is nicely done in X-plane and DCS, but not really all that much in P3D. This would have the advantage that you could get the shaking in the motion AND the visual In real life, flying a high performance aircraft (especially FBW) in perfectly still air (5:00 a.m. TakeOff in the desert) can actually feel a bit like flying on rails. Have you tried setting some light turbulence in DCS?

Oh,.... if you were to implement it on your own, I would add a bunch of sine waves of different frequencies and amplitudes. Space them at ratios that are prime numbers like 7/11/13/19/23...etc. change the amplitudes and/or frequencies according to other sine waves.
Probably also worth considering Simplex Noise or Perlin Noise. If you find a library somewhere, use that.

Cheers,... Dirty

Hi @Dirty ,

Sorry, just saw it today.

I'm using this script to get data:

Code:

-- DCS LUA SCRIPT FOR FLYPT MOVER 2.9

function LuaExportStart()
    package.path = package.path..";.\\LuaSocket\\?.lua"
    package.cpath = package.cpath..";.\\LuaSocket\\?.dll"
    socket = require("socket")
    host = host or "127.0.0.1"
    DCSPort = DCSPort or 4123
    DCSClient = socket.udp()
    DCSClient:settimeout(0)
    DCSClient:setpeername(host, DCSPort)
end

function LuaExportAfterNextFrame()

    local acceleration = LoGetAccelerationUnits()
    local speed = LoGetVectorVelocity()
    local pitch, roll, yaw = LoGetADIPitchBankYaw()
    local rotationSpeed = LoGetAngularVelocity()
    local altitude = LoGetAltitudeAboveGroundLevel()
    local o = LoGetSelfData()
    --[[
    LatLongAlt.Lat -- Latitude in degress
    LatLongAlt.Long -- Longitude in degress
    LatLongAlt.Alt -- Altitude in meters MSL
    Heading -- Heading in radians
    Pitch -- Pitch in radians
    Bank -- Bank in radians
    ]]--
  
    local mechInfo=LoGetMechInfo()
    --[[
    gear          = {status,value,main = {left = {rod},right = {rod},nose =  {rod}}}
    flaps          = {status,value}
    speedbrakes   = {status,value}
    refuelingboom = {status,value}
    airintake     = {status,value}
    noseflap      = {status,value}
    parachute     = {status,value}
    wheelbrakes   = {status,value}
    hook          = {status,value}
    wing          = {status,value}
    canopy        = {status,value}
    controlsurfaces = {elevator = {left,right},eleron = {left,right},rudder = {left,right}}
    ]]--
  
    local alarm = LoGetMCPState()
    --[[
        returned table keys for LoGetMCPState():
        "LeftEngineFailure"
        "RightEngineFailure"
        "HydraulicsFailure"
        "ACSFailure"
        "AutopilotFailure"
        "AutopilotOn"
        "MasterWarning"
        "LeftTailPlaneFailure"
        "RightTailPlaneFailure"
        "LeftAileronFailure"
        "RightAileronFailure"
        "CanopyOpen"
        "CannonFailure"
        "StallSignalization"
        "LeftMainPumpFailure"
        "RightMainPumpFailure"
        "LeftWingPumpFailure"
        "RightWingPumpFailure"
        "RadarFailure"
        "EOSFailure"
        "MLWSFailure"
        "RWSFailure"
        "ECMFailure"
        "GearFailure"
        "MFDFailure"
        "HUDFailure"
        "HelmetFailure"
        "FuelTankDamage"
    ]]--
    local stall = 0
    for k,v in pairs(alarm) do
        if k == "StallSignalization" then
            if v == true then
                stall = 1
            end
        end
    end

    -- local engine = LoGetEngineInfo()
    --[[
    RPM = {left, right},(%)
    Temperature = { left, right}, (Celcium degrees)
    HydraulicPressure = {left ,right},kg per square centimeter
    FuelConsumption   = {left ,right},kg per sec
    fuel_internal      -- fuel quantity internal tanks    kg
    fuel_external      -- fuel quantity external tanks    kg 
    ]]--

    -- The FlyPT Mover uses Z for vertical and Y to the front
    -- That's the opposite in DCS
    -- Values sent in one string, separated by spaces
    socket.try(DCSClient:send(
    --               00   01   02   03   04   05   06   07   08   09   10   11   12   13   14   15   16   17   18   19   20   21   22   23
    string.format("%.4f %.4f %.4f %.4f %.4f %.4f %.4f %.4f %.4f %.4f %.4f %.4f %.4f %.4f %.4f %.4f %.4f %.4f %.4f %.4f %.4f %.4f %.4f %.4f",
    acceleration.x,                     -- 00 = Lateral acceleration (G)
    acceleration.z,                     -- 01 = Lateral acceleration (G)
    acceleration.y,                     -- 02 = Vertical acceleration (G)
    speed.x,                             -- 03 = Lateral speed (m/s)
    speed.z,                             -- 04 = Longitudinal speed (m/s)
    speed.y,                             -- 05 = Vertical speed (m/s)
    rotationSpeed.y,                     -- 06 = Rotation speed around y (yaw in rad/s)
    rotationSpeed.x,                     -- 07 = Rotation speed around x (roll in rad/s)
    rotationSpeed.z,                     -- 08 = Rotation speed around z (pitch in rad/s)
    o.Heading,                             -- 09 = Yaw position (rad)
    o.Bank,                             -- 10 = Roll position (rad)
    o.Pitch,                             -- 11 = Pitch position (rad)
    LoGetTrueAirSpeed(),                 -- 12 = Air speed (m/s)
    LoGetAircraftDrawArgumentValue(1),     -- 13 = Front/Rear landing gear (0 to 1)?
    LoGetAircraftDrawArgumentValue(2),     -- 14 = Turning landing gear (0 to 1)?
    LoGetAircraftDrawArgumentValue(4),    -- 15 = Left landing gear (0 to 1)?
    LoGetAircraftDrawArgumentValue(6),     -- 16 = Right landing gear (0 to 1)?
    LoGetAltitudeAboveGroundLevel(),     -- 17 = Vertical position relative to ground (m)
    mechInfo.flaps.value,                 -- 18 = Flaps amount (%)
    mechInfo.gear.value,                 -- 19 = Delployed landing gear (%)
    mechInfo.speedbrakes.value,         -- 20 = Speed brakes (%)
    mechInfo.canopy.value,                 -- 21 = Canopy open (%)
    stall,                                 -- 22 = Stall alarm (0 or 1)
    LoGetModelTime()                     -- 23 = Time in seconds
    )))
end

function LuaExportStop()
    if DCSClient then
        DCSClient:close()
    end
end

I'm separating data inside Mover, between air and ground by using the sum of:

LoGetAircraftDrawArgumentValue(1), -- 13 = Front/Rear landing gear (0 to 1)?
LoGetAircraftDrawArgumentValue(2), -- 14 = Turning landing gear (0 to 1)?
LoGetAircraftDrawArgumentValue(4), -- 15 = Left landing gear (0 to 1)?
LoGetAircraftDrawArgumentValue(6), -- 16 = Right landing gear (0 to 1)?

If more than zero, it's ground.

For stall, I use the stall alarm.
To generate the vibration, I have a noise filter.
That's a random value generated with the amplitude of the stall value.
So if stall is 0, noise is zero.
If stall is 0.5, noise is 0.5 amplitude.
and so on.
1 is low, so I put a gain there, like 5 for linear accelerations and 2 for rotations.
You can do it in the plugin easily.
There's no need for perlin noise or something like that.
Perlin noise is going to increase load and memory usage, and I don't see how we can use it in this kind of situation.

In C# just use something like this:

Code:

var Random random = new Random();
var noise = random.NextDouble()*amplitude;

Add a smooth filter if needed or a frequency to update the value.
Results seems convincing.

I use the same for flaps turbulence, landing gear or air brakes, but those are multiplied by air speed. So if speed is zero, no turbulence.

To have climate effects (wind), it all depends on games. Some include it in accelerations or speeds, so it would be already felt.
To generate it randomly, I think it would be better to generate a random direction with small variation and the same for speed.
But I'm with you, visuals and instruments should reflect it.
I can add it to Mover, but there's other priorities now.

By the way, I'm having troubles installing the latest plugin for SimTools. It says invalid plugin.

Hey

Thanks a lot!

Great to hear that a simple random number is enough to generate plausible turbulence. I don't have the rig ready yet, so I couldn't test it here at home. I tried the buffet in Mover on @hexpod s rig and it was impressive! Absolutely no need for resource hungry noise functions or sine/cosine compositions.

Dirty

Sometimes I have that too :-/ Couldn't figure out why. Try unpacking the .zip, make a copy of the .dll somewhere and then move only the .dll into the PluginUpdater.

Dirty

Already tried, but it's not working.
Had some problems also with my plugins.
Did you erase any necessary function or changed the name of the assembly.
We can't use spaces in the name, I'm using _.
Those where some of the problems I had.
The plugin I made for Mover has no setup, so I removed everything related to the presets. But it needs to have the functions to generate an empty preset or it's going to crash.
Not sure if those problems are also in plugins for games, but in interfaces I had them.