The X-Plane scenery tools are open source; their bug database is open too, so that anyone working on the project can see the status of all bugs.
We recently merged the scenery tools bug base into the gateway bug base; in the process I audited about 70 open WED bugs, and finally closed all of the bugs where the original filer did not provide adequate materials to reproduce the bug. Typically these bugs had been sitting, waiting for user feedback for at least a year.
I’m looking at the feature request list next; it is also about 70 items long and needs some auditing. The old bug base had about a million “levels” of bug status, so it was easy to leave a bug in some partial state and ignore it forever. The new bug base does not, so I think I need to either set the feature request as something we want or kill it.
One problem: a lot of the WED feature requests aren’t feature requests at all; they are requests for changes in the underlying scenery system. E.g. if you say:
Allow WED to edit the height of the underlying terrain of the global scenery.
The only possible response is “unable”; WED cannot do this because the DSF file format cannot include this information; if you had some way to edit such data in WED, there would be no place to save it in the scenery pack that is built.
Really the request needs to be two-part:
- Allow overlay DSFs to change the underlying mesh heights of the global scenery underneath them.
- Provide an interface and exporter in WED to export the new “mesh modifier” added to the scenery in point (1).
The first change is a change to X-Plane and its file formats; the second one is to the scenery tools.
I don’t blame authors for filing the bugs against WED – as far as authors are concerned, WED is their interface to the scenery system; they want to see something new in WED, and if I do (1) and not (2), the job is not done.
But…the bug base is also my todo list, and having an item on the wrong todo list is a good way for it to get “lost”. If I look at mid-term feature requests for the scenery system in X-Plane, I will not find anything in WED.
I haven’t figured out what I am going to do with this, but one possibility is to simply move all valid feature requests on the underlying scenery system out of the WED bug base and into the X-Plane one. This will have the side effect of taking them private, but if the feature request is a legitimate one, I don’t think the original poster will need to provide more information.
This idea has been on my todo list for a while; I’m hoping to be able to squeeze it into X-Plane 10.40.*
Right now, you can place static aircraft in an X-Plane scenery pack using the library; if the aircraft come from our library, they can go into the gateway. If you use third party scenery packs for custom scenery, you can get even more aircraft types.
But this is not an ideal solution.
- If you don’t place static aircraft, airports with AI planes disabled look empty.
- If you do place static aircraft, they can conflict with real pilots on Pilot’s Edge, VATSIM, or any other online network.
- If you use the AI, X-Plane will park AI planes at the ramp starts, so you must not put ramp starts where the static planes are.
This is a clearly inflexible and non-ideal solution.
Here’s my idea for a fix: X-Plane places static aircraft at real apt.dat ramp starts dynamically based on library paths and apt.dat information.
This way:
- AI planes and static planes do not conflict.
- An airport can be “emptied out” for online flight.
- The level of static aircraft can be turned up and down based on hardware capabilities.
- We can vary the static aircraft over time and take advantage of ramp types in the apt.dat file.
My thought is to do this sooner (e.g. 10.40) so we can all be working on gateway airports that place static aircraft the new “right way” for future expansion. The longer we place static aircraft as OBJs, the more cleanup we will have to do.
* We have two release sizes: big and small. 1040 is the next ‘big’ release where crazy stuff can go and this feature is just barely complex enough that it needs a big release. Also, 1035 is already in beta so it missed that boat.
X-Plane 10.35 beta 1 is out – this is mainly a release to get hundreds of new and updated airports out into the world. There are also a number of bug fixes and some features and improvements to the sim.
- Release notes – including a list of all of the airports.
- Bug in the sim? Report it here.
- Borked airport from the X-Plane Airport Gateway? Report it…here! (You use your gateway account to report bugs with airports on the gateway – or to fix those bugs by updating the airport!)
X-Plane 10.35 beta 1 is meant to be a short, tight release to get out airports; I’d like to have the whole cycle over and done with in a week or two. We’ll do a larger longer release in the future where we put in bigger features and more code change and let it sit for a while, but this one has been kept lean.
If beta 1 turns out to be reasonably stable, I’m going to look at cutting a beta 1 of WED 1.4 next.
Posted in News
by
Ben Supnik |
Every now and then someone tries to set a taxiway in WED to “transparent”, and it pretty much never does what the author expects. Here’s a brief explanation of what’s going on.
Runways
“Transparent” is one of the many built-in surface types that runways can take on in X-Plane; more commonly you would pick asphalt, concrete, or grass. So what is a transparent runway?
The answer is: it is a runway with:
- No texture. That means you see nothing where the runway is. (This is fast by the way; we are not drawing the runway with a 100% clear texture, we actually don’t even place the polygons.)
- No physics. The runway does not change the physics from the underlying ground.
At this point a sane author is thinking: then what does a transparent runway actually do? Why have a no-op?
The answer is: user interface and lights.
- A transparent runway is still a runway; and thus X-Plane can know “hey, there is a runway 3L at KXYZ airport.” X-Plane even knows where the runway is (since the transparent runway has ends and a width) and can thus start your aircraft ont hat runway.
- A transparent runway has approach lights and all other types of runway lights. A few of the common approach light fixtures with “rabbit” strobes are incredibly annoying to build by hand (you can do it, but you basically need a plugin, a gajillion objects, and super-human patience).
So the transparent runway lets you do the graphics and physics with draped polygons and leave the hard things (user interface and lights) to us.
The primary thing to note: the physics are up to you too, and the expectation is that you’ll do the physics with the same tool you’ll use for the graphics. So if you put a draped .pol file down, you can set its surface type (with the SURFACE directive) to match the visuals of the texture you are using.
Taxiways
Taxiways follow the same logic, and thus they are really quite silly.
- Physics and graphics are up to you – the taxiway does nothing.
- There really isn’t anything else to a taxiway; it isn’t part of the UI, and you can place taxi lights directly using light/line strings in WED. You don’t actually need the taxiway polygon.
The fact that you can make a transparent taxiway in WED is actually a bug – the UI simply knows all surface types and does not have special code to say “hey, for a taxiway this is silly!”
What Transparent Taxiways Are Not
Transparent taxiways and runways are not a way to get the physics without the graphics. Instead, get the physics by putting a surface directive on your draped polygons.*
* There is one inefficiency here: if you have a huge draped orthophoto that covers a wide area, it will contain imagery that spans multiple surfaces: grass, concrete, etc.
Here is my suggestion: overlay a second polygon (with a repeating texture at very high res) with some kind of “grit” overlay. Place this only on the areas with concrete (or asphalt, depending on the kind of grit you use) and set the overlay’s surface type to match the overlay’s appearance. This way the polygons you must place for physics correctness at least add visual value too.
It’s very simple: if you want to file a scenery bug, it goes to the bug report form if it is actually a problem with X-Plane or the implementation of X-Plane’s core libraries. If the functionality actually needs to go into WED it goes into the public scenery tools code base, but if it’s a problem with the existing airport data, it goes into the X-Plane Airport Gateway bug database. Plugins have their own bug database. Simple, right?
Given the above, I can’t really be annoyed when authors, developers and users file their bugs in the wrong place. We have five bug databases running now, some public, some private, using three different bug database packages on at least three different servers, implemented in three different back-end languages.
The good news is: Tyler is creating the one bug database to end all bug databases.
Now, if you fly X-Plane and you don’t develop add-ons and you don’t create airports at the airport gateway, I won’t fault you if you don’t care at all. The rest of this post is going to be an (even more) boring discussion of bug databases. Go look at pictures on airliners.net; I won’t fault you for not finishing this post.
For the three of you still here: basically we are creating one unified bug database. The bug database is mostly private (to meet our internal development needs) with a front-end with variable access for authors to contribute. Bugs on some products will remain totally public (e.g. scenery tools), some bugs will private, and there may even be bugs where you can only see what you filed, a la Apple’s “Radar” bug filing system.
Gateway Airport Bugs
This all started when Tyler built a bug report system around the X-Plane airport gateway; it lets you use your airport gateway identity to report bugs on gateway airports. Thus a front-end to a real bug database was born. The front-end lets you have a single user log-in for both uploading airports and reporting bugs.
Scenery Tools Bugs
Tyler has now begun the next step: merging the scenery tools bug database into the new bug database. Thus the scenery tools bug database is temporarily closed to new submissions. All existing bugs will be transferred, but if you don’t have a gateway login you’ll need one to file future bugs.
The scenery tools bugs will remain fully public; the code repository is open source, so the bug base should be as well.
A small number of users have direct access to the scenery tools code repository, e.g. they contributed enough that we gave them their own set of keys. Those users will get direct bug base access as well; however, I think in the long term the front end will include all of the functionality that almost all users will need.
I’m hoping that the migration will be complete within a week or two, and be ready for WorldEditor 1.4 public beta.
Plugin Bugs
The X-plane plugin system has its own bug base; if the scenery tools bug database merge goes well, we’ll merge plugins next. The plugin bug base is a public bug base, like scenery tools, and will probably remain that way.
X-Plane Bugs
I don’t know what we are going to do with X-Plane bugs. The current bug report form does not go directly into our bug base, and I continue to say that that is a good thing: way too high of a percentage of the “bug reports” we get on X-Plane itself look like this:
Help! I just bought X-Plane 10 and it does not work; when I fly I do not see anything! Please help!
Steps to reproduce: Fly the sim!
If you have experience in software quality assurance, you can understand why I don’t want “bugs” like that piling up directly in the bug database; most of the bug reports have to get forwarded to customer support.
There is a bug in 10.32r1 Steam Edition – some kind of interaction between Steam and Gizmo causes Gizmo to crash. Since Gizmo is loaded on startup, this means users of popular add-ons like Skymaxx Pro can’t fly.
We are working on this now and I am hopeful we’ll have some kind of fix tomorrow. I’ll also post more details about the bug once we have more info. The crash affects X-Plane 10.32r1, Steam edition on OS X only, as far as we know.
In the meantime: if you get a crash on start with X-Plane 10.32r1, please file a bug. Please include your Log.txt file and any crash logs that you see go by. In particular, if a plugin is having problems only on the Steam edition (but not the Global edition of 10.32r1) or if a plugin besides Gizmo crashes, I would like to see it!
UPDATE: We have determined that the crashes are caused by Steam introducing an ABI breakage of the libstdc++ runtime when we use one of their distribution tools. We are now working with an engineer at Valve software to solve this. In the meantime, the Steam distributed X-Plane has been rolled back to 10.31.
UPDATE 2015-01-21: Thanks to quick help from Valve software, we were able to re-release X-Plane 10.32r1 on Steam today which now gets along fine with plugins again.
X-Plane 10.32 is now final – you’ll get an auto-update message when you run X-Plane.
Coming soon:
- 10.35 – we still have code to put the finishing touches on, but the plan is to release more Gateway airports in 10.35. This will not be the last gateway release (obviously 🙂 so if your airport was approved too late to make the cut, we’ll try to get the next release out soon. (Our goal is to keep gateway airports flowing rapidly so that everyone can get the full benefit of everyone else’s work easily.) I am hoping for public beta within a week.
- WED 1.4 – will include GeoJpeg2000 image support, improved orthophoto overlay creation, and importing directly from the Gateway. Again, I am hoping for public beta within week.
If you would like to know the status on the Oculus Rift, I suggest you comment on this post (even though it is off topic), any other post that is still open for editing, and every additional post we make (no matter how off topic) until Philipp posts an update; while he has not responded yet, he did assure me that he will make a statement if he gets at least 275 off-topic comments on the Rift.*
* This last paragraph is completely false, just another case of me being snarky and poorly behaved on the interwebs.
The real number is 374 posts. 😉
WorldEditor 1.4 is almost ready for beta, and among its new features (there are several big ones) one is very important to the X-Plane Airport Gateway:
- WED 1.4 can browse airports on the gateway and download scenery packs directly into the WED workspace.
“Direct download” is really important for a few reasons, some of which might not be obvious:
- It saves time. Getting a gateway airport, even if you just want to look at it, is much faster when you don’t have to download the scenery pack, unzip it, install it, then import it into WED. Once you use direct download, you’ll wonder how you lived without it.
- It prevents mistakes. We have seen airport submissions where a user clearly downloaded a scenery pack, imported only the apt.dat (but not the DSF files) and then uploaded it. We cannot take scenery packs like that, because they fundamentally remove the 3-d data from the airport. (A fundamental policy of the gateway is that if you upload a scenery pack and one already exists, yours can’t be worse than the existing one in some way. We have to always move forward.)
- It provides ancestry information. When you download and then upload directly from the Gateway in WED 1.4, WED provides the scenery pack ID of the original pack as the “parent” of the new pack. This means that when Julian goes to look at an upload, he can look at the “original” and more rapidly spot problems. If your pack is the same as the original except for taxi signs, he only needs to inspect taxi signs.
- It prevents data loss. DSF is a slightly lossy data format – that is, if you get your data back out of a DSF file, it won’t be exactly the same as what you put in. (It is like a JPEG image in that regard.)
More on that last point: DSF stands for Distribution Scenery Format – it was meant as a way to make final scenery packs; it was not meant as an interchange format for continuous editing. So users are constantly importing and exporting DSFs to do work, small rounding errors (“bit rot”) will creep into our 3-d, and features that were perfectly aligned might not be well aligned after 4 or 5 edits.
The internal format for scenery on the gateway is not binary DSF files, so doing round trips to the gateway has much less “bit rot” than importing scenery packs.
Finally, DSFs are tiles; if your airport spans a DSF boundary, all DSF features (polygons, fences, etc.) get split along the DSF boundaries.
So if you import a scenery pack that you downloaded, you’re getting the split version, which is harder to edit and work with.
The internal format of scenery packs on the gateway is not split, and thus you can edit the original in almost the same form as it was uploaded.
WorldEditor 1.4 beta should becoming in “weeks” (and hopefully not that many weeks); I’ll post here when we are ready for beta testers.
X-Plane 10.32r1 is now available to beta test – to get it, run the updater and click “get new betas”. Release notes here.
10.32r1 is another small patch aimed at fixing critical bugs. Hopefully soon (E.g. in a week or two) we’ll start a beta of X-Plane 10.35, which will contain new airports from the X-Plane Airport Gateway, as well as smaller feature enhancements that people have asked for.
Right now it looks like fixes for Yosemite will go into X-Plane 10.35 and improved DSF loading and longer DSF visibility will go into X-Plane 10.40 if the code is solid enough.
Hi Guys, it’s Chris. I haven’t written a blog post in ages. They’ve kept me locked in the basement like Milton Waddams, unwilling to let me out to see daylight until I finished X-Plane 10 Mobile. And they stole my #$%#^ stapler!
We recently released X-Plane 10 Mobile for iPhone/iPad and while the Apple users were ecstatic, some Android users were puzzled while others were frustrated.
“Will there be an android version?”
“When’s it coming to Android?”
“Where’s the Android version? 60% of all smartphones run on Android but I guess that Apple-Fan-Boys are more important in your company”
“Why do you guys constantly focus on iPhone first when most users are on Android?”
Before I get into the real point of the blog post, allow me to answer some of those questions. YES we are planning on shipping X-Plane 10 Mobile for Android. YES we have already begun development. We do not have a release date. We do not have any hints. The only thing that I can say, is that we want it out just as soon as you do. NO we do not view Android as a lesser/inferior platform…We value Android customers just as much as we value our iOS customers. A customer is a customer. I think we’ve demonstrated by supporting Windows, Mac and Linux all these years that we’re not trying to play favorites. We want everyone to be able to enjoy our products. BUT, that doesn’t mean that the costs of development and the speed and efficiency of development is equal on all platforms.
Historically, we’ve always developed for iOS first and then Android second. I’d like to be open an honest about our reasons and hope that even if you disagree with them, you’ll at least understand why we have historically developed for Apple first. I will warn you, everything I have to say is completely my opinion, my impression, my feeling based on my experiences. I’m going to sound a lot like an Apple “fanboy”. I will admit, I do have a high level of respect for Apple’s commitment to polish and detail, but I also own a dozen android devices and respect them for their cutting edge features, their openness and their friendliness to customization.
At the end of the day however, I’m paid to be efficient and thorough and my thoughts below explain why that means Apple has historically come first.
I will also warn you…I don’t want this blog post to turn into a flame war between Apple and Android users. We’re talking about phones here people, not religion. At the end of the day, they’re just small piles of plastic and silicon that let us surf the web, make phone calls and play games.
We Can’t Develop Apple and Android In Parallel
Sure, we do this on desktop by releasing Windows, Mac and Linux versions in unison 100% of the time. Developing for desktop is pretty different than developing for mobile. We use very few 3rd party frameworks on desktop and it’s an open environment. On a mobile phone, it’s a very closed environment. What this means is that developing Apple and Android in parallel requires a lot more effort than developing for Windows and Mac in parallel.
Can it be done? Absolutely! Plenty of companies are doing it. But they also have large teams with large expenses. We’re still a pretty small group of individuals and we like it that way. The tradeoff however is that we can only focus on one platform at a time.
One alternative that we could consider is delaying shipment of an Apple product until the Android version is done as well. That’s a loss for everyone. Apple customers lose out on having the latest software and Android customers may lose because…we don’t have the revenue coming in to support the Android development costs. That’s right…Apple sales get reinvested into the company to fund Android development!
As Ben mentioned earlier…Apple and Android mobile sales fund desktop development…and desktop development funds mobile development! This is a very important fact to remember. I’ll admit, we laugh and roll our eyes when desktop users complain about the company working on mobile products, and mobile users complain about the company working on desktop products….and android users complaining about us working on apple products and vice versa.
The company has found equilibrium creating both desktop and mobile products. There’s adequate revenue to fund adequate staffing to continue to develop both.
We Develop On Mac Hardware
This is no secret. It’s been this way since the company started. We just find Apple products allow us to be more productive and don’t get in our way.
Historically, Apple’s Mobile Platform Has Been More Mature
Apple had both a technological advantage as well as a time advantage over Android when they began.
Apple already had an Operating System, supporting frameworks and a development environment to leverage. Making mobile versions of those things required them to port existing, time-tested code to a new platform. From a stability standpoint, Apple had the advantage in that they already had the code, the engineers and the process in place to do this.
On the other hand, Google had to start from scratch. They had to put together a new team to create a new operating system to run new frameworks…and they had to create a set of tools for developers to use.
In addition to all of the technological advantages Apple had, they also had a head-start of well over a year. We were already selling X-Plane V9 for mobile before Android was even announced publicly.
That meant we were already established and familiar with the iOS platform as developers.
When I began the Android port for X-Plane V9, I had to pretty quickly put it down…and wait. Android at the time only supported Java apps. X-Plane is NOT a Java app. 99% of it is written in C/C++ and Android had absolutely no support at the time…and so we waited….and waited….and waited.
Finally, many months later, Android added their NDK which allowed us to have C/C++ support. But it was completely minimal. None of the standard libraries that we were used to using were available. This meant a lot of effort on our part to get anything done. If you’re not a developer, a reasonable metaphor might be a carpenter that’s trying to build a house, but he first has to build his own hammer, nails, square and saw because the tools he’s used to using don’t exist on this job.
Finally it came time to release V9 for Android. For iPhone/iPad, we uploaded our 400+mb app to their store and we were done. On Android however, the store had a limit of 25MB. So that meant we had to buy servers and write code to download the resources from a farm of servers. Again, this added more time and more complexity.
Apple Has Fewer Devices
For this latest release of X-Plane Mobile, we support iPhone 4S/5/5S/6/6+ as well as iPad 2/3/4/Air/Air2/Mini/Mini2 and iPod Touch 5. That’s 13 devices to my recollection. But it’s even simpler than that…because they all have the same GPU manufacturer, they all support the same PVR texture compression, and they all pretty much just work interchangeably from a development standpoint. The only major differences between them are the processor speeds and the screen resolutions. We can literally test on every single device and be sure that the app runs the way we expect it to.
As of the time of this writing, our X-Plane V9 is running on 7,072 devices. You read that right….SEVEN…..THOUSAND…..DIFFERENT……DEVICES. Each device has a different combination of CPU, GPU, screen size, screen density and drivers. We cannot possibly test them all. Admittedly, many of them “just work” and there are of course only a handful of CPU and GPU manufacturers to worry about…but at the very least, it means at least three different texture compression formats. PVR is proprietary and unless the mobile device has a PowerVR chipset, they’re not going to get PVR. So we have to support various formats. That requires three different versions of our app to be created and tested and distributed. That requires three different resource packages to be created and tested.
There’s just no way to have the same level of stability as we can have with the iPhone/iPad platform.
Apple Has Higher OS Upgrade Adoption
Without carriers and other manufacturers getting in the way, Apple can release a new OS with features and bug fixes, and we can be sure that they exist on the majority of the devices that we care about in no time. This means that if there’s a driver issue that needs fixing, it will make it out to the masses and eventually the problem is gone.
Android’s fragmentation has really hurt them in this area. We encountered several devices over the years that violated some OpenGL spec. We worked with the manufacturer to isolate the issue. They release a patch to fix the issue…and most users never had a way to get the patch because their phone carrier dropped support for that phone model.
Now the user’s stuck with an App that they paid for that doesn’t work and there’s nothing that we can do about it.
We like Apple’s Developer Tools Better
As I mentioned earlier, Apple’s developer IDE has been around for ages. We have access to various performance analyzers and can now even analyze an entire OpenGL frame, one draw call at a time. This means we can really tune the crap out of the app before we make it public. In addition, all of the tools come in a single package that just works out of the box. Apple has also always had a simulator that’s hardware accelerated. This means for a lot of things, i don’t need a device plugged into the computer to debug something.
Android’s solution was for less “out of the box” in that they were using various open-source pieces that all had to be installed and fit together just right. Android had an emulator that was not hardware accelerated. It took longer just to boot than it took me to find a phone in my house, get it, plug it in and push an app to it.
Honestly, I think both sets of IDEs are sorely lagging behind features that Microsoft’s Visual Studio has had since 2000, but I digress.
TL;DR
We develop for Apple first because it’s easier and faster for us. It allows us to get the product out the door, running as efficiently and as reliably as possible. When we port the app for Android development, we can be sure that most bugs that come up are specific to Android and are therefore much easier to resolve in a timely fashion.
We are not playing favorites. We have no personal issues with Android and have no personal ties to Apple. The day that Android becomes the faster and easier platform to develop for, it will be the one that we develop for first. It’s just a business decision!
In the meantime, Android users should remember that the way things are currently being done means that they sometimes have to wait longer for new updates, but the updates that they receive will likely be more stable as they’ve been tested harder.
I will also note that we are closing the time gap between iPhone and Android releases. In the past, we were over a year behind on the Android release…because Android didn’t exist. 🙂 Now that it’s becoming more established, the gap should be shrinking more and more.
