DCS A10 Support? solved with post #24909

[sirnoname]

Which plugin? There must be a second script?

[laurivs]

Ok, I am confused, this is how it goes.
DCS -> export.lua-> extractor with lockon plug-> converter, etc

Bank acceleration value is the difference between bank angle in succeeding frames. If the bank angle is the same, there is no acceleration.

Lockon plug does calculation like this: bank2-bank1=bank acceleration value. This has problems.
Here is how it should be and here's my simple (pseudo)code:

variable result1 = 0
variable result2 = 0

result1 = bank2 - bank1

If (bank2 - bank1) < -180 then
result2 = result1 + 360
else if (bank2 - bank1) >180 then
result2 = result1- 360
else result2 = result1

Result2 is the final bank acceleration value

Example1: Rolling aircraft right from bank +170 to -160. Should be 30 degree difference, not 330)

bank2=-160
bank1=+170

-160 - +170=-330 (is smaller than -180)
-330+360=+30

+30 is the clockwise bank acceleration(right roll) and correct result.

Example2: The other way around.
+170 - -160=+330
330-360=-30

Example3: Right roll from +70 to +90 bank.

+90 - +70=+20
Result1 is correct without any extra help.

Thes code works with degrees as is. (I am writing with my phone in a hotel, fairly tired, hopefully didnt mess this code up.. )

[laurivs]

Just to clarify for those of you who wonder, is there anything we can do before the plugin is updated: Yes, the (pseudo)code posted above can be added to export.lua and we can avoid some of the bank acceleration value problems that we have if we use the data from the extractor's lockon plugin. I'm using user4 slot for this custom bank acceleration value and it works somewhat ok.. I can post my export.lua if anyone is interested? (In fact, maybe I'll do it anyway later today.)

I have only the express version of visual studio which isn't enough for making a game plugin for DCS and I pretty much completely lack the coding skills; this is why I kindly request for Sirnoname to do it for us.

-L

[sirnoname]

Isnt DCS FSUIPC compatible?
http://www.x-sim.de/software.php?lang=eng&page=gamelist
-> DCS World

lockon plug compatibility is not planned for DCS

[laurivs]

As far as I know, FSUIPC does not work with DCS and was never meant to work with it? I could be wrong, but i'm 75% sure. I have used FSUIPC a lot in the past with ms flight sim, so I'm not a complete stranger to using it! If anyone actually uses it with DCS, please tell me immediately! Googling DCS and FSUIPC gives pretty much nothing. ( http://www.schiratti.com/dowson.html )
"Full release of FSUIPC 4 (incorporating WideFS 7) for use with FSX, FSX-SE and Prepar3D February 10th 2015 (3.3 MB)"

What I don't understand, is that support for DCS is not planned?

DCS = lockon! It is the same simulation, just a newer version, with a different name!

Lockon has evolved to be "DCS" and the current plugin works 99%! Only one small modification is needed to make life easier, that's all we're asking. To Add 5 - 10 lines of code given on a silver platter.

To not support DCS would be a tragedy as it really is the #1 military aviation simulation with very good physics engine and everything else, FS9/X pale in comparison as simulating ammunition and such is very limited; excellent for civil aviation simulation though! There are legendary simulations like IL2 and such but they are very old compared to DCS.

To not support the #1, leading military aviation simulation (DCS) would be the equivalent of not supporting any of the driving simulations made in the last 10 years.

With respect, I beg for your help.

-L

[sirnoname]

The part of support is no problem.
The game page was written by a member and maybe wrong.
I will check.

[laurivs]

Thank you so much!

[sirnoname]

Bad thing is, I have to delay until Friday.

[laurivs]

No problem, this is worth waiting for! Future simmers that find DCS and motion systems will enjoy the fruits of these updates I'm sure!

-L

[laurivs]

While we're at it, this is another huge problem with lockon plugin data and is easily fixed!

Check out this youtube link, I posted a video about all of what I'm about to explain.
https://www.youtube.com/watch?v=x3n0Zz1pn1k

When looking at the data given by lockon plugin, most of the data is continuous, except data related to acceleration values that flicker between 0 and another value. Let me give you an example:

Radio altimeter data example: 1400, 1400, 1410, 1420, 1430, 1430, 1430 ...
Bank Acceleration data example: +1324, 0, 0, +1530, 0 , +1400, +942, 0, ...

Somewhere the calculation is done too fast, plugin should calculate the difference between two real values. If the plugin does calculation 100 times a second, but simulator gives only say, 30 values a second, the plugin will give 0 as a result every time when the simulator didn't have time to give a value. This causes unnecessarily jumpy data. Some sort of synchronization is required.

"Whenever simulator gives a new value, do acceleration calculation, otherwise keep previous value."

This avoids the flickering values between 0 and an actual useful value. I think that it really might be this simple. This scales perfectly to any system, regardless of the simulator given values per second. Ideally the plugin could take in to account the time scale being used and actually use some sort of lerp function to provide smooth data, mean values or something, but this isn't really the most important part, who does simming with slowed time anyway? The slowing down of the time inside DCS as shown in the video is used only to show the problem in slow motion. Now you might be thinking, what's the problem then, you don't fly in slow motion? Why fix this? Because the problem can be felt with realtime data too! The data could be a lot smoother in real time also.

So, only calculate acceleration value when new data arrives, not between.

Take a close look on lockon plug value "time" and compare it to any other value! It is smooth as butter even when DCS time is slowed down almost to a halt, where as any other value updates only about 3 times a second! So, the time-value should NOT be used for synchronization as this is way too fast but almost any other value would do.

Yaw acceleration also is suffering from the original problem when going around 360 degrees and spiking, this has the same solution as I suggested few posts earlier.

-L