Leaderboard

well here's a little report, just so you know we're not sitting around doing nothing. We are polishing up lots of little corners many won't see. As I said, the reason we are doing so is not a matter of pursuing perfection, but rather is because when you put this in thousands of hands, they will find these issues and if they cause crashes, that is no bueno as we like to say here in San Antonio TX. So today, I was addressing parts of the N1 limit page, for derate stuffs. So here's a CDU entry pattern you probably don't see much. Say you select "TO-1" derate....that will automatically select the "CLB-1" derate mode (so the throttles do not advance in the transition from Takeoff to climb phase....Boeing says that confuses the pilot dontcha know eh?). And then lets say you enter a assumed Temperature value....well depending on the temperature entered, that too might automatically derate the CLB thrust, not only to CLB-1 mode, but maybe CLB-2 if its hot enough......so far so good. But then lets say you decide to delete the TO-1 mode....well the CLB thrust mode may or may not revert to one of the reduced mode..... or not dependent on the assumed temperature entered.....and there are a myriad of other potential combos that may or may not get entered. Here's a little video to show several different combinations that have to be tested....and there are quite a few more patterns other than what is shown here. https://dl.dropboxusercontent.com/u/955680/n1_limitOPT.mp4

Top Secret photo of the team hard at work beta testing our latest build;

For those that don't follow the Facebook page. (There will be at least a pilot in there when it's done.) And a couple of panel grabs...

Fir, Maple and Cedar are clearly present in the photo!

Nice shoes, Jan!

That´s how we are struttin´ it here in Germany!

I'm excited to finally have a proper 737 in x plane 10.

At the moment Chambery is my favorite airport. Surrounded by beautiful scenery and fun approaches. Her is my landing at runway 18 with my 737-200.

Would have been much simpler But hey, kudos to you guys for your thorough testing, looking forward to trying it myself.

Oh, I wish...

Everyday I'm waking up and check the website. And everyday I get disappointed. But someday though.. I hope to see: "Released!".

Never say never

There are not any custom commands available for those functions. You could use the following DataRefs... LES/saab/prop/prop_sync_toggle LES/saab/baro_in_hg_dial_pilot LES/saab/baro_in_hg_dial_copilot

Making a plane great and making money FOR making the plane great are two different things. This is a business first and foremost. People have families and lives, and these things must be taken into account when dedicating resources to projects.

While I agree it would be cool, we've discovered a lesson during this products lifetime. We thought variants would be an effective way to give people good variety, and that there would be many who use all, but the truth is only about 2% of Saab 340A customers use the cargo or AEW variant. Because of this, going into the future we've agreed not to do multiple variants on new products. So with that said, while it would be fun, the demand necessary to generate the revenue and pay back the cost of development for this is simply not there.

Let's call this day "Devil in the details" day Did you spot the difference?

Released

Hardware is guaranteed to get faster. People are guaranteed to get slower. It's not fair to expect that ancient hardware is specially catered for on a multi year project. Having said that; hundreds of hours have been poured into Gizmo in the last year or so to make it perform as fast as possible and more time will be invested in the 737 to ensure that your modern hardware is utilised where and when we can. It's more prudent and beneficial for all our customers to focus on making any product run as well as we can on modern and future hardware than it is to spend time making it run on ancient hardware that is, relatively speaking, the cheapest part of the development chain and the only one certain to be thrown away eventually. This becomes more and more important as we start moving into the age of VR. Modern VR latency requirements and old legacy hardware support are simply mutually exclusive options. I don't think there are any current X-Plane payware products truly technically suitable for use in a VR sim at every level. It's very easy and very tempting to use legacy GL features to provide features that users want today while getting us into a bit of technical debt for features people are going to want tomorrow. (200 fps, VR immersion, full use of modern GPU's etc. etc.) The sanest course is to set the GPU resource usage as high as possible because by the time your product is eventually released the hardware will be there, or be there shortly. ...a bit of a rant, but please, over five years plus, it's impossible to set a legacy hardware target. I think everyone will be able to find a happy medium. It's an experienced team building the product on a varied set of hardware.