Only start the aero engine that was previously shut down
Hi everybody,
This detailed post is aimed at all potential L.3 virtual pilots, but will also analyse the reports submitted by 'Dev One' in detail. Consequently from "Dev One's" second post;
<<I still had a problem when loading one of my aircraft which loads with the engine running. If I then shut it down & change aircraft to the L3, it bounces all over the place.>>
LOGICAL ENGINE INPUT SEQUENCING IS REQUIRED:
I have now had time to investigate the reported 'incompatibility' between FS9 default STARTUP.FLTs and my L.3 engine starting code. The problem is only the consumer input sequence cited above. It is interpreted as 'unsafe' by FS9, and because the aeroplane is in contact with the ground, FS9 imposes a 'whole aircraft crash'.
If I use the cited MSFS9 default STARTUP.FLT, which has the C172 engine running, then switch to the L.3, then shut down the L.3 using its own code, then start it up again using its own code, there is never a problem. The encoded torque versus the encoded inertia delivers 'realistic' output. Although my prior post says that is what I did, the input sequence that I actually had to make to replicate the reported problem, was the sequence 'Dev One' reports above, and that I analyse in more detail now.
To create the reported consumer error I must shut down the C172 using C172 Flight (actually engine and aircrew) Dynamics, only then switch to the L.3 using the SELECT AIRCRAFT menu, then try to start its engine with a different set of Flight Dynamics. Under those circumstances values still on the memory stack from the C172 shut down are incompatible with values on the memory stack from an L.3 start up with a different engine and airscrew and inertia.
It follows that I cannot replicate a problem restarting the engine of the L.3 after a (practice) forced landing in which the engine was actually shut down. For me if it was shut down as a C.N.A. D4, and subsequently restarted (compliantly) as a C.N.A. D4, it will behave 'realistically' (see below).
CONCLUSION:
When third party developers encode inertia values for 'microlights' that are realistically low, the consumer error above emerges as an error of consequence. This consumer error is not limited to switching just after FS9 startup, or just switching from the C172.
SOLUTION:
The permanent solution during desk top flight simulation is developing the self discipline to only start up the same aero engine that was previously shut down.
SELECT FLIGHT OPTION:
If the comment, <<I still had a problem>>, in "Dev One's" second post relates to what happened after using SELECT FLIGHT to select the L.3 via the supplied STARTUP.FLT, I also cannot replicate that problem.
Using the SELECT FLIGHT option instead of the SELECT AIRCRAFT option removes all relevant C172 (any prior aircraft) data from the memory stack. That start up is then compared to the shut down data that I impose via my supplied L.3 STARTUP.FLT.
[Engine Parameters.1.0]
ThrottleLeverPct=0.005828857421875
PropellerLeverPct=1
MixtureLeverPct=1
Pct Engine RPM=0.20281074635482108
MaxReachedEngineRPM=2021.1815071377964
LeftMagneto=True
RightMagneto=True
GeneratorSwitch=True
CowlFlapPct=1
FuelPumpSwitch=False
CarbHeat/DeiceSwitch=False
That is why changing aircraft using SELECT FLIGHT instead of just SELECT AIRCRAFT prevents the problem. Remember, it is not my intention that consumers use the supplied STARTUP.FLT in that way, even though it will impose a safe L.3 engine start, even if a different engine was shut down, before my code above is imposed (overwrites) onto the memory stack. My expectation is only that consumers will take the use of 'maximum realism' flight simulation releases seriously enough to bother to make logical inputs. The permanent solution during desk top flight simulation is developing the self discipline to only start up the same aero engine that was previously shut down.
WHAT 'MAXIMUM REALISM' DOWNLOADABLE CONTENT DELIVERS - AND HOW:
Using this from "Dev One's" second post by way of illustration....
<<I only chose 80 for the limit as that appears to be the norm, although for slower aircraft & rpm's I have seen lower values. As for the difference in the thrust curve, I have not noticed anything untoward - the take off run appears to be the same although I have not measured it, it does seem a bit sprightly for less than 60 HP though with zero or 80 set.>>
For me the only reason to develop flight dynamics for a basic trainer was to allow 'realistic' simulation of many elements of the Regia Aeronautica and Luftwaffe combat pilot selection process, and A.N.R. assault glider pilot training process, in much greater detail than is possible using content that already exists. I don't expect MSFS consumers to have prior knowledge of those doctrines, that the carefully integrated L.3 open cockpit downloadable content was developed to deliver as a learning opportunity. The complex doctrines to be learned, and the means to configure FS9 to conduct realistic self training, are explained in the integrated Student Training Manual.
One of the interesting real world doctrinal requirements that the supplied integrated downloadable content allows desk top flight simulation enthusiasts to learn, is demonstration of the skills needed to use an obstructed 300 metre (1000 foot) runway (or lesser assault glider landing zone) in a flapless aeroplane with no brakes, (the L.3), via both a powered approach, and via a glide approach. It is a complex multi part doctrine and skill. 'Maximum Realism' simulation requires very careful integration of flight dynamics, a training manual, and the 3D components to teach the parallax compliance skills needed. The supplied flight dynamics must be 'realistic enough' to make that training challenge both 'possible' and 'realistic'. The thrust from the airscrew while the vehicle in question travels at less than 80 feet per second, during take off, and approach, and landing, cannot be 'Microsoft default'.
The thrust has to be 'realistic' not randomised by Microsoft. The difference in the distance travelled while accelerating to (say) 60 KmIAS, using dumbed down Microsoft code versus realistic third party developer code, is more than 30%, but realistic thrust also delivers the glide approach glideslope, and the realistic landing roll, during and after a compliant stable, unrushed, approach at Vref. In an L.3 all of those simulation outputs happen at what Microsoft define as 'low speed'. For my realistic code to be used the 'dumbed down' Microsoft default code must be turned off.
low_speed_theory_limit = 0
It is true that;
low_speed_theory_limit = 1 //foot per second
would make no significant difference to the take off, and landing roll versus 0, but 80 would make a difference of around 30%. That's a lot of lost acceleration on a 300 metre obstructed runway in a '60hp' aeroplane!
However nothing is 'sprightly'. Every visible and invisible component is carefully integrated to deliver the possibility of learning real world multiple concurrent compliances by replicating the complex real world doctrines that deliver them. Delivering the real ability to use a 300 metre obstructed STOL airstrip nil wind, down to the real world Luftwaffe minima, while delivering the real parallax compliances throughout, is calculated, integrated, and then coded.
Having agreed to create freeware flight dynamics for a real vintage era 'lead in' trainer, deliberately designed with no brakes in real life, the question for me was, "what else did the real instructor use this particular aeroplane to teach"? One of the things it was used to teach in real life was the consequence of starting the engine with no chocks in front of the wheels. In order for the 'real' consequence to be 'illustrated' inside FS9 it is necessary to impose;
low_speed_theory_limit = 0 //feet per second
because that is the velocity of the vehicle, used in the calculation of airscrew advance ratio, during engine starting. Allowing 'dumbed down' Microsoft code to run below 1 foot per second vehicle velocity removes that learning opportunity.
Maximum realism downloadable content exists to teach specific doctrines and skills, associated with that real aeroplane. The encoded 'performance envelope' has to be 'realistic' across the entire performance envelope. The 'handling envelope' is always less certain. It nevertheless delivers specific known or rumoured problems, and if applicable known doctrinal solutions. Again no developer can expect consumers to know what they are. Consumers need an integrated training manual. .
EVERY FIX MUST MATCH THE REAL CAUSE, NOT THE PERCEIVED CAUSE:
There is a right way, and a wrong way, to overcome the problem of imposing the data from two different aero engines onto a computer memory stack.
Meddling with flight dynamics to deliver random thrust at all velocities below 80 feet per second, to allow or encourage unrecognised and poorly understood generic consumer input error to persist, only removes the opportunity to learn real world doctrines and real world skills of compliance.
There are dozens of 'radio control model' downloads available in which flapless aeroplanes, or aeroplanes with no brakes, or without either, are misrepresented as having powerful flaps, and powerful brakes, for consumers who do not wish to learn any relevant compliance skills. Those consumers must however accept that there are a minority who value functional realism and the ability to replicate real doctrines and real learned skills of parallax compliance without cheating. Without cheating means, in part, without pretending that the flight dynamics of every upload need to be dumbed down to match generic consumer knowledge base and compliance skills.
Nothing is broken. What is missing is learned compliant use of the software. That is why my Tutorials and Training Manuals, and even my infrequent posts to FS forums,have increasingly addressed learned compliant use of the retail software, and not just learned compliant use of the real aeroplane, real engine, and real airscrew.
FSAviator.