>> I think I already mentioned that one doesn't get enough>prop windmilling drag*. The prop coding results in 'over>>unity efficiency': there is less power extracted from the>airstream than dissipated in Friction Torque ....>That

>>>>One reason tail draggers are notrealistic; you can't steer on the ground by using the propblast on the rudder and you can't get the tail up from theprop blast, either.:)It

>>>>>One reason tail draggers are not>realistic; you can't steer on the ground by using the prop>blast on the rudder and you can't get the tail up from the>prop blast, either.<<<<>>Cn_dT (prop wash on rudder) is alive and well in FS9 Ron. I

>>>>I'll check again. I had increased the effect in the FS2K C208 amphibian so one could stear on the water with the prop blast. It disappeared in FS2K2. I also did the RV7, and liked it much better in FS2K2 than in FS9. In 2K one could still get the tail up (though you didn't get the prop on rudder effect).<<<

>>>>>I'll check again. I had increased the effect in the FS2K>C208 amphibian so one could steer on the water with the prop>>>>> I always figured they were accident's. Such as using GS>Rate instead if Airspeed Rate for the SPD hold in FS2K2 and>not fixed in FS9.<<<<>>Really? Accidents? You

Allcott"Do you really expect simmers to prove that MS is wrong?"Yes I do if they say MS is wrong. Otherwise their statements have little more value the saying "the moon is made of green cheese".Consider some the the statements that have been made in this thread:"The 'Induced prop air flow' L:Var was dead when I checked it." But there isn't such a variable."For one thing, there is no 'variation with Beta' in the Stability Derivatives." This now only relates to Eqn 20 in the paper and not to Eqns 17 through 19, and now means means "If there are tables for variation of a stability derivative relative to Beta, we have never found them." I won't deny thay there may be aspects that MS have simplified (or even over-simplified), but the tables in the air file are only part of the picture. As far as I am aware, no one has reverse-engineered the model itself and established the equations that MS actually use so we don't know exactly what MS is modelling.

My admittedly old text book (The Principles of the Control and Stability of Aircraft" W J Duncan, Cambridge University Press 1952) states in relation to longitudinal stability: "There is, however, a destabilising effect which is usually more important. this is attributable to an increase in the angle of downwash e at the tail associated with a given wing incidence for the factor (1 - de/da) in the contribution of the tail to dCm/da. The destabilising effect is particularly large for twin tractor airscrews and this is connected with the fact that the slipstreams, in passing over the wings, are flattened into a broad band of small depth within and near to which the downwash is particularly intense. It appears that, when the landing flaps are up, the destabilising effect is least when the screws are opposite handed and rotate so that the blades nearest the fuselage are rising. However, this may be the worst arrangement with flaps down and there is theres no case for departing from the usual arrangement with screws rotating in the same direction."Was this effect ever modelled?

>My admittedly old text book (The Principles of the Control>and Stability of Aircraft" W J Duncan, Cambridge University>Press 1952) states in relation to longitudinal stability:>"There is, however, a destabilising effect which is usually>more important. this is attributable to an increase in the>angle of downwash e at the tail associated with a given wing>incidence for the factor (1 - de/da) in the contribution of>the tail to dCm/da. The destabilising effect is particularly>large for twin tractor airscrews and this is connected with>the fact that the slipstreams, in passing over the wings, are>flattened into a broad band of small depth within and near to>which the downwash is particularly intense. It appears that,>when the landing flaps are up, the destabilising effect is>least when the screws are opposite handed and rotate so that>the blades nearest the fuselage are rising. However, this may>be the worst arrangement with flaps down and there is theres>no case for departing from the usual arrangement with screws>rotating in the same direction.">Was this effect ever modelled? Not directly. Variations WRT epsilon have to be accounted for in the Horizontal Tail and other Stabilility Derivatives. However, there are non-linearity tables that modify these parameters WRT Alpha. They include variation in Cm_de, Cm_q, Cm_adot, etc. They do not account for Flaps, Spoilers, or LG. I got carried away thinking of Downwash, epsilon. The below does not apply to the effect described above, but does show some of what has been worked out. I modeled a Canard and made the forward stab stall before the main wing by setting the Horiz Stab tables appropriately. Flight model code that uses stability derivatives and lookup tables probably don't often directly try to calculate downwash. Since the effects can be included in the main SD's. Code as X-Plane uses tries to model such effects, one can see the flow vectors on the screen if he wishes. However, X-Plane isn't all tha accurate, a former version appeard to come up with prop efficiency of only 60%. The prop was analysed similar to the other airfoil sections, one could see the helical airflow near the blades. The fact there is no epsilon in MSFS is demontrated by the fact that AFSD calculates Wing CL and Tail CL from TBL 404, 'CL vs AoA', and from CL_dh * Tail Incidence plus CL_de * Elevator Incidence. That is physical tail incidence, no change for downwash. There are also Mach Variations. Total CL = Wing CL + Horiz Stab CL + Elev CL. In the end, everthing comes out correctly (An adjustment is made for flight slope as far as Weight goes). Including Cdi, which is based on (Total Alpha)^2 * 'Induced Drag Constant". So Drag, Induced = q * Cdi. Flaps, LG, and spoiler are also accounted for. In the end, Drag (calculated) = Thrust (FS parameter). If we didn't know exactly how to account for the airfoil incidences, etc. the Excess Thrust calculation would not come out within 0.3% in constant, level, flight. In fact, AFSD can calculate throttle position for the current or user set flight conditions. That means it has to calculate exact drag (a function of Mach, q, T, etc), then go back through the turbine tables all the way to the throttle. That analysis is used to calcuate True Range; Herve' Sors made a forward integration of drag vs weight as fuel burned to get a value for actual range. However, it assumes constant Mach and FL, so doesn't apply to typical AC operations, but is still useful. Wade Chaffe wrote a small app to read aircraft.cfg and some AIR file tables with FS not running. Using the same approach I gave Herve' to calculate drag. It outputs a big set of FM tables showing Mach, C1, CAS, Weight, FL, NAM, and PPH. He used it in the development of the LDS 757 (767?). However, the app doesn't always give the correct tables for other jet transports. Most AIR file parameters and tables are described quantitively. It took years to figure some of them out; most of the people working on these details are not aeronautical/powerplant engineers. ;) Ron

>>>>Maybe they accidently changed a gain parameter in SIM1.DLL.<<<

>>>>>OTOH, I never could land a J3/J4 safely, they are much>easier to ground loop than any of the FS taildraggers.<<<<>>Depends on the individual plane. A cub with worn gear parts>can be a real handful, and those airplanes have been around>for so long that you

DeltaT is the time-step by which the simulation is required to advance. I suggest the frames/sec will be approximately equal to 1/Delta.If the actual time needed to do the calculation to advance the simulation by deltaT is h, then in order to ensure the simulation advances in real time, deltaT should be set to h. Hence as h gets longer when, for example processing complex aircraft, scenery, weather, etc, the longer h will become and hence deltaT will become longer, with a corresponding fall in frames/sec. That's a very simplistic approach. In real-time modelling there are various techniques that can be used to maintain frames/sec. One of these is to prioritise the variables so that, if neccescary, some may not be calculated every frame, but maybe every other frame, or even less frequently. It is possible that FS gives a low priority to calculating contrails so that they could appear as straight line segments. Any digital simulation proceeds in straight in segements from one frame to the next as shown by Eqn (7) of Zyskowski's paper.

>>>>We had flown up to one of the gold mining towns, he scrapped a wing tip in a limited Ground Loop. Off we walked to find a drug store in town. Bought a roll of cloth bandage to tape up the rip.<<<>>>However, he still didn't want to fly it back; fortunately we hitched a flight back to KSJC.<<<

>>>>>We had flown up to one of the gold mining towns, he>scrapped a wing tip in a limited Ground Loop. Off we walked to>find a drug store in town. Bought a roll of cloth bandage to>tape up the rip.<<<<>>>>>However, he still didn't want to fly it back; fortunately>we hitched a flight back to KSJC.<<<<>Well, if it did that to him without any assistance from a>crosswind, I can