39 minutes ago, WebMaximus said:

Sure, there's been a number of great improvements over the years but again...I don't see an improvement worth 10 years of continuous development.

It hasn't been 10 years of CONTINUOUS development, but I get your point. We should have been further along, but maybe we're too naive when trying to understand how complex and demanding the task is. And I doubt the P3D team is staffed and funded as good as ACES were in their prime. But seeing what ACES managed to do in a very short time upgrading FS9 to FSX, and then all the promise FLIGHT had after being a very short time in development, Prepar3D is progressing relatively slow. If one compare the progress made from FS2000 to FSX and P3Dv1 to P3Dv4, Lockheed Martin seems content with fixing stability issues and implementing DX11 standards. Very little has been done to the core platform, i.e. flight dynamics, weather, AI, scenery engine etc. 

7 minutes ago, simmerhead said:

It hasn't been 10 years of CONTINUOUS development, but I get your point. We should have been further along, but maybe we're too naive when trying to understand how complex and demanding the task is. And I doubt the P3D team is staffed and funded as good as ACES were in their prime. But seeing what ACES managed to do in a very short time upgrading FS9 to FSX, and then all the promise FLIGHT had after being a very short time in development, Prepar3D is progressing relatively slow. If one compare the progress made from FS2000 to FSX and P3Dv1 to P3Dv4, Lockheed Martin seems content with fixing stability issues and implementing DX11 standards. Very little has been done to the core platform, i.e. flight dynamics, weather, AI, scenery engine etc. 

Like you say, not being a developer I'm sure it's hard getting the full picture and understand the complexity.

Don't get me wrong. I'm very grateful we have P3D and that at least the platform is moving although very slowly. Certainly better than being stuck with previous versions and no development at all.

I'm just wishing both LM as well as the majority of other parties involved would eventually come to a conclusion maybe dropping some of the backward compatibility thinking wouldn't be such a bad thing after all in order to allow us to see the full potential.

Sure, there would be a number of both users and developers not being happy but I like to think, in the end when everyone would see what could be accomplished going that road, most would be more than pleased with the result.

16 minutes ago, simmerhead said:

It hasn't been 10 years of CONTINUOUS development, but I get your point. We should have been further along, but maybe we're too naive when trying to understand how complex and demanding the task is. And I doubt the P3D team is staffed and funded as good as ACES were in their prime. But seeing what ACES managed to do in a very short time upgrading FS9 to FSX, and then all the promise FLIGHT had after being a very short time in development, Prepar3D is progressing relatively slow. If one compare the progress made from FS2000 to FSX and P3Dv1 to P3Dv4, Lockheed Martin seems content with fixing stability issues and implementing DX11 standards. Very little has been done to the core platform, i.e. flight dynamics, weather, AI, scenery engine etc. 

I assume P3D is slow due to all the professional/corporate/trainer buyers of the sim.  Those guys can not upgrade cheaply and frequently.  I am again assuming here.  You know what they say about "assuming"

13 minutes ago, Skywolf said:

I assume P3D is slow due to all the professional/corporate/trainer buyers of the sim.  Those guys can not upgrade cheaply and frequently.  I am again assuming here.  You know what they say about "assuming"

I'm quite sure that is a major part of the equation. 

31 minutes ago, Skywolf said:

I assume P3D is slow due to all the professional/corporate/trainer buyers of the sim.  Those guys can not upgrade cheaply and frequently.  I am again assuming here.  You know what they say about "assuming"

Yep, makes sense what you say.

On 1/21/2018 at 1:37 PM, JanReidar said:

Being a turboprop pilot I can tell you that it's not realistic in the Realair either. But, it's better than most other turboprops in P3D taking into consideration all the limitations. And, they have fixed a few errors that you will find in other turboprop airplanes for P3D. But the way the engine handles is way off. But like they say in the manual, it's as good as it can be taken into account the limitations in P3D. When you add a little bit of power in a turboprop, the power is there more or less immediately. There's almost no "spool up" time. Also, beta range is not simulated at all in P3D. This is way better in X-plane 11.

Besides this, I agree that a desktop sim flight dynamics will never be the same as in a real airplane. But, there is plenty of room for major improvements and fixes to make the simulation in P3D mirror the real world more precisely and realistically.

I normally don't bring up older posts but I did want to point out that P3d4 does have a mechanism for modifying turboprop spool time. This is from the LM official forum and recently quoted by user kand449170 on FSDeveloper:

"A previously undocumented capability is to configure your fuel_flow_gain in the aircraft.cfg to be a function of engine speed (N2 for straight turbines, N1 for turboprops). It might look something like this...

[TurbineEngineData]

fuel_flow_gain.0 = 00.0, 0.011

fuel_flow_gain.1 = 25.0, 0.011

fuel_flow_gain.2 = 60.0, 0.05 

You can configure up to 5 data points."

Edited July 3, 20187 yr by jabloomf1230

1 hour ago, jabloomf1230 said:

I normally don't bring up older posts but I did want to point out that P3d4 does have a mechanism for modifying turboprop spool time. This is from the LM official forum and recently quoted by user kand449170 on FSDeveloper:

"A previously undocumented capability is to configure your fuel_flow_gain in the aircraft.cfg to be a function of engine speed (N2 for straight turbines, N1 for turboprops). It might look something like this...

[TurbineEngineData]

fuel_flow_gain.0 = 00.0, 0.011

fuel_flow_gain.1 = 25.0, 0.011

fuel_flow_gain.2 = 60.0, 0.05 

You can configure up to 5 data points."

I also read this on their forum. But the question that arise is, if this is possible to fix so easily...then why is not even a single developer out there doing this? The only company that gives you realistic turboprop simulation is Majestic, but they're doing everything externally using their own engine physics.

22 minutes ago, JanReidar said:

The only company that gives you realistic turboprop simulation is Majestic, but they're doing everything externally using their own engine physics.

Majestic isn't the only one (https://www.prepar3d.com/forum/viewtopic.php?t=129745 there are others also with partial), but why do you consider having the ability to do this externally as a problem or do you?  I would think that's a benefit and demonstrates flexibility of the SDK/PDK etc.  In fact, highly detailed aircraft physics are so unique to each aircraft it would be best performed by the aircraft developer rather than rely on a "common" physics system, however, that increases development costs and product costs. 

A common physics system has the advantages of reducing 3rd party developer work load, especially if they can come "close" to what they feel is well simulated.  There are also benefits to moving outside of the "common" physics and into one's own physics ... you are NOT bound to changes in the common physics engine.

One major issue with changing "common usage" physics (this applies to XP11 and P3D and AF2 and DCS) is that you break backwards compatibility ... for P3D this could results in 10,000's of aircraft no longer working correctly ... who's gonna tell the 3rd party developer to update their aircraft and how are they going to get paid for updating their aircraft to a new or changed physics engine?  LM have fixed some physics bugs in their SDK and it did indeed cause some issues with many existing aircraft, some vendors updated some did not.  The bigger your 3rd party market, the harder it is to make significant physics changes without some/lots of backlash.  This in turn is a good argument for developing one's own physics and plugging that into the P3D engine.

What might come out in the future (XP11 and P3D) are optional "common physics" engines ... providing multiple paths by aircraft on which engine is used and thus retaining backwards compatibility.

Cheers, Rob.

1 hour ago, JanReidar said:

I also read this on their forum. But the question that arise is, if this is possible to fix so easily...then why is not even a single developer out there doing this? The only company that gives you realistic turboprop simulation is Majestic, but they're doing everything externally using their own engine physics.

It's a problem for 3rd party developers if a feature is undocumented. 🙃

If undocumented entries are discovered for at least one readily available aircraft in either its aircraft.cfg or its .air file, then more people outside of LM will  eventually figure out how the entries work.

LM claims that grass SimObjects can now be used as autogen on airport backgrounds but I've yet to see a product that does so. There is a element of puzzle-solving to all this.

1 hour ago, jabloomf1230 said:

There is a element of puzzle-solving to all this

Well said Jay, the SDK is what, 6,000 pages long?  Then there is the PDK, etc. etc.  No to mention the reality of discovering what the SDK "says" vs. "what actually happens" ... it's taken developers decades to discover the SDK/PDK and still being discovered as it evolves over time.

Cheers, Rob.

Perhaps V5, with it's proposed new graphics engine, will break the "backwards compatible" mentality. It would also be a great opportunity to introduce new physics modeling too.
It might be a world of pain for those of us with mega dollars invested in add on's but at some point we are going to have to "let it go" if we want to move on to something significantly better.

 

 

On 7/3/2018 at 5:45 PM, Rob Ainscough said:

Well said Jay, the SDK is what, 6,000 pages long?  Then there is the PDK, etc. etc.  No to mention the reality of discovering what the SDK "says" vs. "what actually happens" ... it's taken developers decades to discover the SDK/PDK and still being discovered as it evolves over time.

Cheers, Rob.

Rob,

I just looked at the V4 SDK documentation and this feature is documented after all:

https://www.prepar3d.com/SDKv4/sdk/simulation_objects/aircraft_configuration_files.html

[turbineenginedata]

A turbine engine ignites fuel and compressed air to create thrust.  These parameters define the power (thrust) output of a given jet turbine engine.

Property	Description	Examples
fuel_flow_gain	Fuel flow gain constant.	Beech King Air 350( fuel_flow_gain = 0.011 ) Bombardier CRJ 700( fuel_flow_gain = 0.0025 )
fuel_flow_gain.n	Fuel flow gain constant table. This can be used in lieu of the single constant (above) in order to make the fuel flow gain a function of N1. The table will load sequentially (.0, .1, .2, ...) up to a maximum of 5 entries. Each entries first value is the N1 input, the second is the scalar at that N1. The constant will be linearly interpolated in between data points.	fuel_flow_gain.0 = 00.0, 0.011 fuel_flow_gain.1 = 25.0, 0.011 fuel_flow_gain.2 = 60.0, 0.05
inlet_area	Engine nacelle inlet area, (in square feet).	Beech King Air 350( inlet_area = 1.0 ) Bombardier CRJ 700( inlet_area = 9.4 )
rated_n2_rpm	Second stage compressor rated rpm.	Beech King Air 350( rated_N2_rpm = 29920 )
static_thrust	Maximum rated static thrust at sea level (lbs).	Beech King Air 350( static_thrust = 158 ) Bombardier CRJ 700( static_thrust = 12670 )
afterburner_available	A number, indicating the number of afterburner stages available.	Bombardier CRJ 700( afterburner_available = 0 )
reverser_available	Specifies the scalar on the calculated reverse thrust effect. A value of 0 will cause no reverse thrust to be available. A value of 1.0 will cause the theoretical normal reverse thrust to be available. Other values will scale the normal calculated value accordingly.	Bombardier CRJ 700( reverser_available = 1 )
thrustspecificfuelconsumption	Jet thrust specific fuel consumption. The ratio of fuel used in pounds per hour, to thrust in pounds. Applies at all speeds.
afterburnthrustspecificfuelconsumption	Jet thrust specific fuel consumption. The ratio of fuel used in pounds per hour, to thrust in pounds. Applies only when the afterburner is active.
afterburner_throttle_threshold	Percentage of throttle range when the afterburner engages.

---

Edited July 6, 20187 yr by jabloomf1230

10 minutes ago, jabloomf1230 said:

I just looked at the V4 SDK documentation and this feature is documented after all:

Interesting, I wonder if this is in the ESP and/or FSX SDK docs?

Cheers, Rob.