Jump to content

SFM tuning


Recommended Posts

I'm finally getting a chance to get back into understanding the flight models and I'm having to go back and revisit earlier assumptions. There are three values that are not behaving to expectations:

 

Mzalfa, Mzalfadt, and kjx. The last thoughts I had were that these correspond to Cmalpha, Cmdelta (though reversed), and aileron control power / damping ratio. However, these don't seem to correlate with values used for known aircraft.

 

If I look at NASA values for F-5 coefficients and compare that with values found in SFM_Data.lua, the values are off substantially, so either there is a disconnect in interpretation or the SFM_Data.lua values are nowhere near correct. I tend to think there is a misinterpretation, so it's back to the drawing board.

 

Given this is a simplified flight model, I'm having to make guesses about what is simplified and how. For example, instead of kjx being an aileron control power / roll damping ratio of the coefficients, it may be as simple as a radians / second acceleration factor. I will be testing this once I get my test flight HUD working again.

 

As for Mzalfa and Mzalfadt, I'm still looking at ways they might be simplified to get the values we see in SFM_Data.lua.

Link to comment
Share on other sites

A quick survey of Mzalfa and Mzalfadt use in the SFM data shows the following:

 

The most common use is Mzalfa=4.355 and Mzalfadt=0.8. There are 40 aircraft using this value from the Bf-109K4 to F-86 to F-4e to f-16 to kc-135.

 

The next most common is Mzalfa=6.6 and Mzalfadt=1 with 28 aircraft using this. These include Su-25T, Tornado, c-130, and il-76.

 

The C-101 uses Mzalfa=5 and Mzalfadt=1 while the f-15 variants use Mzalfa=6 and Mzalfadt=1.

 

Given the commonality of these values, I'm beginning to think they are not coefficients at all and may be similar to the kjx and kjz values. Since they are related to pitch, it may be that they are max and delta acceleration values though having fighters and bombers share the same values still leaves me scratching my head and wondering what it all means.

Link to comment
Share on other sites

  • 1 month later...

I just ran a flight test with kjx set to .1 and 1.29 and have now confirmed that kjx is simply a rad/sec roll rate acceleration value.

 

As the stick is deflected, the roll rate value is added to the current roll rate of the aircraft up to the Omxmax value. Damping is built in as the roll rate approaches Omxmax. Apply stick force in the other direction will subtract the acceleration value from the current roll rate.

 

Here's a plot of F-104's roll rate with a kjx of 1.29 at Mach 0.8. The Omxmax for this speed is 2.58 and 2.923 for Mach 0.9. Mach did increase a bit from the starting speed as the aircraft nosed down during roll testing.

 

With an acceleration of 1.29 radians/sec and an Omxmax between 2.6 and roughly 3, the aircraft should take a little over 2 seconds to reach Omxmax. With damping near Omxmax this stretches it out to almost 3 seconds. You can see this in the graph below.

 

RollRate_zpsimdibfma.jpg

Choosing an appropriate value to use for kjx will be an interesting discussion. I plan to dedicate some time to it in the next update of the Beginners Guide I'm working on.

Link to comment
Share on other sites

  • 3 weeks later...

Hello RedBeard could you tell us where exactly (which path and file) is located the SFM? I would tune it for an own plane.

Thank you:p!

Bye, SU

 

AMD FX-8350 @ 4.0 GHz, GIGABYTE (AMD) Radeon R9 280X Series @ 3GB Video, ATI Radeon / Realtek HD SoundCard, GIGABYTE FX-990GAUD Motherboard, Samsung 840EVO SSD @ 120GB, WD Caviar Blue @ 1TB

Link to comment
Share on other sites

Lol! What he said. :-)

 

There is no exact path and file as it varies with each aircraft. If you want to add your own aircraft, then I suggest you start reading The Beginners Guide to DCS World Aircraft Mods.

 

It will take your through, step by step, what you need to do to get your aircraft in flyable condition. It's got over 70 pages of information in it and is not complete yet, but follow along and you should get what you need.

Link to comment
Share on other sites

  • 9 months later...

rpm_acceleration_time_factor = -- time factor for engine governor  ie RPM += (desired_RPM - RPM ) * t(RPM) * dt
			{
				RPM  = {0, 50, 100},
				t    = {1,1,1} 
			},
			rpm_deceleration_time_factor = -- time factor for engine governor 
			{
				RPM  = {0, 50, 100},
				t    = {1, 1, 1} 
			},
			rpm_throttle_responce = -- required RPM according to throttle position 
			{
				throttle = {0  ,0.8 , 1.0},
				RPM      = {50 ,80  ,100},
			},
			thrust_rpm_responce = -- thrust = K(RPM) * thrust_max(M,H)
			{
				RPM = {0  ,50  , 100},
				K   = {0  ,0.5, 1},
			},

 

This must go in SFM_Data = { engine = { extended = {<HERE>}}}


Edited by LevelPulse

[sIGPIC][/sIGPIC]

Director | Team Coordinator

PC Specs:

 

 

  • Intel I7 8700k 4.7Ghz
  • Gigabyte Aorus Ultra Gaming Z370 Motherboard
  • 16GB Corsair Vengeance DDR4 3000MHz Ram
  • 500GB Samsung Evo 850 SSD

 

 

Link to comment
Share on other sites

  • 6 months later...
There are nothing common between sfm and advanced fm coding.

Dont spent your time and effort to sfm.

 

Better start with an accurate SFM then starting with the EFM which could take a lot of months.

[sIGPIC][/sIGPIC]

Director | Team Coordinator

PC Specs:

 

 

  • Intel I7 8700k 4.7Ghz
  • Gigabyte Aorus Ultra Gaming Z370 Motherboard
  • 16GB Corsair Vengeance DDR4 3000MHz Ram
  • 500GB Samsung Evo 850 SSD

 

 

Link to comment
Share on other sites

Disagree. SFM is black box of limitations. EFM open box of unlimited possibilities.

So, i`m not see reasons to waste time for sfm.

everything IMHO of course.

Link to comment
Share on other sites

Disagree. SFM is black box of limitations. EFM open box of unlimited possibilities.

So, i`m not see reasons to waste time for sfm.

everything IMHO of course.

 

If you read his first post, he says he is making a mod. There's no need for an EFM on a mod, SFM will suffice.


Edited by LevelPulse

[sIGPIC][/sIGPIC]

Director | Team Coordinator

PC Specs:

 

 

  • Intel I7 8700k 4.7Ghz
  • Gigabyte Aorus Ultra Gaming Z370 Motherboard
  • 16GB Corsair Vengeance DDR4 3000MHz Ram
  • 500GB Samsung Evo 850 SSD

 

 

Link to comment
Share on other sites

If you read his first post, he says he is making a mod. There's no need for an EFM on a mod, SFM will suffice.

 

If cubanace plan his mod with thrust vectoring, then EFM coding just mandatory. if not, then of course, sfm more simple.

Link to comment
Share on other sites

Something that would provide a great leap forward for the DCS airplane mod community would be if somebody makes an opensource EFM with similar capabilities to the built-in SFM, which people can then extend/change as necessary for new aircraft mods. Ideally ED themselves would make this available as an enhancement/replacement to API/ExternalFMTemplate/ED_FM_Template.cpp (which is too simplistic to be of much use, other than being a minimal compilable EFM dll example). As heavily criticized as the SFM is, it still models a lot of stuff, and even trying to get that level of modelling done from scratch in an EFM would take a lot of work. Most 3rd party modules would still probably opt to completely replace such an example EFM, but it would at least give a head start to new mods (standing on the shoulders of giants etc.). I know there are some opensource EFM examples like the F-16 demo (originated by CptSmiley (I think) with various forks, the most up to date one being https://github.com/ipr/F-16Demo/ (I think) ), but I don't think it is generic enough for this purpose.

____________

Heatblur Simulations

[sIGPIC][/sIGPIC]

Link to comment
Share on other sites

Something that would provide a great leap forward for the DCS airplane mod community would be if somebody makes an opensource EFM with similar capabilities to the built-in SFM, which people can then extend/change as necessary for new aircraft mods. Ideally ED themselves would make this available as an enhancement/replacement to API/ExternalFMTemplate/ED_FM_Template.cpp (which is too simplistic to be of much use, other than being a minimal compilable EFM dll example). As heavily criticized as the SFM is, it still models a lot of stuff, and even trying to get that level of modelling done from scratch in an EFM would take a lot of work. Most 3rd party modules would still probably opt to completely replace such an example EFM, but it would at least give a head start to new mods (standing on the shoulders of giants etc.). I know there are some opensource EFM examples like the F-16 demo (originated by CptSmiley (I think) with various forks, the most up to date one being https://github.com/ipr/F-16Demo/ (I think) ), but I don't think it is generic enough for this purpose.

 

Yes this would be of great Help,maybe some day.

Link to comment
Share on other sites

Something that would provide a great leap forward for the DCS airplane mod community would be if somebody makes an opensource EFM with similar capabilities to the built-in SFM, which people can then extend/change as necessary for new aircraft mods. Ideally ED themselves would make this available as an enhancement/replacement to API/ExternalFMTemplate/ED_FM_Template.cpp (which is too simplistic to be of much use, other than being a minimal compilable EFM dll example). As heavily criticized as the SFM is, it still models a lot of stuff, and even trying to get that level of modelling done from scratch in an EFM would take a lot of work. Most 3rd party modules would still probably opt to completely replace such an example EFM, but it would at least give a head start to new mods (standing on the shoulders of giants etc.). I know there are some opensource EFM examples like the F-16 demo (originated by CptSmiley (I think) with various forks, the most up to date one being https://github.com/ipr/F-16Demo/ (I think) ), but I don't think it is generic enough for this purpose.

 

 

the High Fidelity Academic EFM for the F-16 is likely the only thing you'll get without a license and SDK, and even then, there is no "General" template, some developers have a "Jet Engine" "Propeller" Etc Template, but that's their own internal work.

 

You can Extend the SFM Parameters some... But I dont remember if there's open documentation about how far.

Windows 10 Pro, Ryzen 2700X @ 4.6Ghz, 32GB DDR4-3200 GSkill (F4-3200C16D-16GTZR x2),

ASRock X470 Taichi Ultimate, XFX RX6800XT Merc 310 (RX-68XTALFD9)

3x ASUS VS248HP + Oculus HMD, Thrustmaster Warthog HOTAS + MFDs

Link to comment
Share on other sites

the High Fidelity Academic EFM for the F-16 is likely the only thing you'll get without a license and SDK, and even then, there is no "General" template, some developers have a "Jet Engine" "Propeller" Etc Template, but that's their own internal work.

 

Yup, but it would be nice if ED or somebody else made an open-source SFM-level EFM example. Maybe someday I'll do it myself, I'd be very keen to do that.

 

You can Extend the SFM Parameters some... But I dont remember if there's open documentation about how far.

 

We're using a bunch of extended SFM tables for A-4E currently, there might be more that we don't know about. Basically:

SFM_Data = {
 aerodynamics = {
   -- bunch of constants and tables we populate
 },
 engine = {
   -- bunch of constants we populate here
   extended = {
    -- and a bunch of detailed sub tables in here that we populate
   }
 }
}

The SFM is really quite detailed, so it would be amazing if we could get an opensource SFM-level EFM. Some people think the SFM is just totally simple scripted behaviour, but it's not, it's a proper flight model (internal implementation in DCS, hidden from us), taking MANY parameters as inputs from the Lua. I think it's actually quite impressive for what it is. It is still much simpler than the PFM/AFM etc. flight models that the ED and 3rd party modules implement though, of course.

____________

Heatblur Simulations

[sIGPIC][/sIGPIC]

Link to comment
Share on other sites

The SFM is quite scripted, in that the equations are already made and you can only choose the correct values. Let's call it a "standard" flight model which can be fitted into a lot of planes simply by choosing correct values. But it won't allow for complex and extreme situations. Hell, even the EFM is limited after all... there's always something hardcoded in...

 

When it comes to pure dynamics, the only hardcoded things in an EFM are gravity, ground reaction (but tuneable), and collision reaction forces.

Link to comment
Share on other sites

  • 3 months later...
rpm_acceleration_time_factor = -- time factor for engine governor  ie RPM += (desired_RPM - RPM ) * t(RPM) * dt
               {
                   RPM  = {0, 50, 100},
                   t    = {1,1,1} 
               },
               rpm_deceleration_time_factor = -- time factor for engine governor 
               {
                   RPM  = {0, 50, 100},
                   t    = {1, 1, 1} 
               },
               rpm_throttle_respon[color=Red][b]c[/b][/color]e = -- required RPM according to throttle position 
               {
                   throttle = {0  ,0.8 , 1.0},
                   RPM      = {50 ,80  ,100},
               },
               thrust_rpm_respon[color=Red][b]c[/b][/color]e = -- thrust = K(RPM) * thrust_max(M,H)
               {
                   RPM = {0  ,50  , 100},
                   K   = {0  ,0.5, 1},
               },/code]This must go in SFM_Data = { engine = { extended = {<HERE>}}}[/quote]


Does not work as described. I don't take into account the time factor...
If I start the  mission with the engines running all works as it should, but when the I stop engines and restart them again
(or start mission with the cold and dark), the RPM do not increase  from Idle (61.5%) despite the movement of the throttle.

BTW... Are you sure that there is no typos? -- rpm_throttle_respon[color=Red][b]C[/b][/color]e or pm_throttle_respon[color=Red][b]S[/b][/color]e --

[code]extended =
               {
                   rpm_acceleration_time_factor = -- time factor for engine governor  ie RPM += (desired_RPM - RPM ) * t(RPM) * dt
                       {
                           RPM  = {0, 61.5, 100, 101, 110},
                           t    = {1, 1, 1, 1, 1},
                       },
                   rpm_deceleration_time_factor = -- time factor for engine governor 
                       {
                           RPM  = {0, 61.5, 100, 101, 110},
                           t    = {1, 1, 1, 1, 1},
                       },
                   rpm_throttle_responce = -- required RPM according to throttle position 
                       {
                           throttle = {0, 0.85, 0.91, 1.0},
                           RPM      = {61.5, 100, 101, 110},
                       },
                   thrust_rpm_responce = -- thrust = K(RPM) * thrust_max(M,H)
                       {
                           RPM = {0, 61.5, 100, 101, 110},
                           K   = {0, 0.0311, 0.6954, 0.8622, 1},
                       },
               }, -- end of extended data --]]


Edited by Morkva_55

su-24.gif

Link to comment
Share on other sites

  • 8 months later...
  • 2 months later...
Does not work as described. I don't take into account the time factor...

If I start the mission with the engines running all works as it should, but when the I stop engines and restart them again

(or start mission with the cold and dark), the RPM do not increase from Idle (61.5%) despite the movement of the throttle.

 

BTW... Are you sure that there is no typos? -- rpm_throttle_responCe or pm_throttle_responSe --

 

extended =
               {
                   rpm_acceleration_time_factor = -- time factor for engine governor  ie RPM += (desired_RPM - RPM ) * t(RPM) * dt
                       {
                           RPM  = {0, 61.5, 100, 101, 110},
                           t    = {1, 1, 1, 1, 1},
                       },
                   rpm_deceleration_time_factor = -- time factor for engine governor 
                       {
                           RPM  = {0, 61.5, 100, 101, 110},
                           t    = {1, 1, 1, 1, 1},
                       },
                   rpm_throttle_responce = -- required RPM according to throttle position 
                       {
                           throttle = {0, 0.85, 0.91, 1.0},
                           RPM      = {61.5, 100, 101, 110},
                       },
                   thrust_rpm_responce = -- thrust = K(RPM) * thrust_max(M,H)
                       {
                           RPM = {0, 61.5, 100, 101, 110},
                           K   = {0, 0.0311, 0.6954, 0.8622, 1},
                       },
               }, -- end of extended data --]]

 

Hello!

I have the same problem with my mod, did you find a solution to this? Thanks! :)

Link to comment
Share on other sites

  • 4 weeks later...
Hello!

I have the same problem with my mod, did you find a solution to this? Thanks! :)

 

iirc i did fix the problem for him on Discord. Could you please post your SFM code down below and i can see what is wrong with it.

[sIGPIC][/sIGPIC]

Director | Team Coordinator

PC Specs:

 

 

  • Intel I7 8700k 4.7Ghz
  • Gigabyte Aorus Ultra Gaming Z370 Motherboard
  • 16GB Corsair Vengeance DDR4 3000MHz Ram
  • 500GB Samsung Evo 850 SSD

 

 

Link to comment
Share on other sites

iirc i did fix the problem for him on Discord. Could you please post your SFM code down below and i can see what is wrong with it.

 

Hi! :)

I tried to set all data inside the SFM code and when I start a mission with engine running, everything works how it should be.

If the engine shuts down during the flight (e.g. negative flight for too long) and I try to restart the engine, it starts again but the RPM don't move from the IDLE position (40% RPM) even if I move the throttle forward or backward. I have also the same behaviour when I start a mission with the aircraft cold & dark.

 

I have discord too, if you prefer we can move there.

 

Below the SFM code:

 

rpm_acceleration_time_factor = -- time factor for engine governor  ie RPM += (desired_RPM - RPM ) * t(RPM) * dt
                       {
                           RPM  = {0, 40, 65, 80, 95, 100},
                           t    = {0.1, 0.1, 0.2, 0.3, 0.7, 1.0},
                       },
                   rpm_deceleration_time_factor = -- time factor for engine governor 
                       {
                           RPM  = {0, 40, 65, 85, 95, 100},
                           t    = {0.1, 0.1, 0.2, 0.3, 0.7, 1.0},
                       },

		rpm_throttle_responce = -- required RPM according to throttle position 
		{
			throttle = {0  ,0.8 , 1.0},
			RPM      = {50 ,100  ,100},
		},

		thrust_rpm_responce = -- thrust = K(RPM) * thrust_max(M,H)
		{
			RPM = {0  ,50  , 100},
			K   = {0  ,0.1, 1},
		},


Edited by 6S.Duke
Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...