Happy New Year! This entire post is going to be off topic, but hopefully worth it; I will resume the usual ranting about how video cards are slowly turning our brain into string cheese later.
I think my favorite part of working for Laminar Research and being part of the X-Plane community is the friends I have made in the X-Plane community – X-Plane really does bring a great group of people together. While I lived in California, I met Jay Oliver, and actually lived not too far from him while I was in ATC school.
Here’s the thing about Jay: he is a fabulous musician. In an age where music is “produced” and so much of what we hear is digitally manipulated, there’s a lot to be said for listening to a human being who is simply astoundingly good with his or her instrument. It’s an experience that can’t be synthesized. It was always enjoyable to get a few drinks into Jay and put him down in front of the Piano and then just listen.
I’ve been listening to Jay’s new album for a few days now, but Austin beat me to the punch, putting it on the X-Plane announce list. Jay set up his new website here, and his album is available for sale in CD or DRM-free mp3 format. You can also listen online right on the site.
Austin’s usual diet is highly electronic, usually runs at about 180 beats per minute, and is the musical equivalent of shooting Jolt cola directly into your brain. What Jay does is completely different, and it’s really something special.
Let me set the record straight on this: you should not need to re-save an airplane to have it work in a newer version of X-Plane. If you have to do this, X-Plane is broken … please report a bug!
(In the case of 940 – there is a big fat bug – see the end of the post.)
Here’s a little bit more about what’s going on under the hood.
When Austin creates a new revision of the acf format (which happens in virtually every major patch), he handles backward compatibility with old aircrafts in one of two ways:
- He sets the default value of a setting to match the “unused” value in the old ACF file and sets this default value to match the legacy behavior. This naturally initializes all newly introduced functionality to its “backward compatible default” for old airplanes.
- Where this is not possible, he writes some conversion code that maps old ACF values to new ACF values. This mapping tries to re-create the old systems functionality as closely as possible.
This forward conversion code runs in two cases:
- When you open the airplane in Plane-Maker.
- When you open the airplane in X-Plane.
Plane-Maker will resave the plane in the newest format, with the automatic system updates in place. But this should not be necessary because X-Plane applies the same automatic process on airplane load. This is why you should not need to resave – X-Plane will do the upgrade “on the fly”.
Now about that bug…it turns out that 940 incorrectly updates 930 airplanes – the generator amperage is not correctly initialized. This is why 930 planes will run their batteries down in 940. (This bug was fixed in 941 beta 2, btw.)
What was strange was that, because of the way Plane-Maker’s code was structured, this code was failing in X-Plane but succeeding in Plane-Maker. This doesn’t happen very often (usually the code fails everywhere) but the result was authors noticing that their planes would start working if resaved in PM.
And that brings me back to the beginning of the post. If Plane-Maker can update the airplane but X-Plane cannot, that’s a bug! Please report it as such.
I want to make sure people realize that auto-update should work, and that resaving in Plane-Maker should not be necessary. Otherwise authors will start silently resaving their airplane instead of reporting the bugs, and we’ll never find them.
(Systems bugs sometimes only show up with a particular combination of systems settings. So while I do hope that we can catch all such bugs in beta, it is always possible that one peculiar model will induce a bug once the sim is released.)
X-Plane 940 beta 7 is out. Now is the time to test your airplanes, scenery, and plugins. We’ve reached a point where we think we have the new systems code working. Please try the new beta, test your add-ons, and if something works in 930 but is broken in 940, file a bug immediately!
I’m seeing a number of bug reports where weird artifacts are showing up in 940…missing pieces of runway, flickering triangles…all sorts of good stuff!
I believe that this is due to some kind of bug relating to threading, X-Plane and the video drivers. I won’t say whose fault it is because I really don’t know. I do know that the bug appears to not happen on OS X. (But this could simply be because the threads time out differently on OS X.)
The changes to the rendering engine for 940 from 930 are substantial and aggressive – it’ll take us a little bit to fix these things.
When you wonder how come programs don’t use all 8 of your cores yet, well…this is why…multi-core programming is complex, tricky, tedious to debug, and often involves substantial changes from the original code.
If I have not emailed you back, it’s probably because I’ve been very busy trying to interleave X-Plane coding and packing up the house. But it is also possible that my email response bounced because my web server has ended up on a bunch of anti-spam “black-lists”.
Black-listing seems like a good idea at first: we’ll gather up a list of all of the IP addresses from which spam comes from, then publish them. Then your local mail server can use that list to filter spam – you never see it!
In practice it doesn’t work so well…example: //www.mipspace.com/. The IP address for my server (XSquawkBox) is now on this list. Why?
MIPSpace is a list of IP Addresses associated with known commercial marketing companies.
Since my server is used for my own personal email and to run the SDK website, I’m not sure why I am on the list. I have sent them an email to clear things, but in general I hit an anti-spam/black-list bounce somewhat frequently now, and frankly I don’t have time to separately try to clear my name from every guilty-until-proven-innocent blacklist that pops up and screws up my email.
If I seem disproportionately grumpy about this, it could be due to one of two reasons:
-
Not replying to emails is generally bad customer service. (Okay, my in-box is backed up four months…that’s bad.) I don’t like the idea that a customer might perceive us (LR) as being unresponsive because some third party with no skin in the game decides to black-list us.
The blacklist has no incentive to be accurate – it’s not their lost customers if email doesn’t go through.
-
I’m not at all convinced that this is going to cut down unsolicited commercial mail and/or spam.
In the spam case, spammers can send from botnets – they have access to a huge number of ever-changing IPs. Unless we are prepared to blacklist the entire internet, the blacklists are going to pick up more and more false positives while spammers find ways to harvest fresh, untainted IP addresses. The whole IP-reputation strategy assumes that IPs are hard to change. In practice, IPs are very, very easy to change.
Commercial mail is a lost cause too – even if I am being solicited for commercial mail I don’t want, no program or automatic process is ever going to tell the difference between the confirmation of my invoice and a list of discounts from the same company. When it comes to commercial mail, the reputation damage has to be done to the company, not the IP.
(The company does have reputation to risk – if we are known as a company that doesn’t honnor a “do not subscribe” policy, then customers can choose to not buy our products.)
It could also be because I ran out of Viagra and don’t have a diploma from a prestigious non-acredited university.
I will be out of the office next week – it’s August, time to head for the mountains…no cell coverage, no internet, no computers, no electricity…no mountains actually. (This is upstate New York…mountainous to someone from Boston but not mountains compared to what Sergio normally deals with.)
As you know, LR often shows stellar judgement in managing release risk. So in true X-Plane tradition, I swapped in the new revamped website last night, just in time to head for the hills and avoid the fall-out.
Here’s the short version:
- I am wicked stupid.
- When I did the swap last night, I screwed up the files that manage the auto-update functionality, hosing the updater.
- I fixed these files this afternoon, once the message got back to me.
So if you saw weird stuff happen with the updater or the sim last night, please try again – it should be fixed. If it is still broken, please send an email to Austin and myself – one of us will hopefully be around.
I have also reskinned scenery.x-plane.com and wiki.x-plane.com to match the new site. If you find artifacts in those two sub-sites, please email me – I’ll fix it as soon as I can. The wiki site is a MediaWiki skin – it was pretty tricky to get it working, so it may be a bit before I work all the kinks out.
There is a bug in the newly released 931. When:
- Clouds are set to stratus and
- Pixel shaders are on and
- The airplane has an OBJ that uses ATTR_diffuse_rgb
the attribute is ignored, which typically makes things appear white. The primary example that has been reported to me is the throttle quadrant of the Piper Malibu.
This is simply a bug in the shaders (which is failing to apply the diffuse tinting to ambient-only lighting conditions); I have a fix, but I’m not sure how soon it will be released. We will probably do a small bug-fix release with this and one or two other things, but this is yet to be finalized, since Austin is out of the office this week.
After almost three weeks in Europe, I am now back home!
First, I would like to thank the entire team that put together the French X-Plane Congress – it was a wonderful event – you guys did an amazing job! It was great to see so many X-Plane people in one place (including the elusive Marginal!). The French X-Plane community is a strong group and it shows.
I would also like to thank Cris for setting up an informal Italian X-Plane get-together (complete with the Zurich delegation 🙂 for our last night. We didn’t get much sleep, but it was great to see so many people again before we flew back home.
At this point my in-box looks like someone dropped a bomb on it…it’ll take a while to dig everything out. The first priority of business is X-Plane 930 – we’ll do a series of betas over the next week or two that will hopefully put the release to bed. Once 930 is done, I can probably beta WED 1.1 and get back to work on scenery.
Posted in News
by
Ben Supnik |
Today Lori and I head to France – we will do a bit of site-seeing before the conference, and then Austin and I will go to Italy to work with Sergio.
So first, my email connectivity will be dubious at best for almost an entire month – if you send me a bug report and hear nothing for several weeks, you’re just going to have to wait…our internet connection in Italy doesn’t really deserve the name “internet connection”, and often doesn’t work at all. (If you need tech support, contact info at x-plane dot com – you should not be trying to reach me for tech support in the first place!)
I fixed a number of beta bugs this week; Austin will probably cut beta 11 before the conference, and then there will be a pause while we’re off the net. Once we get back, hopefully we can kill 930 off. (Most of the crash reports I’ve received turn out to be a single bug in the OBJ-handling code, fixed in beta 11, so hopefully the next beta will be stable.)
Now here is my request to everyone at the conference: please … go easy on me if I cannot remember who you are.
The tricky thing about a conference like this is that I mostly know people in the X-Plane community by an email address; if I see a face it is only once every few years. So if I jumble who you are, what you look like, and what you do with X-Plane, I apologize in advance. It is not a reflection on the merits of what you do, but rather an indication of the disorganized state of my (soon-to-be-jet-lagged) brain.
Posted in News
by
Ben Supnik |
I have received a number of emails bringing up crashes and performance problems in the X-Plane 930 betas – some of the writers are concerned that 930 might be a lame patch, going final with crashes and lousy performance.
To assuage this concern, let me make a few comments on where we are in the beta process, the likely future schedule, and the problems themselves.
The Schedule
X-Plane 930 has been an absurdly long beta. Going into the beta I had the mindset that we should take the beta slowly to have time to discover driver bugs on a wide variety of hardware – why rush and miss something?
I think we took this too far. To run a “slow” beta we have run other development simultaneous to the beta, but that in turn has stretched the beta to epic lengths.
We are starting to try to clamp down and close out the beta now, but it is going to get interrupted again. Austin and I will be traveling to attend the
X-Plane conference in France, and from there we will spend two weeks working with Sergio in Italy. Given how rarely we go to Europe, we cannot pass up the opportunity to work with Sergio in person – we have a few problems in the sim where getting the three of us in one room is the best course of action.
Unfortunately our internet connectivity during the trip will be limited, and we can only bring some of our equipment, so closing out the beta while on the road is really not an option. Thus there will be yet another beta delay. Hopefully when we return, we can close the beta out for good.
Performance Problems
I have seen a number of emails regarding framerate with 930. A few notes on framerate and betas:
I try to save framerate for last in a beta. Most performance problems have two possible causes.
- We communicate with the video card driver in a way that is fast on our systems but astoundingly slow on other systems. We discover this from slow performance in a particular piece of the code on other hardware.
- The new beta does something new that is more expensive than what the old build did, and users have not figured out how to (or do not have a way to) turn this more expensive option off.
The solution to case 1 is to use another driver call; the solution to case 2 is to make sure the rendering options provide a way to turn the feature off. (We simply cannot guarantee that a new, nicer looking feature run without a fps penalty – we can only give you a choice between better visuals and faster fps.)
Either way, framerate work tends to be the last thing on my beta list for this reason: other bug fixes may cause framerate problems, typically in category 1 – that is, a bug fixes makes use of a new driver call that we find out has hurt performance. Thus I try to do all performance fixes at the end of beta when we won’t be adding new code.
This means that in practice, I have spent nearly zero time looking at performance. I am just starting that process this week, so it will be a little bit before I find problems.
Unfortunately often performance problems manifest only in the hardware I do not own – despite having a pile of computers in my office (a pile that seems to grow deeper and less manageable every year) there are just a ton of systems out there. So a lot of the performance bugs will get fixed by users trying experiments and reporting back to me – a slow process despite some of the really great efforts by our users.
Crashes
Crashes sometimes are manifestations of gross code defects, but often they fall into the category of driver problems too. I will be working to piece together the puzzle of strange behavior over the next few weeks; usually the solution is to not do some action that we thought was legal but fails in some hardware cases.
Don’t Panic
As always, my final message regarding the beta is: don’t panic. When it gets quiet over the next few weeks, it is because of travel, and even once Austin and I are back in the office, it will be slightly slow going to piece together problems on hardware other than our own.
