Leaderboard

I'm not 100% sure here, but there are many variants of the Saab rolling around, and we've had to stick to "one". So many different panel configs, etc. It may be so that Saab standardized the Cargo variants, but I don't have any clarification on this. Please be aware this is modeled after the A. Our primary concern is the passenger variant, and if the cargo variant has mods in it where smoke detectors are removed then we're not really concerned about that. The cargo version is thrown in as a bonus, and these are small factors that will have to be lived with. Minus the cabin differences visually, if it's in the 340A passenger systems, it's in the cargo version. Non-issue, really.

While Steven is off being his childish norm, my thanks to birdy.dma and Kris. This customer also sent in an e-mail to us the same day he posted the original thread, and we took care of him there.

No strange airfoils XP does a great job on it's own in most areas, but if you want extreme accuracy, it needs a bit of help. We "bend" the model if needed. Exactly what we do in various areas I cannot tell you, but the main point is, that if you are willing and capable of going that extra mile - you can get there n XP. So no, we are not going against the philosophy, we take it one step further and tailor it to fit the 737. M

The primary thing to keep in mind here is the concept of "math modeling" of a behavior. When any engineer decides to model something mathematically, they will have to make choices about how to go about doing so. The "x-plane approach" is a sound approach, but doesn't guarantee that Austin has yet implemented any given feature or relationship accurately. For example, ground effect due to air compression. This is something that Austin might choose to 'approximate' by altering aero forces close to the ground. He might come up with some heuristic function relating wingspan to lift and apply that to his equations. We may find that his choice of model was lacking for some reason...perhaps he was in a hurry or didn't feel like digging up research or thought "this is good enough and nobody will know"....and in such a case, we might seek to alter that behavior to get even more accurate. Just because Austin wrote the code does not mean that adopted the correct math model for a behavior. So we feel we do not go against the x-plane philosophy, but rather seek to improve the areas that Austin has yet to either get to or has no interest in getting to. So for any given behavior, usually the first thing we do is assess how well x-plane simulates something....and if it comes up short, then we try and find ways to improve it. Being that we are multiple guys working on one project (as opposed to Austin working on 3 or 4)...then it's more reasonable for us to spend lots of time fixing one area while Austin is dealing with dozens of other issues with mobile or his VP400 AP system, etc. The challenge for aircraft developers is to assess x-plane and making note of what it does well and what it does not do well. Austin is not interested is absolute accuracy across the board anymore and is content to let 3rd party folks customize it. I give props to the relevant Laminar team members for at least providing a way for folks to simulate that which Austin has elected not to via the SDK. TomK Laminar / IXEG

Alright, here goes nothing: