Post by Tom Goodrick on Aug 25, 2008 15:32:27 GMT -5
Notes on FD Development
« on: Jun 10th, 2007, 10:54am » Quote Modify Remove
--------------------------------------------------------------------------------
I'll start a column here on developing the FD for an aircraft. The intent is to hit the highlights and give people an opportunity to ask questions. People have asked me to write a followup to my ebook on FS Flight Dynamics that Abacus published several years ago. Though the basic elements of that book still apply, many specific steps have changed as new versions of FS have come. This discussion will cover only FS9, not FSX which I have no intention of getting into. But, because we can fly FSX aircraft in FS9, it seems likely most FS9 FD files will work in FSX. If they don't, that's too bad. As I was completing my first ebook, based on FS95, FS98 was coming out and some things were changing. That's the way this business goes.
The good thing is that FS9 allows us to do just about everything we need to do to make aircraft fly with considerable realism.
Rather than just going off by myself and writing about this, I'll post notes here. You're input can affect what we end up with. You can show me what I need to emphasize or clarify. In the end I'll put everything together in one package and email it to everyone who expresses any interest. I'd put it on my web site but then the Learn to Fly book would have to go. Maybe it should. We'll try to keep this effort concise.
First, let's discuss our goals in developing FD for an aircraft. My main goal has always been to make the model do all the things the real aircraft is expected to do - takeoff at the right speed, climb at about the right rate, cruise at the proper speeds and altitudes while consumming the proper amiunt of fuel, descend in the proper manner and fly a good approach and landing. It should have exactly the same stall characteristics. Handling characteristics should be reasonable for the type but we can't always insure that. We can make sure that any notable quirks of the real aircraft are evident in the model including such things as a propensity for flat spins from an accelerated stall. Handling during takeoffs and landings should be as realistic as we can make them.
In FS9, the "virtual cockpit" does not work well. The instruments are seldom as easy to read as in the 2D cockpit. Therefore, I always design for the 2d panel as the primary panel. I have designed several panels, one for each basic type of aircraft. Those are the ones I use when test-flying an aircraft. I don't want surprizes in an unfamiliar panel to mess up my flying with a new aircraft that may do strange things. test flying is an obvious and becessary part of developing the FD. Nobody can hit the right numbers the first time.
There are certain specs you need at hand when you start an FD project or even when you examine a new download and may contemplate "fixing" the FD. First, I should say my opinion that the odds are that any download you get will need some FD work. There are many reasons for this. One is that the talent it takes to do the detail wrk of creating a fine design is not the same as the knowledge it takes to work up the FD. Many designers will just leave in the generic FD from a similar aircraft. Thus you end up flying a generic aircraft that looks like the special aircraft you wanted. Another problem that we all have to watch is the developer's learning curve. When you start flying a plane that has had a lot of work done on it, you see many strange things. You fix those you can quickly but this process - flying, pausing, switching planes, editing, saving, switching planes and re-flying - is so tedious that you start over-looking some problems. Or you do mainly air maneuvers and very few takeoffs and landings. Or you do those all at one airport on a clear, calm day. Then you "release the aircraft' and people find all kinds of problems that you either did not see or learned to live with.
Start with the basics - weights (MTOW, EW and MLW), wing area, wing span, aircraft length, a sense of the longitudinal position of the center of lift (which will be ZERO on the X axis). the power or thrust specs on the engine should be known. The main flight performance values are: stall speeds, cruise speed (at a particular altitude), and fuel flow at the cruise speed and power setting. Wing loading (weight divided by wing area) is very important for all of the airspeeds the aircraft will experience - stall, climb, cruise, landing, etc. Every force and moment coefficient must be multiplied by the wing area (and the dynamic pressure) to produce a force. Having the wrong wing area screws everything up. The moments of inertia can be esitimated most accurately given the wing span and the over-all aircraft length. Calculating these in a reasonable way (either a method shown by Microsft in the SDK or another one I will describe) makes a very big contribution to handling in all aspects of flight. Get these right and proper model behavior is assured.
There is a lot of confusion as to what the different files do - aircraft.cfg and name.air (known as the .air file). Start with the .air file. It must be from an aircraft that is similar in type and in landing gear type. If you use a .air file from a fixed-gear aircraft and try to apply it to a retractable-gear aircraft, your model will NEVER be able to show landing gear drag, a very important part of flying the approach. Indeed, when starting to fix any FD problem for an aircraft with retractable gear, check first to see if there is any gear drag. (get in steady flight on autopilot at gear speed and lower the gear. You should see the airspeed decay by several knots. If there is no change, you have this problem. The only solution is to delete that entire .air file and get another one. I have learned this the hard way, losing much time spent tweaking an .air file.
The .air file can only be examined and edited using a special program such as Aircraft Airfile Manager (AAM). The only things required in the .air file are the gear drag coefficient and the spoiler lift drag and pitch increments. These cannot be altered in the aircraf.cfg file. There are many other things that can be set only in the .air file, but, if you have chosen .air file you are familiar with from a similar aircraft, those special things can wait until you start tweaking fine points of the design. A typical value of drag coefficient for the gear is 0.026 to 0.036 depending on complexity of the gear - number of wheels and doors sticking into the wind. In FS we often err on the side of nig gear drag to help us slow down the aircraft. But this is bad because it encourages bad pilot technique. Spoiler drag should be similar to gear drag because pilots have reorted the effects of spoiler deployment are often similar to gear deployment. But that depends on the type and placement of the spoilers. Some mainly add drag while some spoil much of the lift.
The aircraft.cfg file can be edited using Notepad. It is simply a text file. But you must take care to keep the proper format. Two slashes // indicate a line of remarks that won't be read by the sim. It will take a whole special note to explain the parts of the aircraft.cfg file. Some parts are obvious, but many are not. there are often cross effects - changing one thing has an effect on many other aspects of flight. All elements of the aircraft.cfg take precedence over comparable elements in the .air file. Therefore, most of your work will be in the aircraft.cfg file. Indeed, in those instances where I have had to dump an .air file and replace it with one from another aircraft well into the development process, I have ciounted on the aircraft.cfg file preserving most of the character of the specific aircraft.
Also in a future artical, we'll get into the business ofr the lift curve and the stability parameters and their derivatives in the .air file. That is both very interesting and very frustrating. I have called it a "can of worms" and it has proven to be just that in many cases.
Here is a quick run through the development process.
1. Set the gear and spoiler values in the .air file.
2. Put all the weight and geometry values in the aircraft.cfg file.
3. Start with the aircraft parked. Fix it so it does not crash while parked. Don't laugh too hard. This has taken hours in some cases. Here is one place you need to work on balance. The plane may drop its nose or tail in the ground. It may start shaking and suddenly jump into the air and then crash!
4. Make a takeoff. if successful, climb to cruise altitude and get into steady cruise on the autopilot at the proper power setting. This must be done in clear wetaher (no wind, standard temperature).
5. Adjust the parasite (aircraft.cfg scalar) or zero-lift drag (.air file drag coefficient) to get the right cruise speed. (Usually only the aircraft.cfg file is needed.)
6. Check and set the cruise fuel flow (gph or pph). See the old value. Multiply the fuel flow scalar in the aircraft.cfg file by the ratio of correct to old value. Check also for a level attitude at cruise. The fuselage should line up with the horizon. If it doesn't, you must go into the 404 lift table in the .air file and shift everything right or left until the aircraft is level.
7. Check clean stall speed at MTOW. To adjust this, you must move the peak lift coefficient up (to reduce stall speed) or down (to increase stall speed) in table 404 of the .air file.
8. Check full flaps stall speed at MLW. To adjust this you can either adjust the lift coefficient increment in the .air file or the flap lift scalar in the aircraft.cfg file. Add lift to reduce the stall speed.
9. Start flying approaches, landings and takeoffs in sequence. Here is where the drag for the gear and the flaps can be adjusted to give "good" results. Look for gear bounce problems. Some runways are rougher than others. Try takeoffs and landings at several different airports.
10. Get some altitude and do steep stalls, accelerated stalls, straight and in turns and try some spins. Some aircraft should not recover easily from spins. Some aircraft will snap into inverted flat spins when you get rough with them. Here is where you work on the stability values and their derivatives in the .air file. You'll probably die a few times. Have fun! The behavior should be appropriate to the aircraft. This is where anecdotal pilot reports come in handy.
All testing must be done with a panel that shows all important parameters and shows them clearly so there is no doubt what is going on. A panel that is better-suited to the aircraft can be installed after everything checks out. The test panel must include weight, CG, AoA, Turn Test data, all engine instruments, both indicated and true airspeed. The autopilot is used a lot to test in steady conditions. Hand flying is a waste of time until checking for handling problems.
« Last Edit: Jun 10th, 2007, 2:01pm by Tom Goodrick » 216.180.4.228 216.180.4.70
flaminghotsauce
Member
Posts: 680
Re: Notes on FD Development
« Reply #1 on: Jun 10th, 2007, 6:11pm » Quote Modify Remove
--------------------------------------------------------------------------------
Yikes. It sounds like it would take hours of work to start from scratch!
I have yet to mess with an .air file. I need to go back to my old computer and steal off several things I had to put on my lap top. I had a version of the 172 that flew pretty accurately as far as I can tell. The only thing I could find that didn't match my real life experience was the engine RPM settings to maintain a descent on approach. But that's the same as the default 172. I used 1700 in real life, and 1800 on any version of the 172.
On my desktop computer, I had done some steering adjustments, and a few other things. I still need to go in and do all that again.
I am still almost completely stock-install on my lappy. I have a video driver error (I think) that makes twin "whiskers" off my empennage.
I appreciate the ordered list of things to do. This process has to have a logical order to keep chaos to a minimum. It's why I have not tampered with very much at all in either the .cfg file or .air.
72.161.248.198
--------------------------------------------------------------------------------
"Barring all differences, they're identical!"
Tom Goodrick
Administrator
Simaholic
Posts: 3589
Re: Notes on FD Development
« Reply #2 on: Jun 10th, 2007, 11:15pm » Quote Modify Remove
--------------------------------------------------------------------------------
I am glad you mentioned the RPM problem with the 172. It can be very tricky trying to get the rpm correct on an aircraft with a fixed-pitch prop. The key is to adjust the value for the fixed-pitch beta (blade angle) in this line:
fixed_pitch_beta= 19.1 //Fixed pitch angle of fixed pitch prop, (degrees)
This is from my 172SP where I had made an adjustment to get the right cruise RPM. The problem will be getting the rpm right in all phases of flight.
I'd say the typical time to develop the FD for a new aircraft - starting from scratch is about 10 hours in flight time and another similar amount of clock time working things out with notes and checking information. Then if you run into a problem such as a balance problem or a landing gear spring issue and many hours can go by stuck on one thing, This happens when things don't respond to your changes as you expect. Any thing related to the interaction of the landing gear with the ground can get very strange. For example, if you watch a landing very closely, you'll see the aircraft respond to ground contact before the wheels are actually touching. The air gap corresponds to the rate of descent.
« Last Edit: Jun 11th, 2007, 9:04am by Tom Goodrick » 216.180.4.56 216.180.4.69
Tom Goodrick
Administrator
Simaholic
Posts: 3589
Re: Notes on FD Development
« Reply #3 on: Jul 15th, 2007, 12:04pm » Quote Modify Remove
--------------------------------------------------------------------------------
I should add a note to the effect that sometimes things happen in FS9 that HAVE NO EXPLANATION. For example, just the otehr day, I flew an airplane I had not flown in a while. Everything went fine including some accelerated stalls from which recovery was difficult. I flew back to the airport and made a very nice landing. I stopped the sim when I was slowed down to a few knots and starting a turn onto a taxiway. Then, I watched the Instant Replay of the landing a few times checking that the pitch attitude looked proper from early in the approach to the roll out. Then I switched back to the sim to go park the aircraft. It flipped up into the air and then nosed into the ground with debris and smoke coming out of the wreck! I just said a nasty word and shut down the sim. I've seen that before.
Shut down your system and reboot after something like that. You won't see it again for a while.
216.180.4.74
Tom Goodrick
Administrator
Simaholic
Posts: 3589
Re: Notes on FD Development
« Reply #4 on: Jul 15th, 2007, 2:58pm » Quote Modify Remove
--------------------------------------------------------------------------------
NOTES ON MODEL DESIGN AND THE .mdl FILE
Part 1
The process of aircraft model design starts with the use of a special design porgram. There are only two that I know of - FSDS and GMAX. GMAX is a basic 3-D design program. It lets you make individual components and then connect them together in some way the ends up looking like an airplane. I have never used it. But I have noted some things from the results. It seems that the fuselage shell is made with a particular thickness that scales on the order of an inch. With the finished aircraft in FS9, you can put a viewpoint inside and look outward through the cut-out for a window. It looks reasonably realistic if you discount inch-thick walls. There are special programs that come with GMAX that enable the process of making and saving special effects like spinning props and moving gear. They also create the several files needed in FS9 to fly the aircraft.
FSDS is Flight Simulator Design Studio by Abacus. I own this one and have used it to make several aircraft including the Beech Bonanza, the Cessna 340 and 414 twins, the Aerobat, the Parafoil and several others. It also includes a 3-D modelling routine but one tailored especially for building aircraft. You can examine my Aerobat to get an idea of how things work in the design process. Unfortunately, I cannot recommend FSDS for anyone who is not fanatically dedicated to making aircraft because it is terrible to learn to use, even if you know something about designing and building real aircraft. The instructions that come with it - even though it looks like a whole book - are terrible, incomplete and just plain wrong in several instances. To begin with, they took the "standard" X,Y,Z coordinate system and stood it on its ear! Even in FS9, this system is close to the one we all learn in engineering school: X along the centerline of the fuselage (the longitudinal axis), Y along the wing and Z up with all these being mutually orthogonal. But in FSDS X is out the right side, Z is forward and Y is up. It sure is confusing for a while. Why they did that sure beats me.
You begin building a model of the plane by setting simple objects like a box or a cylinder on the axes. Usually you make the fuselage from a cylinder. You pick the length and diameter in real units, the spacing of cross-sectional plates and the number of equally-spaced verticies around each plate. You place this object on the longitudinal axis with the origin at about the 1/4 chord location for the wing. (Exact placement can be easily adjusted later.) You can take each of the plates, from nose to tail and scale it to get a reasonable profile for the fuselage with a windshield, a cabin area and a tail cone. In some cases, such as the Aerobat, the canopies will be made separately and attached after the fuselage is made. FSDS does make it easy for you to select sections through the structure to view and to manipulate. You see lines passing from the nose to the tail around every plate. You can grab a line at a plate and pull it in or out, left or right, to make special little forms in the fuselage. Wings are made from special forms where you specify the span, root chord length and tip chord length. You can select from several airfoil sections you have made up ahead of time. These form the ribs at various spanwise sections as you have specified. With a fuselage sitting on the axes, you just move the wings (left and right) into position so the root sections are inside the fuselage. (The program will take care of forming the joint between the walls of the fuselage and the surfaces of the wings.) You can define various groupings of parts and place them in special component files if desired. Until you have defined them as a whole unit, you can move components around until they "look right." You can even scale entire groups.
Making the prop takes a bit of work. You do have to make a prop blade in 3-D from hub to tip. Then you can copy it into two, three or four positions. You make also a disk which you give a transparent color. This must be the same diameter as the combined set of props. You put the prop set in place and give that a files name. Then you put a copy of the prop rotated at an angle in place and call its file something else. you place the disk in position and call it another file. You then name these files as your prop system. For a twin, you duplicate this file.
Landing gear are built in pieces and assembled in the down position. Doors are built and assembled into position as photos show they should be. This was a little bit tricky on the Bonanza becaues there are two doors in the center between left and right mains that are closed when the gear are up and when they are down. The doors open only during transit of the gear. You must walk the gear and the doors through their particular rotations during a gear cycle recording about four "snapshots" of all positions. The the program lets you run the gear through operation while you look from many different points and angles of view. This is when you find that a wheel sticks up through the wing when in the "up" position. (You also find that when you are test flying the airplane later.)
You make the cutouts in the wings for the flaps and ailerons and save them as separate pieces. One thing you learn is that you must make interior surfaces for the inboard edges of these surfaces and the corresponding edges in the wing which will show during certain motions. Each surface in FSDS has an inside and an outside surface. You will see the surface only from the outside. If there is a possibility you might see a surface from both sides when looking at the airplane while it is flying, you must make a double surface, each have opposite "outside surfaces." This is why you will see some very strange things looking at the aileron gaps in a flying plane. I screwed up on the Bonanza by not making movable "ruddervators" because I could not see how to do it. Later I saw another guy's work and asked him how he did it. It was astoundingly simple. When animating a surface such as a rudder, elevator, flap, or aileron, you assign a control to that surface such as "rudder" for the rudder. I was too stupid to realize you can assign two controls to the same surface! Maybe I'll fix it one of these days.
In FSDS it is a bit more work to make possible a view of the inside of the airplane that you see from the cockpit. The normal event which I experiened with my Bonanza was to go flying and see nothing of the inside of the aircraft though I could see the wings and the nose cowling where they should be. I could even see the ailerons and watch them move. To see the inside, you must build a separate inside surface of the cockpit. This is some work but not too bad. You copy the whole fuselage into a separate workspace. Then you chop off the nose and tail and install bulkheads. Then you go around to each polynomial in the frame (poly's are formed between the lines and the edges of the plates (which are invisible)). Each poly has a surface normal vector indicating which way is "outside". A command lets you view all those vectors. You select several and "flip" them so they point oppositely. Now you have an inside surface for the complete fuselage. bring this structure back into the normal workspace and merge it with the rest of the aircraft. Go fly it and look outside from the pilot's point of view. You will see portions of the interior and portions of the exterior such as the wings. They all look very realistic.
Then you fly the same plane into some scenery areas such as the Alaskan scenery of our friend Jim Bertleson, and your fuselage walls become invisible in some scenes but not in all. One minute you are wram and comfortable in the cockpit looking through a window at the ice and cold sea. The next you see no protection around you from the cold! It can be enough to drive you out of the business.
216.180.4.74
Tom Goodrick
Administrator
Simaholic
Posts: 3589
Re: Notes on FD Development
« Reply #5 on: Jul 15th, 2007, 3:06pm » Quote Modify Remove
--------------------------------------------------------------------------------
NOTES ON MODEL DESIGN AND THE .mdl FILE
Part 2
All the component motions are recorded in code in the .mdl file. You cannot ever examine this file, not even when doing the designing. As you build a model, there are many files produced that stay in the design space for the program. You save these, of course. When you see something on your aircraft that does nopt look right, such as an overly large aileron gap, you can go back into the design program and change it and then save the result. But no one else can ever do it unless you give them all the design files. Even then they would not know which files you used in what components or what is in the various component files. I would even have trouble going back into an aircraft I built four years ago.
For anyone who wants to try building an aircraft, model, I'd say you should buy the latest and best aircraft design program around (you have to figure out which one) and also get a plastic model of the airplane and put it together first, to the same level of detail you want in the final FS model. Then keep a rule handy that will read scale lengths off the model. A calibrated eyeball helps. I did that with the Bonanza. With the other aircraft I built, I only had photos but there were several of them from several articles including 3-view drawings in some cases. in the case of the Aerobat, I had some photos and drawings of several unlimited aerobatic aircraft and just designed the model as I went based on some engineering calulations for wing size and shape and other components. It differs from most such aircraft by having retractable trike landing gear. I simply prefer that. I wanted a sleek design for doing vertical rolls with low deceleration. It also tumbles well.
There are some things you can edit into the aircraft.cfg file that will have an effect on the model animation. For example, I recently set a max flap angle of 60 degrees on the Citation Jet. This exposed some ugly parts inside the wing. The original designer did not know the flaps were supposed to go to 60 degrees. He never even looked at them when set at 60 degrees.
Like everything else related to the Microsoft Flight Simulators, there are mysterious things about this work that come and bother you every once in a while. So it goes.
Painting seems to be easy for some but I find it difficult. I can draw a decent pattern in 2-D. My problem is wrapping it around the object and getting everything to come out like it should. I am obviously doing something wrong because I know most painting is done as 2 D projections. I was able to paint the few aircraft I have done using basic generic airplane paint schemes. But I have great trouble trying to paint other people's aircraft, even to just paint new numbers on the side. There is some mysterious program you need that will make sure your new paint file is in the correct resolution. When I paint a texture file on an aircraft made by someone else, it is never seen again! I mentioned this once a few years ago and a certain blithering idiot yelled at me saying that "You don't have to paint numbers on the side of aircraft. Just change the number when you load the aircraft within the sim." That only works with certain aircraft built using GMAX. Now he does his blithering somewhere else while I do mine here.
Incidentally, if you have tried to load an aircraft made for FS2000 or FS2002 into FS9, you have seen the box warning you that the model contains some nasty code that MS would like to block. JUST SAY NO! That will disable things like your gear and prop. I have never seen a case where such animations, done by software by a company other than Micro$oft di in fact harm your sim in any way. But I have seen or heard of many inoperable props and landing gear. The problem is that you cannot simply re-install the same plane and then say "No!" Micro$oft writes a little note in FS9.CFG namineg that airplane as a bad one. You must find that note and remove it before you can re-install the same aircraft. Aren't they nice people?
216.180.4.74
Tom Goodrick
Administrator
Simaholic
Posts: 3589
Re: Notes on FD Development
« Reply #6 on: Jul 15th, 2007, 9:48pm » Quote Modify Remove
--------------------------------------------------------------------------------
This is just short note about the Microsoft Aircraft Container Software Developer's Kit, lovingly known as the ACSDK for FS9. This is free from microsoft's web site. Everyone should have a copy. There is a similar SDK for panel designers that is absolutely necessary if you intend to design or to modify gauges. The main thing the ACSDK does is make some sense out of the lines in the aircraft.cfg file. The first time you go through this document, you should have a copy of the aircraft.cfg file for a default aircraft you have flown ready to look at for examples of how the commands in the SDK are actually implemented by Microsoft's FS staff. The Baron would be a good aircraft to use.
There is one basic theme that is repeated throughout this document. It assumes that you are going to use FSEDIT to modify the aircraft.cfg file and that these notes are merely information so you don't get confused should you ever be confronted by the aircraft.cfg file as a text file (which it is, of course). They claim that there are many lines in the aircraft.cfg file where parameter values modify parameters in the .air file that WILL NOT TAKE EFFECT until you run FSEDIT. I have not found ANY instance where this is true. I have not used FSEDIT since it first came out several versions ago. Then I used it once to change payload weights (before they put station weights in the menu of FS) and found that it messed up other station weights I was not changing. I also found it was setting things in the .air file that I did not want to set. I refuse to use software that changes things in files without telling me and things that it is not supposed to be touching. One thing they clearly state, as an example, is that changing the parasite drag scalar will have no effect until you run FSEDIT. That is clearly not true because I do it all the time.
But they also say that, to make edits take effect quickly, you can define a key sequence that will reload the aircraft, thus effecting the change of any edits in the aircraft.cfg file. Many others have reported, as I have that this does not work. You must load another aircraft and then load back in the aircraft you have edited. When this happens your pitch trim setting is reset to zero so you will get a bump in your flight if you do not remember the setting and put it in manually 9using the 1/10 digit in the decimal value. But you certainly do not have to run FSEDIT. I don't even have it on my system so I can't play with FSEDIT.
It becomes clear that a whole bunch of people having various aviation backgrounds work at Microsoft. In some places in the sim they show evidence they know what they are doing. In other parts, they show utter and complete ignorance. An example i in the SDK and the aircraft.cfg file under [reference_speeds] where they state very clearly with exclamation that the stall speeds are to be entered in knots, true airspeed (KTAS). If this were true you could not fly safely at altitudes above zero. The fact is, as every student pilot learns very quickly, stall speeds must be given in Indicated Airspeeds or KIAS.
There are two other areas in the aircraft.cfg file that are purely bogus and the explanation in the SDK proves it. One is with respect to the cruis_lift_scalar in the [flight_tuning] section. the supposition is that you will find it useful to change this parameter from 1.0 in order "to give the proper lift at cruise."
Their exact explanation is: regarding cruise_lift_scalar=
The following parameter is a multiplier on the coefficient of lift at zero angle of attack ("cruise lift" in this context refers to the lift at relatively small angles of attack, which is typical for an airplane in a cruise condition). This scaling is decreased linearly as angle of attack moves toward the critical (stall) angle of attack, which prevents destabilizing low speed and stall characteristics at high angles of attack. Modify this value to set the angle of attack (and thus pitch) for a cruise condition.
This is total balderdash. Don't touch this parameter. I erase it from all files I see. Elsewhere in the document they mention this is related to the viewed pitch angle in cruise. That pitch angle in cruise should be fixed by the wing incidence angle as it is on all real aircraft. But the "management decision" was made to make the incidence angle constant at 1.5 degrees in FS9. I cannot imagine such a mixed up situation where this was worthy of a management decision. It certainly would have no effect on computation time or memory utilization. So the only way we can fix the cruise pitch angle is to shift the lift table #404 along the x axis. This must be done only to those values of lift from zero to stall. It is a bit of pain but it simply involves subtracting a constant such as 0.002 from the x axis values at several points.
There is only one more example of pure balderdash in the SDK. That is regarding the section in the aircraft.cfg file called [airspeed]. This section and its single line must also be deleted. You'll find it prominently only on the file for the Cessna 182 Skylane. in revising the FD for the Skylane so it would meet the performance specs mentioned by Cessna on their web site, I found some difficulty caused by this line. The explanation is that this permits the user to enter a scalar and an offset to convert the indicated airspeed to calibrated airspeed. Cessna uses calibrated airspeed in their stall specs which is very unusual because a pilot cannot ever see the calibrated airspeed. He can open the manual and find a conversion table but he will seldom do that when wondering whether or not he will stall! Calibrated airspeed is otherwise used only when first flight testing an aircraft. It is measured by a pitot tube extending far out in front of the aircraft (either from the nose or from the wing tip where it sees flow undisturbed by any part of the aircraft. As flow gets closer to the aircraft where normal pitot tubes are installed, it slows down, especially at high angle of attack where stall will occur. I have two airplane owner's manuals for planes I used to fly. I never owned these but had to buy the manual in order to transition to the aircraft. (They are are for the American Model AA-1A trainer and the Cessna 172.) Both contain tables showing the relation between caibrated airspeed and indicated airspeed. Both are nonlinear. You could not possibly set the parameters in the [aispeed] line to perform these calibrations. if you set it at one end, it would be off at the other end. You are best off assumming that calibrated airspeed equals indicated airspeed which is what happens by default when you delete these lines.
There is yet another section that has been peculiar for years but I just ignore it. It lets you set the delay in the vertical speed indicator. There really is not much of a delay in that indicator. Modern instruments may not have any. In old instruments, that need no electrical power, the vertical speed is measured by taking the air from the static source on the side of the plane that feeds the ailtimeter and the airspeed indicator and splitting it so that one side passes through a narrow part that delays it before both tobes then enter opposite sides of a diaphram. The fact that old air is compared with new air gives you an indication of the rate of change of pressure which is proportional to the rate of climb. This delay was of the order of 2 seconds which is what is often specified for this vertical speed delay. But if you are climbing steadily and then level off, the delay would only be slightly significant when levelling off and then you'd not notice it in the temporary upset that always occurs when you make the change from climb to level flight. The fact is that today, electronic sensors can be used that will electronically determine the rate of change of pressure having no delay at all.
Another cute thing is with the two sections [attitude_indicators] and [turn_indicators]. These set whether your gauges are driven by vacuum or by electricity in case of a failure of one of those systems. Aircraft that are well-prepared for IFR flight will have two such indicators, one depending on vacuum and one on electricity. But in FS we only have room on the panel for one indicator so these lines seldom have mening. For what it is worth, though, Microsoft has managed to screw this up. The line for the attitude indicators has 1 for Vac and 2 for Elec. The one for the Turn indicator has 1 for Elec and 2 for Vac.
I did learn a nice new thing tonight that I might try to use and see if it really works. It is the line for [directional_indicator] which has a 1 for Vac Gyro and a 2 for Elec Gyro but also a 3 for electro-mag slaved Compass. Your normal cheap directional gyro (DG) most of us have flown with can only hold its bearing for a few minutes. Then as long as you are steady and level, you look at the compass and reset the DG to agree with the compass. You do this before starting any prolonged turn because you want to use the DG during the turn as the mag compass either leads or lags the turn. Long ago I elected to select the "Zero Drift Gyros" so I do not have to go through my sim flying career tapping D to reset the gyro. I knew there were fancy instruments that slaved the DG to a compass so it would get automatic periodic updates from the compass when in steady flight. Evidently you can set this value to 3 and get just that. I'll soon see if it works. (Of course, the new glass cockpits get away from this altogether with their AHRS's. See my notes on digital panels for info on that.)
Well, have fun with your SDK's. We shall discuss the aircraft.cfg file in more detail, covering the important parts next.
216.180.4.145
Hans_Petter
Member
Posts: 424
Re: Notes on FD Development
« Reply #7 on: Jul 18th, 2007, 10:52am » Quote Modify Remove
--------------------------------------------------------------------------------
Just a quick note on paint jobs, it largely depends on the texture mapping. The 3D model comes with a texture map that defines where the textures you see in your paint program are supposed to go. Elaborate paint jobs are hard to accomplish unless the texture mapping is detailed enough to allocate separate textures to separate parts. What happens with an insufficient texture mapping is that the textures are stretched and skewed to drape the entire 3D model. To some extent pixels will be stretched in all cases and the texture file will have to be modified to counteract the stretching and skewing. Anyone who has looked at texture files will have noticed skewed images that come out right when the model is viewed in the sim. Pilots' faces come to mind. That is, in order to draw a straight line it will have to be curved, provided it's supposed to texture a curved surface. I know of no way to approach this other than old fashioned trial and error. If the numbers look too tall, shorten them in the texture file. If the straight line curves, try to curve the texture image line in one direction and see what happens. Elaborate logos may need to be skewed (compressed or stretched) along one axis to make them look right. It's all a question of fitting a 2D image unto a 3D surface. Thus, the more the textured surface curves the harder it is to fit a 2D image unto it and make it look right.
222.123.156.242
--------------------------------------------------------------------------------
best regards,
Hans Petter
Allen_Peterson
Member
You gotta Keep a-Goin'
Posts: 157
Re: Notes on FD Development
« Reply #8 on: Aug 7th, 2007, 7:01pm » Quote Modify Remove
--------------------------------------------------------------------------------
This has been bugging me for some time. Maybe writing this out will help me get it straight in my mind. Reference_datum_position is defaulted to 1/4 chord aft of the leading edge unless specified otherwise, say 3.6, 0, 0 (maybe the nose). Then, for example, wing_pos_apex_lon (assuming a straight wing) would be measured back from the nose. If reference_datum_position were 0,0,0 then wing_apex_position would be 1/4 chord forward. htail_pos_lon and vtail_pos_lon would be measured the same way, either back from the nose or back from 1/4 chord (0,0,0). And longitucinal positions for contact points would be measured the way?
76.182.131.116
--------------------------------------------------------------------------------
Have a good day.
Allen
Tom Goodrick
Administrator
Simaholic
Posts: 3589
Re: Notes on FD Development
« Reply #9 on: Aug 7th, 2007, 10:17pm » Quote Modify Remove
--------------------------------------------------------------------------------
Congratulations. You have identified a tricky point in FS that takes some careful study although it might seem to be simple. It is not simple. I am just now, with the help of your question, getting it all together. I think you'll find this interpretation makes sense.
We'll try this piece by piece:
"Reference_datum_position is defaulted to 1/4 chord aft of the leading edge unless specified otherwise..."
That is not a good way to put it. The sim internally requires mass points to be given coordinates where X is zero at the 1/4 chord point aft of the "apex" of the wing. Points ahead of that point have positive X values and points aft of that point have negative values. The purpose of the ref datum is to provide an offset that can be used to convert real aircraft coordinates in to FS coordinates. Those who have a pilot's hanbook of "POH" for an aircraft, would want to set the coordinates for weight positions in an FS model the same as in the real aircraft. This lets them do that.
The coordinate stated for each weight point is added to the ref datum to get the FS coordinate of the weight point. Take three examples:
C172 Xref = 3.6 and EWX = -3.0. Then FS coord of EWx is 3.6-3.0 = 0.6.
C340 Xref=0 and EWx=0.50
FS coord of EWX = 0+0.5 = 0.5
Baron 58 Xref=6.96 and EWx=-6.06
FS coord of EWx = 6.96-6.06 = 0.90
"Then, for example, wing_pos_apex_lon (assuming a straight wing) would be measured back from the nose."
No, like all other coordinates, it is added to the Xref to get the FS coord. The purpose of this value is to show where the wing fits on the fuselage in relation to the BIG ZERO POSITION or origin of the FS coordinates.
Again we can get help from some examples.
In my C340, I built the airplane around the point that later became the 1/4 chord point. That was my origin of coordinates. So Xref=0 and the value for the wing_pos_apex_lon is 1.28 which is 25% of the root chord (it should be mean chord on a tapered wing but it is the root chord). That value is +1.28 because the apex or leading edge is 1.28 ft forward from BIG ZERO.
In the C172 with Xref=3.6, the value of wing_pos_apex_lon is -2.4. Add that to the xref and you get +1.2 which puts the leading edge 1.2 ft ahead of BIG ZERO. (That's 1/4 the root chord.)
In the Baron 58, Xref=6.96 and wing apex is at -5.6. Add the Xref and the FS coordinate is 1.36 meaning the leading edge is 1.36 ft ahead of the BIG ZERO.
The FS coordinate system has a long historical basis through many versions although there was a shift between FS2002 and FS2004 (FS9). Before FS9, the wing apex position was not used. that has caused some problems.
I prefer not to use a non-zero reference datum. The reason is that all the positions identified in all sections of the aircraft.cfg file must be in the same consistent coordinate system - weight stations, aircraft components, engines, fuel tanks and contact points. positions relative to "Big Zero" are what matter to the stability of the aircraft in the sim and it is hard to fihure that if you have a non-zero reference.
So now it is all clear - right? Good. Now you can explain to me how there are inconsistencies in CG position. I did a little calculation using simple geometry some time ago and got very confused. There seemed to be a mysterious "X factor!" Recently with the CitationJet where I was trying to match real world data supplied by Dustman, a pilot of the CJ, I ran into a case where a setup in the aircraft.cfg file was completely messed up when I had to switch to another .air file.
There may be things here that we mortals were not meant to understand!
216.180.4.82
Tom Goodrick
Administrator
Simaholic
Posts: 3589
Re: Notes on FD Development
« Reply #10 on: Aug 10th, 2007, 10:22am » Quote Modify Remove
--------------------------------------------------------------------------------
In the section on "Citation Jet Revisited" I worked through the complete problem of calculating the center fo gravity for an FS aircraft and getting it to agree with the same calculation on a real aircraft. But, in looking back at it, there are a few gaps in the math that are not very clear. Between what was written in that section and what is in my hand-written notes from that time, I think I can work out a generic summary of the equations needed. I'll get busy at it.
216.180.4.60
Cam G.
Member
N41BE: in memoriam
Posts: 16
Re: Notes on FD Development
« Reply #11 on: Aug 11th, 2007, 11:20am » Quote Modify Remove
--------------------------------------------------------------------------------
I have worked with .cfg files quite a bit, but have always wondered about some items listed: "Reference Speeds" are given for stall and cruise speeds. Does the .air file read and apply these?? I would assume that changing the wing span/area, gross weight and other physical parameters would change the stall speed--just as in real aircraft. Why are Reference Speeds in the .cfg file if the other stuff defines the stall behavior?
A similar one is the "Horsepower" entry. Does changing this value change the horsepower of the model? Again, the "real" way to modify an engine would be to make changes in the number of cylinders, displacement and compression ratio (and making it turbocharged). Is the "Horsepower" value used by the .air file?
Last item: What does "gain on fuel flow" affect? I tried increasing it and reducing it about 30%, but didn't detect any flow change cruising at altitude. MS SDK defines "Gain on Fuel Flow" as the gain on fuel flow...thanks, MS, that was helpful!!
12.162.217.254
Tom Goodrick
Administrator
Simaholic
Posts: 3589
Re: Notes on FD Development
« Reply #12 on: Aug 11th, 2007, 3:11pm » Quote Modify Remove
--------------------------------------------------------------------------------
There are some aspects of these reference speeds you can use and some you can ignore.
[Reference Speeds] // (Baron 58)
flaps_up_stall_speed = 84.0 //Knots True (KTAS)
full_flaps_stall_speed = 75.0 //Knots True (KTAS)
cruise_speed = 200.0 //Knots True (KTAS)
max_indicated_speed = 223 //Red line (KIAS)
First you can ignore the note from the ignorant folks at MS that the stall speeds are in KTAS. They are in KIAS. They do have something to do with stalling the airplane but I don't know why they should. One day I was working on the stall speed for an aircraft that had them set too low. I was adjusting the max lift coefficient in Table 404 of the .air file as one would normally do the trick. I was also adjusting the two stall warning conditions in the .air file - one based on speed and one based on angle of attack. I knew it wanted to stall at the right speeds. Finally I changed the clean stall speed in this reference set and it worked fine.
The cruise speed is used when you use the navigator log feature to estimate the time it will take to fly a planned flight. For that reason it helps to set this one at least close. Of course we all know there are many cruise speeds for any aircraft, based on high/low and light/heavy. Pick one. And you can belive the KTAS. This really is in True Airspeed as are all cruise speed specs.
The max indicated speed is VMO or VNE. Make sure this is close after looking up data on the plane. It will activate the overspeed warning if you exceed that speed.
You are right that the geomtry you might change would have a significant effect. Neither the cruise speed or the max indicated speed have any effect on flight. The overspeed warning just makes noise.
For a long time I thought the horsepower setting made sense. I still don't understand why MS does not use it to tune up engine settings. But they don't. You can double it and your speeds won't change a bit. Still, I like to set it correctly just so it looks right.
The main thing it does affect is your next question - fuel flow. The first thing I dod with an aircraft that needs FD adjustment is climb it up to the altitude for which I have a cruise speed spec. I also have a fuel flow for this condition. (If I don't have these specs, I prefer not to work on the aircraft. But you can work out a fuel flow if you have range information at the same cruise condition.) For the Baron 58, these specs are 203 KTAS at 5,000 ft using 210 lb per hour (total, 105 or 15.7 gph from each engine). With the powere set at 75% (25 inches and 2500 rpm for the Baron and many other aircraft), I look for the right cruise speed. On the default Baron 58 I didn't find it so I reduced the drag - either the parasite drag scalar or the zero lift drag in section 1100 of the .air file will work equally effectively.
When the true airspeed at cruise is correct (use either the GPS in no-wind conditions), then note the fuel flow per engine. Say it is 17.3 gph when it is supposed to be 15.7 gph. You solve this problem exactly and quickly by going to the following section in the aircraft.cfg file.
[GeneralEngineData]
engine_type = 0 //0=Piston, 1=Jet, 2=None, 3=Helo-Turbine, 4=Rocket, 5=Turboprop
Engine.0 = -1.4, -5.3, 0.0 //(feet) longitudinal, lateral, vertical distance from reference datum
Engine.1 = -1.4, 5.3, 0.0 //(feet) longitudinal, lateral, vertical distance from reference datum
fuel_flow_scalar= 0.9 //Fuel flow scalar
By default this fuel flow scalar would be 1.0. if other people have messed around with the file all right it could be anything. You calculate a correction factor of 15.7 / 17.3 (new over old) and multiply that by the existing scalar and use the result. I have read that this does not work. It always has worked for me.
By the way, setting a non-zero minimum throttle limit keeps the engine from dying while you taxi.
I am sure you know there are many types of .cfg files for each aircraft. All are really just text files and can be edited by Notepad. The two we most often change are the aircraft.cfg and the panel.cfg files. Sometimes it is fun to tweak a sound.cfg file.
In their SDK, the gurus at MS have given many instructions that are totally worthless. At MS there are some Twits and some Ni Twits and a few people who do know what is going on. The trouble is they seldom talk to each other. In the SDK they assume they are writing for dumb code writers like themselves.
If you have studied a lot of math as I have, you might be confused by the term "scalar" as used by the original developer of the Flight Simulator and perpetuated by Microsoft. I had certainly heard of and used scalers as opposed to vector quantities. A scaler has only magnitude while a vector has both magnistude and direction of application. Scalers are sometimes used as multipliers for vectors and matrices. in matrices they apply to all elements of the matrix.
So where did "scalar" come from and what does it mean? Just consider it a factor to be multiplied by whatever parameter it relates to. A scalar of 1.1 increases something by 10%. A scalar of 2 doubles it. The guy who wrote Flight Simulator was working on a Master's Thesis in Electrical Engineering. How this relates to that beats me, but, those guys have their own terminology.
« Last Edit: Aug 11th, 2007, 3:26pm by Tom Goodrick » 216.180.4.73
Cam G.
Member
N41BE: in memoriam
Posts: 16
Re: Notes on FD Development
« Reply #13 on: Aug 12th, 2007, 7:12pm » Quote Modify Remove
--------------------------------------------------------------------------------
Tom, When I was talking about fuel flow I was referring not to the fuel_flow_scalar in [GeneralEngineData], but the fuel_flow_gain in [TurbineEngineData]. It only applies to turbine aircraft, apparently. The Boeing 777 shows a value of 0.002, while the Cessna Caravan shows a value of 0.011. Its bugging me as to what this affects.
12.73.130.123
jcomm
Member
Easily lose my mind about women and aircraft...
Posts: 208
Re: Notes on FD Development
« Reply #14 on: Aug 13th, 2007, 9:21am » Quote Modify Remove
--------------------------------------------------------------------------------
Allow me
It's a somehow non-intuitive name, as usual in the MSFS SDK.. It ** only ** controls spool rate, and re-shapes de default 1505 Tbl ("Turbine Corrected FF vs. CN2).
If you edit that table you'll notice it's steeper near the beginning (low CN2 values) and converges near the end. The steeper the slower throttle changes affect fuel injection into the combustion chamber and thus slower spool up speed.
The parameter affects the shape of the graph.
You'll get the "big picture" from Jerry's graph:
www.mudpond.org/jet_flow_chart.pdf
And since you're there, download also:
www.mudpond.org/fs_props.pdf
for a nice explanation of Propeller Tables...
If you're really after the "Internals" of MSFS, you have the right site here:
perso.orange.fr/hsors/index.html
In Hervé's "Airfile Documentation" section:
perso.orange.fr/hsors/fsdocs.html
make sure you visit each link...
And... download/install/use & abuse AFSD, one of the best tools we have to depict what's going on inside of MSFS. Latest version works for both fs9 and fsX - both require FSUIPC!
Hervé is a RW pilot, a great programmer, and someone with deep knowledge of MSFS.
« Last Edit: Aug 13th, 2007, 9:36am by jcomm » 193.137.20.1
--------------------------------------------------------------------------------
############################
jose carlos monteiro
Lisboa - Portugal
« on: Jun 10th, 2007, 10:54am » Quote Modify Remove
--------------------------------------------------------------------------------
I'll start a column here on developing the FD for an aircraft. The intent is to hit the highlights and give people an opportunity to ask questions. People have asked me to write a followup to my ebook on FS Flight Dynamics that Abacus published several years ago. Though the basic elements of that book still apply, many specific steps have changed as new versions of FS have come. This discussion will cover only FS9, not FSX which I have no intention of getting into. But, because we can fly FSX aircraft in FS9, it seems likely most FS9 FD files will work in FSX. If they don't, that's too bad. As I was completing my first ebook, based on FS95, FS98 was coming out and some things were changing. That's the way this business goes.
The good thing is that FS9 allows us to do just about everything we need to do to make aircraft fly with considerable realism.
Rather than just going off by myself and writing about this, I'll post notes here. You're input can affect what we end up with. You can show me what I need to emphasize or clarify. In the end I'll put everything together in one package and email it to everyone who expresses any interest. I'd put it on my web site but then the Learn to Fly book would have to go. Maybe it should. We'll try to keep this effort concise.
First, let's discuss our goals in developing FD for an aircraft. My main goal has always been to make the model do all the things the real aircraft is expected to do - takeoff at the right speed, climb at about the right rate, cruise at the proper speeds and altitudes while consumming the proper amiunt of fuel, descend in the proper manner and fly a good approach and landing. It should have exactly the same stall characteristics. Handling characteristics should be reasonable for the type but we can't always insure that. We can make sure that any notable quirks of the real aircraft are evident in the model including such things as a propensity for flat spins from an accelerated stall. Handling during takeoffs and landings should be as realistic as we can make them.
In FS9, the "virtual cockpit" does not work well. The instruments are seldom as easy to read as in the 2D cockpit. Therefore, I always design for the 2d panel as the primary panel. I have designed several panels, one for each basic type of aircraft. Those are the ones I use when test-flying an aircraft. I don't want surprizes in an unfamiliar panel to mess up my flying with a new aircraft that may do strange things. test flying is an obvious and becessary part of developing the FD. Nobody can hit the right numbers the first time.
There are certain specs you need at hand when you start an FD project or even when you examine a new download and may contemplate "fixing" the FD. First, I should say my opinion that the odds are that any download you get will need some FD work. There are many reasons for this. One is that the talent it takes to do the detail wrk of creating a fine design is not the same as the knowledge it takes to work up the FD. Many designers will just leave in the generic FD from a similar aircraft. Thus you end up flying a generic aircraft that looks like the special aircraft you wanted. Another problem that we all have to watch is the developer's learning curve. When you start flying a plane that has had a lot of work done on it, you see many strange things. You fix those you can quickly but this process - flying, pausing, switching planes, editing, saving, switching planes and re-flying - is so tedious that you start over-looking some problems. Or you do mainly air maneuvers and very few takeoffs and landings. Or you do those all at one airport on a clear, calm day. Then you "release the aircraft' and people find all kinds of problems that you either did not see or learned to live with.
Start with the basics - weights (MTOW, EW and MLW), wing area, wing span, aircraft length, a sense of the longitudinal position of the center of lift (which will be ZERO on the X axis). the power or thrust specs on the engine should be known. The main flight performance values are: stall speeds, cruise speed (at a particular altitude), and fuel flow at the cruise speed and power setting. Wing loading (weight divided by wing area) is very important for all of the airspeeds the aircraft will experience - stall, climb, cruise, landing, etc. Every force and moment coefficient must be multiplied by the wing area (and the dynamic pressure) to produce a force. Having the wrong wing area screws everything up. The moments of inertia can be esitimated most accurately given the wing span and the over-all aircraft length. Calculating these in a reasonable way (either a method shown by Microsft in the SDK or another one I will describe) makes a very big contribution to handling in all aspects of flight. Get these right and proper model behavior is assured.
There is a lot of confusion as to what the different files do - aircraft.cfg and name.air (known as the .air file). Start with the .air file. It must be from an aircraft that is similar in type and in landing gear type. If you use a .air file from a fixed-gear aircraft and try to apply it to a retractable-gear aircraft, your model will NEVER be able to show landing gear drag, a very important part of flying the approach. Indeed, when starting to fix any FD problem for an aircraft with retractable gear, check first to see if there is any gear drag. (get in steady flight on autopilot at gear speed and lower the gear. You should see the airspeed decay by several knots. If there is no change, you have this problem. The only solution is to delete that entire .air file and get another one. I have learned this the hard way, losing much time spent tweaking an .air file.
The .air file can only be examined and edited using a special program such as Aircraft Airfile Manager (AAM). The only things required in the .air file are the gear drag coefficient and the spoiler lift drag and pitch increments. These cannot be altered in the aircraf.cfg file. There are many other things that can be set only in the .air file, but, if you have chosen .air file you are familiar with from a similar aircraft, those special things can wait until you start tweaking fine points of the design. A typical value of drag coefficient for the gear is 0.026 to 0.036 depending on complexity of the gear - number of wheels and doors sticking into the wind. In FS we often err on the side of nig gear drag to help us slow down the aircraft. But this is bad because it encourages bad pilot technique. Spoiler drag should be similar to gear drag because pilots have reorted the effects of spoiler deployment are often similar to gear deployment. But that depends on the type and placement of the spoilers. Some mainly add drag while some spoil much of the lift.
The aircraft.cfg file can be edited using Notepad. It is simply a text file. But you must take care to keep the proper format. Two slashes // indicate a line of remarks that won't be read by the sim. It will take a whole special note to explain the parts of the aircraft.cfg file. Some parts are obvious, but many are not. there are often cross effects - changing one thing has an effect on many other aspects of flight. All elements of the aircraft.cfg take precedence over comparable elements in the .air file. Therefore, most of your work will be in the aircraft.cfg file. Indeed, in those instances where I have had to dump an .air file and replace it with one from another aircraft well into the development process, I have ciounted on the aircraft.cfg file preserving most of the character of the specific aircraft.
Also in a future artical, we'll get into the business ofr the lift curve and the stability parameters and their derivatives in the .air file. That is both very interesting and very frustrating. I have called it a "can of worms" and it has proven to be just that in many cases.
Here is a quick run through the development process.
1. Set the gear and spoiler values in the .air file.
2. Put all the weight and geometry values in the aircraft.cfg file.
3. Start with the aircraft parked. Fix it so it does not crash while parked. Don't laugh too hard. This has taken hours in some cases. Here is one place you need to work on balance. The plane may drop its nose or tail in the ground. It may start shaking and suddenly jump into the air and then crash!
4. Make a takeoff. if successful, climb to cruise altitude and get into steady cruise on the autopilot at the proper power setting. This must be done in clear wetaher (no wind, standard temperature).
5. Adjust the parasite (aircraft.cfg scalar) or zero-lift drag (.air file drag coefficient) to get the right cruise speed. (Usually only the aircraft.cfg file is needed.)
6. Check and set the cruise fuel flow (gph or pph). See the old value. Multiply the fuel flow scalar in the aircraft.cfg file by the ratio of correct to old value. Check also for a level attitude at cruise. The fuselage should line up with the horizon. If it doesn't, you must go into the 404 lift table in the .air file and shift everything right or left until the aircraft is level.
7. Check clean stall speed at MTOW. To adjust this, you must move the peak lift coefficient up (to reduce stall speed) or down (to increase stall speed) in table 404 of the .air file.
8. Check full flaps stall speed at MLW. To adjust this you can either adjust the lift coefficient increment in the .air file or the flap lift scalar in the aircraft.cfg file. Add lift to reduce the stall speed.
9. Start flying approaches, landings and takeoffs in sequence. Here is where the drag for the gear and the flaps can be adjusted to give "good" results. Look for gear bounce problems. Some runways are rougher than others. Try takeoffs and landings at several different airports.
10. Get some altitude and do steep stalls, accelerated stalls, straight and in turns and try some spins. Some aircraft should not recover easily from spins. Some aircraft will snap into inverted flat spins when you get rough with them. Here is where you work on the stability values and their derivatives in the .air file. You'll probably die a few times. Have fun! The behavior should be appropriate to the aircraft. This is where anecdotal pilot reports come in handy.
All testing must be done with a panel that shows all important parameters and shows them clearly so there is no doubt what is going on. A panel that is better-suited to the aircraft can be installed after everything checks out. The test panel must include weight, CG, AoA, Turn Test data, all engine instruments, both indicated and true airspeed. The autopilot is used a lot to test in steady conditions. Hand flying is a waste of time until checking for handling problems.
« Last Edit: Jun 10th, 2007, 2:01pm by Tom Goodrick » 216.180.4.228 216.180.4.70
flaminghotsauce
Member
Posts: 680
Re: Notes on FD Development
« Reply #1 on: Jun 10th, 2007, 6:11pm » Quote Modify Remove
--------------------------------------------------------------------------------
Yikes. It sounds like it would take hours of work to start from scratch!
I have yet to mess with an .air file. I need to go back to my old computer and steal off several things I had to put on my lap top. I had a version of the 172 that flew pretty accurately as far as I can tell. The only thing I could find that didn't match my real life experience was the engine RPM settings to maintain a descent on approach. But that's the same as the default 172. I used 1700 in real life, and 1800 on any version of the 172.
On my desktop computer, I had done some steering adjustments, and a few other things. I still need to go in and do all that again.
I am still almost completely stock-install on my lappy. I have a video driver error (I think) that makes twin "whiskers" off my empennage.
I appreciate the ordered list of things to do. This process has to have a logical order to keep chaos to a minimum. It's why I have not tampered with very much at all in either the .cfg file or .air.
72.161.248.198
--------------------------------------------------------------------------------
"Barring all differences, they're identical!"
Tom Goodrick
Administrator
Simaholic
Posts: 3589
Re: Notes on FD Development
« Reply #2 on: Jun 10th, 2007, 11:15pm » Quote Modify Remove
--------------------------------------------------------------------------------
I am glad you mentioned the RPM problem with the 172. It can be very tricky trying to get the rpm correct on an aircraft with a fixed-pitch prop. The key is to adjust the value for the fixed-pitch beta (blade angle) in this line:
fixed_pitch_beta= 19.1 //Fixed pitch angle of fixed pitch prop, (degrees)
This is from my 172SP where I had made an adjustment to get the right cruise RPM. The problem will be getting the rpm right in all phases of flight.
I'd say the typical time to develop the FD for a new aircraft - starting from scratch is about 10 hours in flight time and another similar amount of clock time working things out with notes and checking information. Then if you run into a problem such as a balance problem or a landing gear spring issue and many hours can go by stuck on one thing, This happens when things don't respond to your changes as you expect. Any thing related to the interaction of the landing gear with the ground can get very strange. For example, if you watch a landing very closely, you'll see the aircraft respond to ground contact before the wheels are actually touching. The air gap corresponds to the rate of descent.
« Last Edit: Jun 11th, 2007, 9:04am by Tom Goodrick » 216.180.4.56 216.180.4.69
Tom Goodrick
Administrator
Simaholic
Posts: 3589
Re: Notes on FD Development
« Reply #3 on: Jul 15th, 2007, 12:04pm » Quote Modify Remove
--------------------------------------------------------------------------------
I should add a note to the effect that sometimes things happen in FS9 that HAVE NO EXPLANATION. For example, just the otehr day, I flew an airplane I had not flown in a while. Everything went fine including some accelerated stalls from which recovery was difficult. I flew back to the airport and made a very nice landing. I stopped the sim when I was slowed down to a few knots and starting a turn onto a taxiway. Then, I watched the Instant Replay of the landing a few times checking that the pitch attitude looked proper from early in the approach to the roll out. Then I switched back to the sim to go park the aircraft. It flipped up into the air and then nosed into the ground with debris and smoke coming out of the wreck! I just said a nasty word and shut down the sim. I've seen that before.
Shut down your system and reboot after something like that. You won't see it again for a while.
216.180.4.74
Tom Goodrick
Administrator
Simaholic
Posts: 3589
Re: Notes on FD Development
« Reply #4 on: Jul 15th, 2007, 2:58pm » Quote Modify Remove
--------------------------------------------------------------------------------
NOTES ON MODEL DESIGN AND THE .mdl FILE
Part 1
The process of aircraft model design starts with the use of a special design porgram. There are only two that I know of - FSDS and GMAX. GMAX is a basic 3-D design program. It lets you make individual components and then connect them together in some way the ends up looking like an airplane. I have never used it. But I have noted some things from the results. It seems that the fuselage shell is made with a particular thickness that scales on the order of an inch. With the finished aircraft in FS9, you can put a viewpoint inside and look outward through the cut-out for a window. It looks reasonably realistic if you discount inch-thick walls. There are special programs that come with GMAX that enable the process of making and saving special effects like spinning props and moving gear. They also create the several files needed in FS9 to fly the aircraft.
FSDS is Flight Simulator Design Studio by Abacus. I own this one and have used it to make several aircraft including the Beech Bonanza, the Cessna 340 and 414 twins, the Aerobat, the Parafoil and several others. It also includes a 3-D modelling routine but one tailored especially for building aircraft. You can examine my Aerobat to get an idea of how things work in the design process. Unfortunately, I cannot recommend FSDS for anyone who is not fanatically dedicated to making aircraft because it is terrible to learn to use, even if you know something about designing and building real aircraft. The instructions that come with it - even though it looks like a whole book - are terrible, incomplete and just plain wrong in several instances. To begin with, they took the "standard" X,Y,Z coordinate system and stood it on its ear! Even in FS9, this system is close to the one we all learn in engineering school: X along the centerline of the fuselage (the longitudinal axis), Y along the wing and Z up with all these being mutually orthogonal. But in FSDS X is out the right side, Z is forward and Y is up. It sure is confusing for a while. Why they did that sure beats me.
You begin building a model of the plane by setting simple objects like a box or a cylinder on the axes. Usually you make the fuselage from a cylinder. You pick the length and diameter in real units, the spacing of cross-sectional plates and the number of equally-spaced verticies around each plate. You place this object on the longitudinal axis with the origin at about the 1/4 chord location for the wing. (Exact placement can be easily adjusted later.) You can take each of the plates, from nose to tail and scale it to get a reasonable profile for the fuselage with a windshield, a cabin area and a tail cone. In some cases, such as the Aerobat, the canopies will be made separately and attached after the fuselage is made. FSDS does make it easy for you to select sections through the structure to view and to manipulate. You see lines passing from the nose to the tail around every plate. You can grab a line at a plate and pull it in or out, left or right, to make special little forms in the fuselage. Wings are made from special forms where you specify the span, root chord length and tip chord length. You can select from several airfoil sections you have made up ahead of time. These form the ribs at various spanwise sections as you have specified. With a fuselage sitting on the axes, you just move the wings (left and right) into position so the root sections are inside the fuselage. (The program will take care of forming the joint between the walls of the fuselage and the surfaces of the wings.) You can define various groupings of parts and place them in special component files if desired. Until you have defined them as a whole unit, you can move components around until they "look right." You can even scale entire groups.
Making the prop takes a bit of work. You do have to make a prop blade in 3-D from hub to tip. Then you can copy it into two, three or four positions. You make also a disk which you give a transparent color. This must be the same diameter as the combined set of props. You put the prop set in place and give that a files name. Then you put a copy of the prop rotated at an angle in place and call its file something else. you place the disk in position and call it another file. You then name these files as your prop system. For a twin, you duplicate this file.
Landing gear are built in pieces and assembled in the down position. Doors are built and assembled into position as photos show they should be. This was a little bit tricky on the Bonanza becaues there are two doors in the center between left and right mains that are closed when the gear are up and when they are down. The doors open only during transit of the gear. You must walk the gear and the doors through their particular rotations during a gear cycle recording about four "snapshots" of all positions. The the program lets you run the gear through operation while you look from many different points and angles of view. This is when you find that a wheel sticks up through the wing when in the "up" position. (You also find that when you are test flying the airplane later.)
You make the cutouts in the wings for the flaps and ailerons and save them as separate pieces. One thing you learn is that you must make interior surfaces for the inboard edges of these surfaces and the corresponding edges in the wing which will show during certain motions. Each surface in FSDS has an inside and an outside surface. You will see the surface only from the outside. If there is a possibility you might see a surface from both sides when looking at the airplane while it is flying, you must make a double surface, each have opposite "outside surfaces." This is why you will see some very strange things looking at the aileron gaps in a flying plane. I screwed up on the Bonanza by not making movable "ruddervators" because I could not see how to do it. Later I saw another guy's work and asked him how he did it. It was astoundingly simple. When animating a surface such as a rudder, elevator, flap, or aileron, you assign a control to that surface such as "rudder" for the rudder. I was too stupid to realize you can assign two controls to the same surface! Maybe I'll fix it one of these days.
In FSDS it is a bit more work to make possible a view of the inside of the airplane that you see from the cockpit. The normal event which I experiened with my Bonanza was to go flying and see nothing of the inside of the aircraft though I could see the wings and the nose cowling where they should be. I could even see the ailerons and watch them move. To see the inside, you must build a separate inside surface of the cockpit. This is some work but not too bad. You copy the whole fuselage into a separate workspace. Then you chop off the nose and tail and install bulkheads. Then you go around to each polynomial in the frame (poly's are formed between the lines and the edges of the plates (which are invisible)). Each poly has a surface normal vector indicating which way is "outside". A command lets you view all those vectors. You select several and "flip" them so they point oppositely. Now you have an inside surface for the complete fuselage. bring this structure back into the normal workspace and merge it with the rest of the aircraft. Go fly it and look outside from the pilot's point of view. You will see portions of the interior and portions of the exterior such as the wings. They all look very realistic.
Then you fly the same plane into some scenery areas such as the Alaskan scenery of our friend Jim Bertleson, and your fuselage walls become invisible in some scenes but not in all. One minute you are wram and comfortable in the cockpit looking through a window at the ice and cold sea. The next you see no protection around you from the cold! It can be enough to drive you out of the business.
216.180.4.74
Tom Goodrick
Administrator
Simaholic
Posts: 3589
Re: Notes on FD Development
« Reply #5 on: Jul 15th, 2007, 3:06pm » Quote Modify Remove
--------------------------------------------------------------------------------
NOTES ON MODEL DESIGN AND THE .mdl FILE
Part 2
All the component motions are recorded in code in the .mdl file. You cannot ever examine this file, not even when doing the designing. As you build a model, there are many files produced that stay in the design space for the program. You save these, of course. When you see something on your aircraft that does nopt look right, such as an overly large aileron gap, you can go back into the design program and change it and then save the result. But no one else can ever do it unless you give them all the design files. Even then they would not know which files you used in what components or what is in the various component files. I would even have trouble going back into an aircraft I built four years ago.
For anyone who wants to try building an aircraft, model, I'd say you should buy the latest and best aircraft design program around (you have to figure out which one) and also get a plastic model of the airplane and put it together first, to the same level of detail you want in the final FS model. Then keep a rule handy that will read scale lengths off the model. A calibrated eyeball helps. I did that with the Bonanza. With the other aircraft I built, I only had photos but there were several of them from several articles including 3-view drawings in some cases. in the case of the Aerobat, I had some photos and drawings of several unlimited aerobatic aircraft and just designed the model as I went based on some engineering calulations for wing size and shape and other components. It differs from most such aircraft by having retractable trike landing gear. I simply prefer that. I wanted a sleek design for doing vertical rolls with low deceleration. It also tumbles well.
There are some things you can edit into the aircraft.cfg file that will have an effect on the model animation. For example, I recently set a max flap angle of 60 degrees on the Citation Jet. This exposed some ugly parts inside the wing. The original designer did not know the flaps were supposed to go to 60 degrees. He never even looked at them when set at 60 degrees.
Like everything else related to the Microsoft Flight Simulators, there are mysterious things about this work that come and bother you every once in a while. So it goes.
Painting seems to be easy for some but I find it difficult. I can draw a decent pattern in 2-D. My problem is wrapping it around the object and getting everything to come out like it should. I am obviously doing something wrong because I know most painting is done as 2 D projections. I was able to paint the few aircraft I have done using basic generic airplane paint schemes. But I have great trouble trying to paint other people's aircraft, even to just paint new numbers on the side. There is some mysterious program you need that will make sure your new paint file is in the correct resolution. When I paint a texture file on an aircraft made by someone else, it is never seen again! I mentioned this once a few years ago and a certain blithering idiot yelled at me saying that "You don't have to paint numbers on the side of aircraft. Just change the number when you load the aircraft within the sim." That only works with certain aircraft built using GMAX. Now he does his blithering somewhere else while I do mine here.
Incidentally, if you have tried to load an aircraft made for FS2000 or FS2002 into FS9, you have seen the box warning you that the model contains some nasty code that MS would like to block. JUST SAY NO! That will disable things like your gear and prop. I have never seen a case where such animations, done by software by a company other than Micro$oft di in fact harm your sim in any way. But I have seen or heard of many inoperable props and landing gear. The problem is that you cannot simply re-install the same plane and then say "No!" Micro$oft writes a little note in FS9.CFG namineg that airplane as a bad one. You must find that note and remove it before you can re-install the same aircraft. Aren't they nice people?
216.180.4.74
Tom Goodrick
Administrator
Simaholic
Posts: 3589
Re: Notes on FD Development
« Reply #6 on: Jul 15th, 2007, 9:48pm » Quote Modify Remove
--------------------------------------------------------------------------------
This is just short note about the Microsoft Aircraft Container Software Developer's Kit, lovingly known as the ACSDK for FS9. This is free from microsoft's web site. Everyone should have a copy. There is a similar SDK for panel designers that is absolutely necessary if you intend to design or to modify gauges. The main thing the ACSDK does is make some sense out of the lines in the aircraft.cfg file. The first time you go through this document, you should have a copy of the aircraft.cfg file for a default aircraft you have flown ready to look at for examples of how the commands in the SDK are actually implemented by Microsoft's FS staff. The Baron would be a good aircraft to use.
There is one basic theme that is repeated throughout this document. It assumes that you are going to use FSEDIT to modify the aircraft.cfg file and that these notes are merely information so you don't get confused should you ever be confronted by the aircraft.cfg file as a text file (which it is, of course). They claim that there are many lines in the aircraft.cfg file where parameter values modify parameters in the .air file that WILL NOT TAKE EFFECT until you run FSEDIT. I have not found ANY instance where this is true. I have not used FSEDIT since it first came out several versions ago. Then I used it once to change payload weights (before they put station weights in the menu of FS) and found that it messed up other station weights I was not changing. I also found it was setting things in the .air file that I did not want to set. I refuse to use software that changes things in files without telling me and things that it is not supposed to be touching. One thing they clearly state, as an example, is that changing the parasite drag scalar will have no effect until you run FSEDIT. That is clearly not true because I do it all the time.
But they also say that, to make edits take effect quickly, you can define a key sequence that will reload the aircraft, thus effecting the change of any edits in the aircraft.cfg file. Many others have reported, as I have that this does not work. You must load another aircraft and then load back in the aircraft you have edited. When this happens your pitch trim setting is reset to zero so you will get a bump in your flight if you do not remember the setting and put it in manually 9using the 1/10 digit in the decimal value. But you certainly do not have to run FSEDIT. I don't even have it on my system so I can't play with FSEDIT.
It becomes clear that a whole bunch of people having various aviation backgrounds work at Microsoft. In some places in the sim they show evidence they know what they are doing. In other parts, they show utter and complete ignorance. An example i in the SDK and the aircraft.cfg file under [reference_speeds] where they state very clearly with exclamation that the stall speeds are to be entered in knots, true airspeed (KTAS). If this were true you could not fly safely at altitudes above zero. The fact is, as every student pilot learns very quickly, stall speeds must be given in Indicated Airspeeds or KIAS.
There are two other areas in the aircraft.cfg file that are purely bogus and the explanation in the SDK proves it. One is with respect to the cruis_lift_scalar in the [flight_tuning] section. the supposition is that you will find it useful to change this parameter from 1.0 in order "to give the proper lift at cruise."
Their exact explanation is: regarding cruise_lift_scalar=
The following parameter is a multiplier on the coefficient of lift at zero angle of attack ("cruise lift" in this context refers to the lift at relatively small angles of attack, which is typical for an airplane in a cruise condition). This scaling is decreased linearly as angle of attack moves toward the critical (stall) angle of attack, which prevents destabilizing low speed and stall characteristics at high angles of attack. Modify this value to set the angle of attack (and thus pitch) for a cruise condition.
This is total balderdash. Don't touch this parameter. I erase it from all files I see. Elsewhere in the document they mention this is related to the viewed pitch angle in cruise. That pitch angle in cruise should be fixed by the wing incidence angle as it is on all real aircraft. But the "management decision" was made to make the incidence angle constant at 1.5 degrees in FS9. I cannot imagine such a mixed up situation where this was worthy of a management decision. It certainly would have no effect on computation time or memory utilization. So the only way we can fix the cruise pitch angle is to shift the lift table #404 along the x axis. This must be done only to those values of lift from zero to stall. It is a bit of pain but it simply involves subtracting a constant such as 0.002 from the x axis values at several points.
There is only one more example of pure balderdash in the SDK. That is regarding the section in the aircraft.cfg file called [airspeed]. This section and its single line must also be deleted. You'll find it prominently only on the file for the Cessna 182 Skylane. in revising the FD for the Skylane so it would meet the performance specs mentioned by Cessna on their web site, I found some difficulty caused by this line. The explanation is that this permits the user to enter a scalar and an offset to convert the indicated airspeed to calibrated airspeed. Cessna uses calibrated airspeed in their stall specs which is very unusual because a pilot cannot ever see the calibrated airspeed. He can open the manual and find a conversion table but he will seldom do that when wondering whether or not he will stall! Calibrated airspeed is otherwise used only when first flight testing an aircraft. It is measured by a pitot tube extending far out in front of the aircraft (either from the nose or from the wing tip where it sees flow undisturbed by any part of the aircraft. As flow gets closer to the aircraft where normal pitot tubes are installed, it slows down, especially at high angle of attack where stall will occur. I have two airplane owner's manuals for planes I used to fly. I never owned these but had to buy the manual in order to transition to the aircraft. (They are are for the American Model AA-1A trainer and the Cessna 172.) Both contain tables showing the relation between caibrated airspeed and indicated airspeed. Both are nonlinear. You could not possibly set the parameters in the [aispeed] line to perform these calibrations. if you set it at one end, it would be off at the other end. You are best off assumming that calibrated airspeed equals indicated airspeed which is what happens by default when you delete these lines.
There is yet another section that has been peculiar for years but I just ignore it. It lets you set the delay in the vertical speed indicator. There really is not much of a delay in that indicator. Modern instruments may not have any. In old instruments, that need no electrical power, the vertical speed is measured by taking the air from the static source on the side of the plane that feeds the ailtimeter and the airspeed indicator and splitting it so that one side passes through a narrow part that delays it before both tobes then enter opposite sides of a diaphram. The fact that old air is compared with new air gives you an indication of the rate of change of pressure which is proportional to the rate of climb. This delay was of the order of 2 seconds which is what is often specified for this vertical speed delay. But if you are climbing steadily and then level off, the delay would only be slightly significant when levelling off and then you'd not notice it in the temporary upset that always occurs when you make the change from climb to level flight. The fact is that today, electronic sensors can be used that will electronically determine the rate of change of pressure having no delay at all.
Another cute thing is with the two sections [attitude_indicators] and [turn_indicators]. These set whether your gauges are driven by vacuum or by electricity in case of a failure of one of those systems. Aircraft that are well-prepared for IFR flight will have two such indicators, one depending on vacuum and one on electricity. But in FS we only have room on the panel for one indicator so these lines seldom have mening. For what it is worth, though, Microsoft has managed to screw this up. The line for the attitude indicators has 1 for Vac and 2 for Elec. The one for the Turn indicator has 1 for Elec and 2 for Vac.
I did learn a nice new thing tonight that I might try to use and see if it really works. It is the line for [directional_indicator] which has a 1 for Vac Gyro and a 2 for Elec Gyro but also a 3 for electro-mag slaved Compass. Your normal cheap directional gyro (DG) most of us have flown with can only hold its bearing for a few minutes. Then as long as you are steady and level, you look at the compass and reset the DG to agree with the compass. You do this before starting any prolonged turn because you want to use the DG during the turn as the mag compass either leads or lags the turn. Long ago I elected to select the "Zero Drift Gyros" so I do not have to go through my sim flying career tapping D to reset the gyro. I knew there were fancy instruments that slaved the DG to a compass so it would get automatic periodic updates from the compass when in steady flight. Evidently you can set this value to 3 and get just that. I'll soon see if it works. (Of course, the new glass cockpits get away from this altogether with their AHRS's. See my notes on digital panels for info on that.)
Well, have fun with your SDK's. We shall discuss the aircraft.cfg file in more detail, covering the important parts next.
216.180.4.145
Hans_Petter
Member
Posts: 424
Re: Notes on FD Development
« Reply #7 on: Jul 18th, 2007, 10:52am » Quote Modify Remove
--------------------------------------------------------------------------------
Just a quick note on paint jobs, it largely depends on the texture mapping. The 3D model comes with a texture map that defines where the textures you see in your paint program are supposed to go. Elaborate paint jobs are hard to accomplish unless the texture mapping is detailed enough to allocate separate textures to separate parts. What happens with an insufficient texture mapping is that the textures are stretched and skewed to drape the entire 3D model. To some extent pixels will be stretched in all cases and the texture file will have to be modified to counteract the stretching and skewing. Anyone who has looked at texture files will have noticed skewed images that come out right when the model is viewed in the sim. Pilots' faces come to mind. That is, in order to draw a straight line it will have to be curved, provided it's supposed to texture a curved surface. I know of no way to approach this other than old fashioned trial and error. If the numbers look too tall, shorten them in the texture file. If the straight line curves, try to curve the texture image line in one direction and see what happens. Elaborate logos may need to be skewed (compressed or stretched) along one axis to make them look right. It's all a question of fitting a 2D image unto a 3D surface. Thus, the more the textured surface curves the harder it is to fit a 2D image unto it and make it look right.
222.123.156.242
--------------------------------------------------------------------------------
best regards,
Hans Petter
Allen_Peterson
Member
You gotta Keep a-Goin'
Posts: 157
Re: Notes on FD Development
« Reply #8 on: Aug 7th, 2007, 7:01pm » Quote Modify Remove
--------------------------------------------------------------------------------
This has been bugging me for some time. Maybe writing this out will help me get it straight in my mind. Reference_datum_position is defaulted to 1/4 chord aft of the leading edge unless specified otherwise, say 3.6, 0, 0 (maybe the nose). Then, for example, wing_pos_apex_lon (assuming a straight wing) would be measured back from the nose. If reference_datum_position were 0,0,0 then wing_apex_position would be 1/4 chord forward. htail_pos_lon and vtail_pos_lon would be measured the same way, either back from the nose or back from 1/4 chord (0,0,0). And longitucinal positions for contact points would be measured the way?
76.182.131.116
--------------------------------------------------------------------------------
Have a good day.
Allen
Tom Goodrick
Administrator
Simaholic
Posts: 3589
Re: Notes on FD Development
« Reply #9 on: Aug 7th, 2007, 10:17pm » Quote Modify Remove
--------------------------------------------------------------------------------
Congratulations. You have identified a tricky point in FS that takes some careful study although it might seem to be simple. It is not simple. I am just now, with the help of your question, getting it all together. I think you'll find this interpretation makes sense.
We'll try this piece by piece:
"Reference_datum_position is defaulted to 1/4 chord aft of the leading edge unless specified otherwise..."
That is not a good way to put it. The sim internally requires mass points to be given coordinates where X is zero at the 1/4 chord point aft of the "apex" of the wing. Points ahead of that point have positive X values and points aft of that point have negative values. The purpose of the ref datum is to provide an offset that can be used to convert real aircraft coordinates in to FS coordinates. Those who have a pilot's hanbook of "POH" for an aircraft, would want to set the coordinates for weight positions in an FS model the same as in the real aircraft. This lets them do that.
The coordinate stated for each weight point is added to the ref datum to get the FS coordinate of the weight point. Take three examples:
C172 Xref = 3.6 and EWX = -3.0. Then FS coord of EWx is 3.6-3.0 = 0.6.
C340 Xref=0 and EWx=0.50
FS coord of EWX = 0+0.5 = 0.5
Baron 58 Xref=6.96 and EWx=-6.06
FS coord of EWx = 6.96-6.06 = 0.90
"Then, for example, wing_pos_apex_lon (assuming a straight wing) would be measured back from the nose."
No, like all other coordinates, it is added to the Xref to get the FS coord. The purpose of this value is to show where the wing fits on the fuselage in relation to the BIG ZERO POSITION or origin of the FS coordinates.
Again we can get help from some examples.
In my C340, I built the airplane around the point that later became the 1/4 chord point. That was my origin of coordinates. So Xref=0 and the value for the wing_pos_apex_lon is 1.28 which is 25% of the root chord (it should be mean chord on a tapered wing but it is the root chord). That value is +1.28 because the apex or leading edge is 1.28 ft forward from BIG ZERO.
In the C172 with Xref=3.6, the value of wing_pos_apex_lon is -2.4. Add that to the xref and you get +1.2 which puts the leading edge 1.2 ft ahead of BIG ZERO. (That's 1/4 the root chord.)
In the Baron 58, Xref=6.96 and wing apex is at -5.6. Add the Xref and the FS coordinate is 1.36 meaning the leading edge is 1.36 ft ahead of the BIG ZERO.
The FS coordinate system has a long historical basis through many versions although there was a shift between FS2002 and FS2004 (FS9). Before FS9, the wing apex position was not used. that has caused some problems.
I prefer not to use a non-zero reference datum. The reason is that all the positions identified in all sections of the aircraft.cfg file must be in the same consistent coordinate system - weight stations, aircraft components, engines, fuel tanks and contact points. positions relative to "Big Zero" are what matter to the stability of the aircraft in the sim and it is hard to fihure that if you have a non-zero reference.
So now it is all clear - right? Good. Now you can explain to me how there are inconsistencies in CG position. I did a little calculation using simple geometry some time ago and got very confused. There seemed to be a mysterious "X factor!" Recently with the CitationJet where I was trying to match real world data supplied by Dustman, a pilot of the CJ, I ran into a case where a setup in the aircraft.cfg file was completely messed up when I had to switch to another .air file.
There may be things here that we mortals were not meant to understand!
216.180.4.82
Tom Goodrick
Administrator
Simaholic
Posts: 3589
Re: Notes on FD Development
« Reply #10 on: Aug 10th, 2007, 10:22am » Quote Modify Remove
--------------------------------------------------------------------------------
In the section on "Citation Jet Revisited" I worked through the complete problem of calculating the center fo gravity for an FS aircraft and getting it to agree with the same calculation on a real aircraft. But, in looking back at it, there are a few gaps in the math that are not very clear. Between what was written in that section and what is in my hand-written notes from that time, I think I can work out a generic summary of the equations needed. I'll get busy at it.
216.180.4.60
Cam G.
Member
N41BE: in memoriam
Posts: 16
Re: Notes on FD Development
« Reply #11 on: Aug 11th, 2007, 11:20am » Quote Modify Remove
--------------------------------------------------------------------------------
I have worked with .cfg files quite a bit, but have always wondered about some items listed: "Reference Speeds" are given for stall and cruise speeds. Does the .air file read and apply these?? I would assume that changing the wing span/area, gross weight and other physical parameters would change the stall speed--just as in real aircraft. Why are Reference Speeds in the .cfg file if the other stuff defines the stall behavior?
A similar one is the "Horsepower" entry. Does changing this value change the horsepower of the model? Again, the "real" way to modify an engine would be to make changes in the number of cylinders, displacement and compression ratio (and making it turbocharged). Is the "Horsepower" value used by the .air file?
Last item: What does "gain on fuel flow" affect? I tried increasing it and reducing it about 30%, but didn't detect any flow change cruising at altitude. MS SDK defines "Gain on Fuel Flow" as the gain on fuel flow...thanks, MS, that was helpful!!
12.162.217.254
Tom Goodrick
Administrator
Simaholic
Posts: 3589
Re: Notes on FD Development
« Reply #12 on: Aug 11th, 2007, 3:11pm » Quote Modify Remove
--------------------------------------------------------------------------------
There are some aspects of these reference speeds you can use and some you can ignore.
[Reference Speeds] // (Baron 58)
flaps_up_stall_speed = 84.0 //Knots True (KTAS)
full_flaps_stall_speed = 75.0 //Knots True (KTAS)
cruise_speed = 200.0 //Knots True (KTAS)
max_indicated_speed = 223 //Red line (KIAS)
First you can ignore the note from the ignorant folks at MS that the stall speeds are in KTAS. They are in KIAS. They do have something to do with stalling the airplane but I don't know why they should. One day I was working on the stall speed for an aircraft that had them set too low. I was adjusting the max lift coefficient in Table 404 of the .air file as one would normally do the trick. I was also adjusting the two stall warning conditions in the .air file - one based on speed and one based on angle of attack. I knew it wanted to stall at the right speeds. Finally I changed the clean stall speed in this reference set and it worked fine.
The cruise speed is used when you use the navigator log feature to estimate the time it will take to fly a planned flight. For that reason it helps to set this one at least close. Of course we all know there are many cruise speeds for any aircraft, based on high/low and light/heavy. Pick one. And you can belive the KTAS. This really is in True Airspeed as are all cruise speed specs.
The max indicated speed is VMO or VNE. Make sure this is close after looking up data on the plane. It will activate the overspeed warning if you exceed that speed.
You are right that the geomtry you might change would have a significant effect. Neither the cruise speed or the max indicated speed have any effect on flight. The overspeed warning just makes noise.
For a long time I thought the horsepower setting made sense. I still don't understand why MS does not use it to tune up engine settings. But they don't. You can double it and your speeds won't change a bit. Still, I like to set it correctly just so it looks right.
The main thing it does affect is your next question - fuel flow. The first thing I dod with an aircraft that needs FD adjustment is climb it up to the altitude for which I have a cruise speed spec. I also have a fuel flow for this condition. (If I don't have these specs, I prefer not to work on the aircraft. But you can work out a fuel flow if you have range information at the same cruise condition.) For the Baron 58, these specs are 203 KTAS at 5,000 ft using 210 lb per hour (total, 105 or 15.7 gph from each engine). With the powere set at 75% (25 inches and 2500 rpm for the Baron and many other aircraft), I look for the right cruise speed. On the default Baron 58 I didn't find it so I reduced the drag - either the parasite drag scalar or the zero lift drag in section 1100 of the .air file will work equally effectively.
When the true airspeed at cruise is correct (use either the GPS in no-wind conditions), then note the fuel flow per engine. Say it is 17.3 gph when it is supposed to be 15.7 gph. You solve this problem exactly and quickly by going to the following section in the aircraft.cfg file.
[GeneralEngineData]
engine_type = 0 //0=Piston, 1=Jet, 2=None, 3=Helo-Turbine, 4=Rocket, 5=Turboprop
Engine.0 = -1.4, -5.3, 0.0 //(feet) longitudinal, lateral, vertical distance from reference datum
Engine.1 = -1.4, 5.3, 0.0 //(feet) longitudinal, lateral, vertical distance from reference datum
fuel_flow_scalar= 0.9 //Fuel flow scalar
By default this fuel flow scalar would be 1.0. if other people have messed around with the file all right it could be anything. You calculate a correction factor of 15.7 / 17.3 (new over old) and multiply that by the existing scalar and use the result. I have read that this does not work. It always has worked for me.
By the way, setting a non-zero minimum throttle limit keeps the engine from dying while you taxi.
I am sure you know there are many types of .cfg files for each aircraft. All are really just text files and can be edited by Notepad. The two we most often change are the aircraft.cfg and the panel.cfg files. Sometimes it is fun to tweak a sound.cfg file.
In their SDK, the gurus at MS have given many instructions that are totally worthless. At MS there are some Twits and some Ni Twits and a few people who do know what is going on. The trouble is they seldom talk to each other. In the SDK they assume they are writing for dumb code writers like themselves.
If you have studied a lot of math as I have, you might be confused by the term "scalar" as used by the original developer of the Flight Simulator and perpetuated by Microsoft. I had certainly heard of and used scalers as opposed to vector quantities. A scaler has only magnitude while a vector has both magnistude and direction of application. Scalers are sometimes used as multipliers for vectors and matrices. in matrices they apply to all elements of the matrix.
So where did "scalar" come from and what does it mean? Just consider it a factor to be multiplied by whatever parameter it relates to. A scalar of 1.1 increases something by 10%. A scalar of 2 doubles it. The guy who wrote Flight Simulator was working on a Master's Thesis in Electrical Engineering. How this relates to that beats me, but, those guys have their own terminology.
« Last Edit: Aug 11th, 2007, 3:26pm by Tom Goodrick » 216.180.4.73
Cam G.
Member
N41BE: in memoriam
Posts: 16
Re: Notes on FD Development
« Reply #13 on: Aug 12th, 2007, 7:12pm » Quote Modify Remove
--------------------------------------------------------------------------------
Tom, When I was talking about fuel flow I was referring not to the fuel_flow_scalar in [GeneralEngineData], but the fuel_flow_gain in [TurbineEngineData]. It only applies to turbine aircraft, apparently. The Boeing 777 shows a value of 0.002, while the Cessna Caravan shows a value of 0.011. Its bugging me as to what this affects.
12.73.130.123
jcomm
Member
Easily lose my mind about women and aircraft...
Posts: 208
Re: Notes on FD Development
« Reply #14 on: Aug 13th, 2007, 9:21am » Quote Modify Remove
--------------------------------------------------------------------------------
Allow me
It's a somehow non-intuitive name, as usual in the MSFS SDK.. It ** only ** controls spool rate, and re-shapes de default 1505 Tbl ("Turbine Corrected FF vs. CN2).
If you edit that table you'll notice it's steeper near the beginning (low CN2 values) and converges near the end. The steeper the slower throttle changes affect fuel injection into the combustion chamber and thus slower spool up speed.
The parameter affects the shape of the graph.
You'll get the "big picture" from Jerry's graph:
www.mudpond.org/jet_flow_chart.pdf
And since you're there, download also:
www.mudpond.org/fs_props.pdf
for a nice explanation of Propeller Tables...
If you're really after the "Internals" of MSFS, you have the right site here:
perso.orange.fr/hsors/index.html
In Hervé's "Airfile Documentation" section:
perso.orange.fr/hsors/fsdocs.html
make sure you visit each link...
And... download/install/use & abuse AFSD, one of the best tools we have to depict what's going on inside of MSFS. Latest version works for both fs9 and fsX - both require FSUIPC!
Hervé is a RW pilot, a great programmer, and someone with deep knowledge of MSFS.
« Last Edit: Aug 13th, 2007, 9:36am by jcomm » 193.137.20.1
--------------------------------------------------------------------------------
############################
jose carlos monteiro
Lisboa - Portugal
