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.

Despite many of the Lufthansa Pilots being on strike, Ben made it to Paderborn for the 13th FlightSim Conference in Germany. The event was held at the Paderborn airport, where the airport fire brigade pulled out two of their fire engines to the tarmac – the freed up hangar space was then used as the exhibition floor.

The FS Konferenz starts with a developer’s dinner, were FSX and X-Plane developers drink beer together talk about the development experience, then has a day of public exhibition, talks and interaction with users and ends in the traditional “captain’s dinner”.

We are extremely satisfied with this year’s conference. Not only were there more exhibitors and more visitors than last time, but also the impact of X-Plane is growing steadily. This became evident not so much in the public exhibition space, but in the little ad-hoc sessions we had with other developers. FSX developers who would not have touched X-Plane with a ten foot pole a few years ago were now asking us questions: How do I make a great landclass scenery? How do I make my add-on work with the X-Plane weather engine? How can I make 3d grass next to the taxiway in a way performance doesn’t suck? How do I program a gauge for X-Plane?

I think we are in for a round of new add-ons that will finally come to X-Plane.

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.”

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

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.

We should have had WED 1.4 beta days ago, but we do not. And the reason we do not is that some .jp2 files from the USGS do not import properly into WED. Others do, but going the ones that don’t are very common, and going beta with .jp2 files not working is asking for one hundred copies of the same bug to be filed within a day.

I now have a nasty hackworkaround for the problem: WED recognizes the particular projection that the problematic .jp2 files have and replaces the projection information with something the libraries we use can understand. This is a very brittle work-around but for now it’s all I can do. I’ll post again when the beta goes live.

This is another “Request for Comments” post – please discuss the proposal in the comments; if you comment asking about the OccRift your comment will be piped to /dev/null.

There’s one aspect of the library system that acts as a sharp unprotected corner, poking users on a regular basis: some scenery packs require other scenery packs to function. For example, many freeware airport scenery packs require OpenSceneryX. When the library pack is not available, X-Plane will not load the custom pack because it is missing art assets.* Users report this to us as a bug surprisingly often.

In my view, the big problem here is that a user has no way of knowing from X-Plane’s diagnostic message what library they should have installed. The diagnostic message isn’t useful because X-Plane doesn’t know either. All X-Plane knows is that there was a library path, no one is providing art for it, and therefore life isn’t worth living.

The Proposal: Library Pack Dependencies

My proposal goes like this:

A library scenery pack can declare its “official name”, e.g. “opensceneryx” or “proaddons/trees” or what-ever. Like plugin names, the goal is to pick a reasonably verbose name tied to your identity to avoid conflicts. This directive would go in your library.txt file.

A scenery pack that needs that library declares a need for the library by the same name.

When X-Plane tries to load an art asset from the scenery pack and it is missing, if at least one dependent library is not present in the system, then the error message changes to something like

The scenery pack “KLAS Las Vegas” could not be loaded because the library “OpenSceneryX” is not installed.

The log.txt file would contain complete details, but hopefully it would be clear(er) to an end-user what has gone wrong: OpenSceneryX is missng, and thus KLAS Las Vegas cannot be used.

How Is The Link Made

In order for this proposal to work, scenery packs that require library X have to contain a directive stating so. Therefore this proposal is not a cure-all for existing load problems. It would help in the long term as new scenery packs and libraries are created with these directives.

How would the link be made? WorldEditor (or other scenery editing tools) would automatically write the dependency into the scenery pack by looking at the dependencies in place on the author’s machine and copying them into the scenery pack when the user picks “Build”. Thus as long as the libraries had correct “naming” annotations (this does require library authors to update) then new packs made with WED would contain the right dependencies automatically.

Nasty Details

A few nasty details:

Library packs would need to contain both their “permanent” name and some kind of “human readable name” for error reporting.

The dependency statement in custom scenery packs would list the permanent names of needed libraries and copies of the human-readable names; if we need “librutrees” and it is missing, we don’t know that it’s real name is “Russian Trees 2.0″ unless this has been copied at build time.

Dependencies would also need an integer version number. This allows us to declare the case where the library is installed, but it is too old.

X-Plane’s built-in libraries would not contain dependency names because they are always available.

Dependency names for scenery packs would be written as DSF properties; there is no guarantee or need for the non-library scenery pack to have a library.txt file.

Open Issue: if a scenery pack declares a dependency and it is missing, should it be allowed to load if all of the art assets are present? This is the more permissive use case, but it implies something fairly strange is happening on the end user’s machine. Permissiveness might be desirable during the transition into using dependency names.

Will It Work

The library system has (for quite a few years now) allowed “place-holder” objects to be declared in a scenery pack that act as fall-backs for missing objects. The use case goes like this:

OpenSceneryX provides a “fallback” pack that is dumped directly into the scenery pack with blank objects for every library path.

If the end user has OpenSceneryX installed, they see the real art.

Otherwise they see nothing – the fallbacks are blank, and no error is generated.

It seems clear from the number of users who report a missing OpenSceneryX object as a “bug” that this is not working. Authors who use OpenSceneryX are not bothering to copy the “fallback” pack. This might not even be a bug – maybe the authors don’t want their work being viewed without OpenSceneryX installed. My guess, however, is that the authors just don’t know that the fallback pack exists. Since the authors have OpenSceneryX installed, they have no need for the fallback and can’t even tell if it is working properly.

My hope is that the library dependency scheme can be more successful in the long run because it requires no action by individual scenery authors, as long as a small number of library maintainers update their libraries. The work of annotating scenery packs is automatic.

* Please do not try to convince me that what X-Plane should do is ignore this problem and proceed. With the RFC proposed above, we could do something less drastic, like not loading the scenery pack if the library isn’t present. But I am strongly against “load what we can and keep going”.

If X-Plane treats errors in authorship as acceptable results, then authors trying to get actual work done will have to do a lot more work to detect human mistakes in their own authorship. We need a bug to be a bug.

I have a working prototype of a proposed modification for X-Plane 10.40: dataref-driven library regions.

The idea is simple: you can define a region in a library pack, and X-Plane will only load those art assets when datarefs written into the library.txt file evaluate to true.

One of the main usages for this is to implement seasonal or winter scenery add-ons that don’t require rebooting the sim to take effect. Right now if you want to change the look of the scenery you either:

Write a script to replace files inside X-Plane. This makes updating X-Plane tricky, but it lets you mod anything. Of course, some of those mods may not work in future versions.

Create a custom library pack that replaces library paths for the default art. This requires reboot to take effect but doesn’t affect updates and is stable.

With this extension, method 2 can be done without a reboot. The custom library art assets are put in a region and the region is set to only be available when certain datarefs are set to certain values.

Performance

Changes to the datarefs require a scenery re-load to take effect; that’s the cost of being able to fully change the art asset in the library. This does allow for a lot of flexibility, however – whole objects can be added or removed based on the date, for example. For seasonal use, if the user can decide on a season before flying, the reload should not be a facotr.

Textures vs Library Paths

The original proposal was to allow textures to be swapped by dataref. I changed to library paths because a number of the existing seasonal/winter add-ons for X-Plane change properties of art assets other than the textures; for example, they change specularity values or add normal maps that were not otherwise present. Only changing the library art asset allows for complete customization.

Proposed Syntax

The new syntax is a single library.txt line:

REGION_DREF <dataref> <comparison> <value>

e.g.

REGION_DREF myplugin/use_snow == 1.0

Datarefs can come from the sim or a plugin; all six conditionals (< <= == != > >=) are available. If more than one REGION_DREF line is present, all must evaluate to true to use the region.

Request For Comments

Please use the comments section to comment on this particular proposal. I’m going to be a bit fascist and nuke all off-topic comments. This is about a specific proposed feature, not a general news update.

I have working code for this; if you’d like to try a developer build, please email me.