Tyler is migrating the website to new hosting, and so the old server has decided to flip us one last middle finger. Needless to say, if you’re seeing this page, you probably waited for 30 seconds to get it. 🙁
I have WED 1.4b2 ready, as well as a cut of the command line scenery tools pack and MeshTool; I will post all of them once the server is migrated. Not a lot of good posting the files if you can’t download them.
Hopefully the website will be full speed again early next week, if not sooner.
UPDATE: Tyler says the site migration is finished. If you’re still having problems accessing X-Plane.com, demo downloaders, or sim updates, give him a shout at tyler@x-plane.com.
X-Plane 10.40 will have an option to load a larger local region of DSF scenery. For as long as I have been involved in X-Plane (back to X-Plane 6 as a user) the local scenery region was 3×2 tiles (each 1×1 degree in latitude and longitude). With this option, the region is 4×3.
What this gets us is the option for a longer viewing distance before we have to transition from the higher detail DSF scenery tiles to the lower resolution whole-planet render. In X-plane 10 the planet render actually has shape, but the resolution is low; if you see it up close, it does not look good.
Some fine print:
You will only be able to use this option in the 64-bit build of X-Plane. The 32-bit version does not have enough memory.
Combining extended DSFs with heavy third party scenery may be unacceptably slow. For example, Alpilotx was able to run extended DSFs with the HD meshes, but his computer has monstrous amounts of RAM (64 GB I think??). I’m pretty sure extending with the UHD meshes is a non-starter.
Load time shouldn’t be too bad; this change also includes a re-work of the DSF loader that takes better advantage of multi-core hardware. If you have a 4-core machine your DSF load time shouldn’t be worse, even with extended DSFs.
Here are two sets of pictures taken over the demo area at extreme res on my PC; this shows the interaction between atmospheric scattering and loading more DSFs. The camera is at about 30k feet.
Normal DSFs, no scattering
Normal DSFs, with scattering
Extended DSFs, no scattering
Extended DSFs with scattering
The combination of pushing the transition to the planet “out” away from us and using scattering to remove color detail starts to get something that looks more like the real world.
Note that to get the match-up in the lower right, you must have Earth Orbit textures (which come with any full install) and you must be in extreme res or the planet starts to get fuzzier.
Here’s another set.
Normal DSFs, No Scattering
Normal DSFs, Scattering
Extended DSFs, No Scattering
Extended DSFs, Scattering
In the long long term, I expect the planet to improve in render quality (with at least a 2x boost in image quality, and perhaps better than that in mesh shape), and I expect scattering and other lighting to improve in quality.
I do not expect to further extend the DSF box beyond 4×3; I think that the planet can improve to further “bridge the gap.”
Philipp and I will be at the 13th German Flight Simulation Conference in Paderborn this weekend. (Well, I am crossing my fingers that I can still make it despite the lufthansa strike.)
If you ask about the OcRift in person I won’t be able to just delete your comment. 🙂
Report bugs on the gateway – the scenery tools have their own tab.
If you have reported bugs against WED in the past and the bug says “please retry in WED 1.4” or “fixed in WED 1.4”, please go re-check the bug now!
The online user’s manual is up-to-date; pick WED Manual from the help menu to see it and read about the new features.
I’ll try to write some release notes up later but there isn’t a procedure in place for WED for that right now. Some major features:
Download from the X-Plane Scenery Gateway
I think the most important feature of the new build is the ability to directly download an airport from the scenery gateway. This feature is intended for authors and editors who want to modify and re-upload the scenery; in this case direct download has a number of advantages:
It’s a lot quicker and easier.
Better data quality: there’s a lot less data precision loss in the direct download because the format used is not binary DSF; overlay elements spanning DSF tiles will not be split when you get the airport directly.
Version tracking: when you download from the airport, WED knows the scenery ID you downloaded from and sets up a history chain when you re-upload. This sets us up to more easily track changes and understand what are major airport changes vs. minor editing changes.
I think direct download is going to be especially good for bug-swatting. If an airport had one small problem, it used to be that most of the work in fixing it was the import and export; this is now totally automated, so you can just download, edit, re-upload.
Orthophoto Creation
WED 1.4 builds orthophoto draped polygons for you. In this workflow you:
Import source imagery, e.g. a TIFF or PNG. If it’s a GeoTIFF, WED places it for you. (GeoTIFF placement is fixed in WED 1.4.)
WED converts the image format to DDS when you build the scenery pack.
WED makes the draped .pol file for you, and puts a correct LOAD_CENTER directive in place to get paging.
It’s a much quicker and simpler work-flow than the old scheme from WED 1.1 (which was basically a hack I put in for Sergio to get the LOWI demo area built for X-Plane 9).
If you want to make your own .pol files you can still use .pol files directly – WED works either way.
GeoJPEG-2000 Got Kicked Out
I turned off GeoJPEG-2000 support in this beta; our testing indicated that .jp2 was super-unstable and unreliable. I’m not sure whether .jp2 will make it into this release or whether we’ll even keep the feature, but one thing is clear: it’s holding up an otherwise solid beta. There’s no reason why anyone should have to deal with broken GeoTIFF location, crashes on certain library scenery objects, or having to manually download from the Gateway for longer than necessary.
I still need to do more investigation into the crashes we’ve seen but so far the signs don’t look good – there are multiple indicators that point in the direction of .jp2 not being ready for prime-time.
Note: Oops – I wrote this a week ago and forgot to post it. 10.35 will probably “go final” shortly.
If you haven’t tried X-Plane 10.35, please do. Check “get betas” in the updater to get it. Just one bug fix and a license file in the release candidate. A Steam RC should come soon.
Chris took a sledgehammer to the Windows build materials for the scenery tools and pretty much rebuilt everything for Windows; I’ll have betas in a day or two.
UPDATE: The RC is available on Steam also. To get it, right-click on X-Plane in the Steam library, click the “BETA” tab, and then select the beta to opt-in to.
Ben posted a few weeks ago about our quest for “One Bug Base to Rule Them All“—our goal of cleaning up the fact that we had no fewer than five bug bases running, each for different products, with no communication between them.
This situation is understandably confusing—bugs that dealt with the Airport Scenery Gateway wound up in the WED database, bugs filed against WED wound up in the X-Plane database, and so on.
I’m happy to report that we’ve taken the first steps toward unification: today, we have just one place to report issues with:
any of the scenery tools (WED, MeshTool, the AC3D plugin, etc.),
airports and scenery packs in the Gateway or in X-Plane, and
Click the “Report a Problem” link in the navigation at the top of the page.
Use the tabs to select the type of bug you’re reporting: does it deal with an airport/scenery pack, the Gateway site, or the scenery tools?
Fill in the reporting form with as much detail as you can, and hit Report Issue.
In the future, we’ll move to a similar system for the plugin system and X-Plane itself. At that point, we’ll have one page (probably on the main X-Plane site, rather than the Gateway) with a tab for all the things you might need to file a bug for.
EFIS App networking support will remain in X-Plane for the life of v10. We thought that no one was using this option, and interestingly, none of the bug reports were from actual EFIS-App users. (If you are using EFIS app with v10, maybe drop us a line? EFIS app has been discontinued for a very long time.)
It turns out that a third party app is using EFIS App’s network output. This is sort of weird; the output is labeled for EFIS App and isn’t a published “thing. On the other hand, it’s really easy to figure out how the option works and jump on it, and that’s apparently what the developer did.* So we won’t pull it until a major version break.**
WorldEditor Soon
I think we’ll get a WorldEditor 1.4 public beta early next week; I’m just going through the last beta-stopping bugs now.
Linux Nerds: I need help with this bug. Basically we don’t have a way for me to compile a cross-distribution WED release on Ubuntu (Debian) without CURL going somewhat haywire.
If we don’t come up with anything better, my default action is going to be to compile on Ubuntu and if it doesn’t work on your distribution, you can rebuild from the open source. That’s not awesome, so if anyone has a better idea, I’m interested. (But: doing several builds on several VMs for several distros is not on the table. I can’t spend that kind of time on Linux build process.)
MeshTool Anyone?
I have a build of MeshTool that can build X-Plane 10-style DSFs (with the new terrains). If you’d like to try it, please let me know.
Edit: if you want to try an early private beta of MeshTool, please email me. My goal is to have 2 or 3 users try a private build first to make sure it more or less works; then we’ll do a public beta.
* It turns out that the EFIS App output is just the regular data output on another port. More modern options like Xavion and Foreflight really have their own proprietary protocols.
It begs the question of whether we should intentionally have a ‘handshake’ with our own app to guarantee that we don’t have to do third party compatibility on what we consider our own internal interfaces.
** There’s an easy work-around for the authors if they want their product to keep working with the next major version: go back to using X-Plane’s regular UDP data output, which is actually a published thing.
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.
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.
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.
