PAD Beech 1900C autopilot

KellyB said:
I'm still puzzled by the relationship between the cfg and air files.
Click to expand...

As I understand it, the first editions of FS only used air files. Later versions started using cfg files (one would presume) to make customization easier. The air file is compiled, and requires a dedicated editor to open and make changes. The cfg's are simple text and only require Notepad. I've heard talk about sim's getting away from air files completely, but that may prove tough, since the air files have certain functions that are graph based, like ground effect lift vs. distance from ground.
 
I have looked into air files with airwrench and even it gathers at least some data from the cfg file it would seem.

What is interesting is that the changes we've made to the cfg file have a direct impact on the way the plane flies, without doing anything to the air file, which sort of suggests that cfg has precedence over air??

I'm not necessarily looking to DO anything; what aeromed did is working just fine. I'm just curious as to why there would be two different files for the same things. In CFS3, there is a bdp file which is a binary version of the xpd file for the planes, and when you make any mods to the xpd file, you must delete the corresponding bdp binary file which will be rewritten as the plane loads. The binary file is supposed to be used by cfs3 because it loads faster than the xpd file.

Your explanation of successive sim versions migrating from one file type to another makes sense, and perhaps the air files are there to provide some backwards compatibility?
 
I am with Rob aka Srgalahad on this issue, which is why I mentioned twice the need to establish weather or not the out of the box AC was flyable at an established Vref or not. In addition to that as Rob correctly pointed out Vref is not flown from 10-20nm out but rather onlythe final portion of the flight.

When we released our Connie series there were quite a few folks who similarly went directly to modifying the provided files to cure a presumed flaw in the aircraft rather than question their own technique or ****.
I personally had spent a good deal of time and real world money to meet with folks lucky enough to have flown the real thing to gather flight impressions, numbers and procedures to round out what the real world flight manuals from TWA and Eastern ,to name just a couple, might not have made clear enough.

We have since had feedback that the simulated one is spot on to the recollection of the real one, even in the elusive "feel" of the controls.

My experience with PAD offerings in the past also indicated that the airplane should be fine as it was.

Unless you really have all parameters for an aircraft at hand AIrWrench or similar programs may be good enough to make a wingless bird fly but it will unlikely be anything close to the real thing.

Stefan

Stefan
 
KellyB said:
I have looked into air files with airwrench and even it gathers at least some data from the cfg file it would seem.

What is interesting is that the changes we've made to the cfg file have a direct impact on the way the plane flies, without doing anything to the air file, which sort of suggests that cfg has precedence over air??

I'm not necessarily looking to DO anything; what aeromed did is working just fine. I'm just curious as to why there would be two different files for the same things. In CFS3, there is a bdp file which is a binary version of the xpd file for the planes, and when you make any mods to the xpd file, you must delete the corresponding bdp binary file which will be rewritten as the plane loads. The binary file is supposed to be used by cfs3 because it loads faster than the xpd file.

Your explanation of successive sim versions migrating from one file type to another makes sense, and perhaps the air files are there to provide some backwards compatibility?
Click to expand...

That's about 99% true. If there is a conflict in identical parameters, the cfg gets the nod. But one odd thing that I've seen is actually in the [fltsim.xx] section. There was one plane that I d/l'd a long while back whose basic template was taken from the default Baron. In the cfg, the "description" line was still the text from the default plane. So I erased that and restarted. The air file's description line was then rewritten into the cfg! So I erased it again and replaced it with a single space placed in quotes. Now I had an actual "value" in that line that overrode the air file.
 
I guess that's the sort of thing we love about FS and CFS -- it's the mystery of everything!
I marvel at folks like you and aeromed and all the others who are able to fathom the labyrinths and come up with really great stuff for the rest of us.

For me, I dabble at it and do actually make a discovery on my own which has long since been known by others, but it still feels good when the discovery happens.

Thanks for your explanations, Tom. They really do illuminate the dark spaces of this stuff.
 
Thanks for the kind thoughts, but the "illumination" that my sparse knowlege brings is about on par with a tea candle that's just about out of wax!
 
Gentlemen, you are too modest.

Remember that to someone who is in a dark room for hours, the light from a match is enough to find the door!

and that's all from the philosophy department for today...:kilroy:
 
You must log in or register to reply here.
Back
Top