Hi Friends,
I just uploaded the A.V.I.A. FL.3.....
The L.3 was a partially failed attempt to create a very simple and cheap monoplane trainer, better suited to the entire basic training syllabus of Regia Aronautica pilots from 1940 onwards. This open cockpit version was also adopted for 'lead in' training, by the Croatian Air Force, and eventually the Luftwaffe, and by the A.N.R. for assault glider pilot training. Some also served as 'unit hacks' during WW2. Full details are in the suppled contextual history.
This release (Part 1) provides two open cockpit MDLs, with different landing gear, many relevant liveries, a combined contextual history of both the open and closed cabin versions, and an illustrated Student Training Manual to allow realistic simulation of the wartime Axis 'lead in' training syllabus. The Part 2 of this release will later feature the enclosed cabin version.
VC only.It also works subject to some limitations within in FSX.
CREDITS:
External GMAX model, animations, VC and liveries by Manuele Villa.
Prop textures by Bob Rivera.
Pilots by Manuele Villa on original by Craig Richardson.
Flight dynamics, handling notes, contextual history and student training manual by FSAviator.
Sounds from default Piper J3 Cub modified by Manuele Villa.
Screenshots (FS2004 & FSX) by Huub Vink.
Gauges - many of the Italian gauges in this panel were created from scratch or radically modified from freeware items by Manuele Villa and Stefano Meneghini (PCMENEG). The icons are MS default. Bitmaps for some gauges by A.Biagi (ItalianWings). Aircraft descriptions by FSAviator & Manuele Villa.
SPECIAL THANKS To Mr.S.Meneghini,Mr.Kikko Zanaboni and Mr.Paolo Miana for their precious help.
I installed this in FSX, it seems to work fine. You have to remember that it doesn't have any brakes.
The only slight negative is a background noise like someone pounding a drum. Maybe this in FSX only?
What a lovely plane - I downloaded it this morning before setting of to work. Can't wait to try it out this evening! Thank you so much for keeping on giving us these beautiful models of classic italian aviation !
Anyone have trouble starting her from 'cold & dark', i.e. fuel off, mags off at park place or end of runway?
If I set default flight of Cessna, that has engine off, then change to the L3, the L3 bounces all over the place as it does in FSX, anyone else copy this?
If they do try the FSX aircraft.cfg mod offered in that forum, i.e. change the low_speed_theory_limit=0 to 80 & see if its OK after that.
It seems to be OK in FS9 if engine is running at the start of the flight, but a 'dead stick' landing makes it bounce for me without that change.
@ Manuele: First I want to thank you for your efforts with your planes. Love all of them.
But I have the same probs as Keith mentioned. When starting cold+dark, it is like a ten ton weight is dropped on this little plane. When loading the start up-flight (the engine is running in this scenario) everything is just fine.
It seems that no one has a problem, under any circumstance, if the L.3 is spawned with the engine running, and the engine is never restarted.
NATURE OF THE PROBLEM:
However if I use the cited default Cessna 172 STARTUP.FLT, then select the L.3 using the Select Aircraft menu, then shut the engine down, and then restart it, I can replicate the reported problem.
No one involved in development, or beta testing, reported this problem during engine start or re-start while using assorted other personal STARTUP.FLTs, but something in that specific Microsoft STARTUP.FLT, (and some other MS default STARTUP.FLTs), is incompatible with the L.3 engine start code.
THE TEMPORARY (FULL) SOLUTION:
The solution *only needed if an engine start will be invoked*, is to start FS9 as usual. Then instead of using the AIRCRAFT menu to select the L.3, use the FLIGHTS menu to select the supplied L.3 STARTUP.FLT. Then move to desired location using the World\GoTo menu as usual.
MEDDLING WITH FLIGHT DYNAMICS:
<<If they do try the FSX aircraft.cfg mod offered in that forum, i.e. change the low_speed_theory_limit=0 to 80..... >>
Altering the entire real thrust equation of the real screw is a silly way to solve any problem unless MSFS is used only as a radio control model aeroplane simulator.
DEAD STICK LANDING and ENGINE RESTART:
<<It seems to be OK in FS9 if engine is running at the start of the flight, but a 'dead stick' landing makes it bounce for me without that change.>>
It is not the engine off landing, or the engine shut down / failure, that causes the problem. It is the code relating to 'behaviour during engine starting' imposed on the memory stack by the most recent STARTUP.FLT chosen, and 'remembered' throughout the following FS session.
After a default start up, when the provided STARTUP.FLT in the L.3 Part 1 release is used to select the L.3, and imposes its values on the memory stack, there is no subsequent engine start problem (in FS9). How much later the engine start happens is not a factor. It can be within seconds after a GoTo 'anywhere', or it can be hours later after a dead stick landing. What is going to happen upon any later engine start is already loaded from the *most recent* STARTUP.FLT that has imposed its coded values on the memory stack.
UNIVERSAL SOLUTION?
However it was not my intention that the provided STARTUP.FLT, (for a real Luftwaffe L.3 STOL training runway that has no GoTo in FS9, but is cited in the Training Manual), be mandatory for cold and dark starting.
I expect a 'universal solution', that will not destroy the real thrust curve, will be available once the specific incompatibility is isolated. I have started to look for the problem code in the cited STARTUP.FLT, since that will be the clue to the best way to make the L.3 code fully compatible with that and similar STARTUP.FLTs that cause this problem.
I had time to try this jewel out yesterday and it instantly ranks as one of my all-time favorite GA planes! What an absolutely lovely model! Thank you so much Maunuele, for this and all your other planes.
I also have the issue reported in the thread but it is easily fixed by going cold and dark and slewing back to where you want to be.
zmike,
Glad you are onto the problem & hope you can isolate & rectify. 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, but if I skew up to say 1k' & start the engine & recover from the resulting dive, all is again OK.
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.
Must go & do some bedtime reading of your manual now.
Regards
Keith
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.
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.
Zmike,
As far as I can tell looking at your prop graph, you have obviously tuned that to maybe get a uniform acceleration during take off, well done if thats the case either by calculation or empirically. I'm not sure though that that theory holds true for all props & aircraft.
The L3 was obviously fitted with a propeller designed for take off & climb rather than for cruise or high(er) speed, i.e. a fine pitch prop.
As for MSFS, it does seem to require a value greater than zero for the low speed theory limit, otherwise it throws a wobbly.
As for using various values of this limit & have done some empirical tests using AFSD in both FS9 & FSX & within the limits of experiment I concur with your increase in take off roll distances, for a value of zero it took about 310 ft roll, & progressively increased to 400 ft at 80. Not quite linearly.
As the take off speed is 34 Kts (60 fps/65 Km/hr) I would think that 60 is the ideal for me as the definition in the FS9 SDK of this low speed limit is:
'The speed at which low-speed propeller theory gets blended into the high speed propeller theory, (feet/second).'
Old style propellers are notoriously inefficient at very low speed & for example, the use of hovercraft helped develop a low speed theory, & of course human powered flight.
Setting it to this value (60) would not affect demonstrating the error of hand swinging the engine without chocks....a very stupid thing to try!
Anyway it is your work & your decision to apply as you wish, I was just reporting what seems abnormal behaviour.
Keith
Casual use versus learned compliant use of flight simulators
Keith,
This is now moving to a developer to developer discussion about design time issues. My e-mail address has changed since we last conversed, so PM me if you wish to discuss design time issues further via e-mail.
I intend to use this forum to illuminate post download learning opportunities and avoidance of post download input errors. In my two earlier replies I have explained in detail the non compliant consumer input that caused the open cockpit L.3 to crash in the reports provided, and the simple universal means to avoid that consumer input error.
<<As for MSFS, it does seem to require a value greater than zero for the low speed theory limit, otherwise it throws a wobbly.>>
As everyone knows, who is making compliant inputs that do not cause data from two different aeroplanes to co-exist on the memory stack at the same, that is not true. Most of the allegations in forums that MSFS is broken are untrue. The issue is learned compliance.
<<As the take off speed is 34 Kts (60 fps/65 Km/hr) I would think that 60 is the ideal for me as the definition in the FS9 SDK of this low speed limit is: 'The speed at which low-speed propeller theory gets blended into the high speed propeller theory, (feet/second).>>
You have not understood the purpose of 'maximum realism' downloadable content, or the mathematical logic behind delivery of the real take off roll (TOR) to consumers. Since what you are recommending is both illogical and counter productive I must explain why.
This is not a radio control model of an L.3. This is downloadable content that replicates the real airfield performance of the real L.3. It uses a provided STARTUP.FLT to position the L.3 on an obstructed 300 metre grass runway *at altitude*. The downloadable content allows the consumer to witness its real airfield performance, on short grass, in real time, from the driving seat. Importantly that consumer experience depends on their learned compliance using the TERRA - QUOTA control to impose the mixture that delivers peak power. The multiple compliances that the consumer must learn when using 'maximum realism' downloadable content go far beyond developing the discipline to start up the same engine that they shut down.
I have the operating manuals. The consumer does not. This is not a guessing game. I place the consumer exactly where they need to be to understand the real grass airfield performance of this real aeroplane. Then they make compliant inputs, that they learned from the supplied Student Training manual. Some learned inputs require Microsoft software operating compliance, and some require learned real engine operating compliance. Then the consumer invokes my code that delivers the real grass airfield performance, versus their learned compliant (or not) inputs, and the current air density on that alpine airfield. Then they witness the consequence of learned compliance, or non compliance.
Then they can go on to learn the complex doctrine that delivers the multiple concurrent compliances that allow the same flapless, brakeless, aeroplane to land safely over obstructions, nil wind, just below MTOW, on the same 300 metre strip, via a powered or much more demanding glide approach, right down to real Luftwaffe minima.
Each consumer does not have individual thrust values that 'work best for them', in total ignorance of the real airfield performance of the real aeroplane (nil wind at MTOW in ISA on short grass). Meddling with the flight dynamics is just one more casual consumer input error that causes consumer failure to learn real world skills of compliance.
If the intention is to deliver realistic take off distance to Vr, cited in the real manual, then the IAS at which the Microsoft default thrust curve blends to the realistic thrust curve for that specific aeroplane provided by the third party developer, cannot be Vr. IAS = Vr is exactly too late.
The idea that consumers can 'make up' numbers that 'work better for them' is ridiculous.
The underlying issue is your assumption, and the assumption of others in other threads, that all downloadable content contains only a radio control model in which the encoded values deliver no more realism than any real radio control model does. 'Maximum Realism' downloadable content is different and is more demanding of the consumer. The consumer must impose many learned compliances, not make up their own version of what the aeroplane could do, or what the operating doctrine was.
The only thing that meddling to impose; low_speed_theory_limit = 60 delivers, is failure to be able to use the real runway safely, in accordance with a cherished consumer misconception that a '60hp' aeroplane should not cope. It was designed to cope. by A.V.I.A., and then by me. Importantly it will only cope if the consumer learns the real doctrines which are the real concurrent multiple skills of compliance that allowed a Luftwaffe generic aircrew trainee, to pass lead in training, and be selected for further pilot training.
This 'maximum realism' downloadable content opportunity is about far more than learning what an open cockpit L.3 looked like, and what colours it was painted, by watching a model move around randomly. This maximum learning opportunity is about the possibility of consumers learning real basic flying skills, instead of making only casual imaginary inputs, in a random sequence. I fully realise that most will never bother, but that does not mean that no one should make that complex learning opportunity available.
Many real pilots struggle to replicate in desk top simulators, what they achieve more easily in real life, because they have deficient skills of Microsoft software compliance, and so I address that within the documentation of 'maximum realism' downloadable content too.
Flight simulation simply isn't about casually making up random numbers and inputs, in random sequences. Flight simulation is the demonstration of all real world compliances in a virtual environment, down to real world minima.
Moving on from the ideas put forward by 'Dev One'; many readers here will remember that when the Z.506B Airone hydroplane 'maximum realism' downloadable content was released a few months ago consumers in assorted forums immediately announced that the contact or scrape points must be broken and started telling one another that they obviously knew better than the developers how to model both hydroplane stranding, and consumer = pilot error in FS9, by casually and randomly meddling with the aircraft.cfg.
****************************
Take Off Phase and power: //Z.506B
**NEVER EXCEED 2300 GIRI**
FLAP = UP
CARB HEAT = COLD
TRIM = 14 degrees UP <<<<<<<<<
SCREW PITCH = FULL FINE (100%)
LINE = UP
P2 = RETURN TO SEAT (])
THROTTLE = FULL
R = PREVENT YAW
YOKE = FULL AFT UNTIL UNSTICK <<<<<<<<<<
AFTER UNSTICK = NO HUMAN BACKPRESSURE
TRIM = DO NOT VARY FROM +14
ABOVE ALL OBSTACLES
ALWAYS WITIN TWO MINUTES
BEGIN (MAX) CRUISE CLIMB PHASE
*********************************
The Z.506B crew training manual explained;
<<<<During take off PF in an Airone is desperately trying to lift the front of the floats out of the water to reduce the spray thrown through the aircrew arc, but lacks the elevator authority to achieve that at low IAS. Consequently in an Airone *the yoke is held full aft until unstick*. Vr is not calculated. The Airone unsticks when it is ready to fly. Failure to TRIM compliantly may cause a crash, or very prolonged acceleration to unstick.>>>>
The continued 'shaking', beyond low IAS, was reported as developer error, but was the carefully coded 'maximum realism' flight dynamics demonstrating what happens during the pilot error of allowing the nose of the floats to slam into every wave, throwing a wall of water through the wing airscrews throughout the take off.
MSFS is not broken. Consumers do not need to fix it. The issue is learned compliance. Real multiple concurrent compliance equals a real operating doctrine. In the case above a fairly generic twin engine twin float hydroplane operating doctrine that was simply ignored, by consumers who made too little effort to understand the doctrine of compliance. Teaching consumers to remove all indications that they are failing to comply, is the problem, not the solution. Maximum realism flight dynamics exist to quantify the consequence of consumer = pilot error and deliver the quantified outcome. The issue is whether the developer bothers to invoke warning of consumer non compliance, and then also bothers to explain to the consumer, and if relevant illustrate, to the consumer, how to recognise their own errors, so that they can learn to recognise casual non compliance and substitute learned compliance.
That is what 'maximum realism' = 'maximum learning opportunity' downloadable content achieves. In the case of a 'lead in' trainer like the L.3 many of the real world learned compliances are 3D parallax compliances. The consumer must learn what compliance looks like, in order to demonstrate learned compliance to themselves. The consumer must not randomly destroy the ability to take off from the runway they need to use to learn those doctrines and skills via the Student Training Manual.
Everybody needs to think about the carefully integrated nature of downloadable content capable of teaching real world doctrines of compliance and why that content cannot be casually randomised by consumers who only think they understand those compliances and doctrines better than the developers who have been studying the aeroplane, its real multiple compliances, and real operating doctrines, for many months. It is the developer's job to explain real world compliance, and if necessary illustrate real world compliance. The consumer's role is to learn to demonstrate all the real cited compliances, (the real operating doctrine), in a virtual desk top environment, down to the real world minima. In combat aircraft operating doctrine will vary over time, with enemy capability. That will be explained too, and compliance with those real changed doctrines must be learned and demonstrated.
Casually making random inputs instead, in a random sequence instead, before and after engine start, is possible, but explaining that it is possible in forums, is not actually useful.
Mike,
I am trying to understand where you are coming from & aiming to, but unless you can rewrite the FS9 & FSX code, I think there is no need for further discussion, but thank you for your offer of discussion.
Right or wrong, as far as I'm concerned there are many 'fudge' factors added to the base code & the Low speed theory limit is I fear one of them, as I cannot find any reference on propeller theory to have such a factor, which is possibly why it is not really recognised as a training simulator, only a game.
So as I said previously, I was only reporting what I considered to be an abnormal (in FS9 & FSX) behaviour.
Hi Friends,
I just uploaded the FL.3 part 2 (the Closed Cockpit Version).....
"This closed cockpit version, initially conceived for civil use, was used also by the Croatian Air Force, the Luftwaffe and by the A.N.R. (for assault glider pilot training also). Some also served as 'unit hacks' during WW2. This release (Part 2) provides a closed cockpit MDL in many relevant liveries.It also works (Tested) subject to some limitations within in FSX.
A.V.I.A. L.3 (Part 1) (L3_v01-OPEN COCKPIT.ZIP) MUST BE INSTALLED BEFORE INSTALLING THIS PART 2.
VC only.GMax Models and Skins by Manuele Villa, Flight dynamics by FSAviator, Screenshots by Huub Vink.
By Manuele Villa/MVG3D, February 2015.
Ok, i hope nobody will beat me in the head for this, but i decided to try fsx aircraft.cfg in my fs9, for both closed and open cockpit versions and there's no "bouncing" when engine is off and generaly its seems to me that plane is a bit more smoother on the ground. Without much testing i noticed that only difference is "low_speed_theory_limit = 80", which in fs9 version of aircraft cfg is 0, probably it has something to do with previously expressed comments...
Besides that, it most excellent gift!
FS 2004
A.V.I.A. FL.3 Uploaded
Reply With Quote
running to get it.....
Bookmarks