WorldEditor 1.4 Public Beta 1 Is Here

WorldEditor 1.4 public beta 1is available now.  First, the links:

  • Download from the WorldEditor page.
  • 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.

 

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in News, Tools | 11 Comments

X-Plane 10.35 Is Out Now

X-Plane 10.35 is now officially released! If you run X-Plane, it will prompt you to update. Lots of details here!

I’m still trying to get WED 1.4 to public beta – that’s high priority right now!

X-Plane 10.40 is currently in development. Austin has some new features that he’s letting people test-drive; I’ll post more about 10.40 in a few weeks.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in Uncategorized | 20 Comments

GeoJP2K Makes Me Want to Stab Myself (or Where is WED)?

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.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in Scenery | 11 Comments

RFC: Library Dependencies

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.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in File Formats, Scenery, Tools | 18 Comments

RFC: Dataref-Driven Library Regions

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:

  1. 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.
  2. 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.

 

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in File Formats, RFC | 12 Comments

10.35 Release Candidate

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.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in News, Uncategorized | 15 Comments

Windows and Scenery Tools

Note: This post is a boring discussion of the state of the scenery tools. If you use MeshTool or you work on the scenery tools code – or would like to modify MeshTool’s code – read this post!  If you just want to know the status of the Oculus Rift or whether we’ve changed X-Planes’ fogging model, a little bit of your soul will die if you read this post.

Last weekend I discovered that MeshTool 3.0 seemed to “just work” for OS X; when I mentioned this on the blog I received a number of “I’d like a copy” emails. When I further emailed with those authors, I found that they all wanted a Windows build.

Unfortunately the Windows build of the scenery tools was in a state of disarray.  The Windows build was until recently based on running mingw and trying to make Windows look like Linux. This has a few problems:

  • Windows is not Linux.
  • Mingw is often a lower-tier priority (or non-priority) for the developers of the libs the scenery tools use.
  • It’s not easy to get a fully functional mingw environment to begin with.

A while ago Ted moved WorldEditor to MSVC.  This was a pretty big win: debugging actual problems with WED is about a billion times easier in MSVC (which has one of the best visual debuggers, um, ever) than trying to use gdb via mingw on Windows.  It also sets WED up to be worked on by actual real developers; if you are a programmer and Windows is your preferred platform, MSVC is mandatory; gcc/mingw/gdb is a foreign country.

So in response to MeshTool for Windows being borked due to mingw/Windows issues, I horse-traded with Chris: I’d do a bunch of his dev tasks if he’d port MeshTool to MSVC.

Will he succeed? I don’t want to say yes until it’s a done thing, but as of yesterday he did have MeshTool running, only to discover that libtiff was missing AdobeDeflate support. But I think his efforts do look promising.

The Plan

So here’s my plan for scenery tools:

  • MSVC will become the supported compiler for all scenery tools: WED, MeshTool, and the various command line tools (DSFTool, DDSTool, etc.).
  • The scenery tools will come with an MSVC .sln/.proj set to support them.
  • We will let mingw support die.  (If you want to make mingw work, send me patches, I’ll take them! But no one involved now has the expertise to keep mingw working, and it is already significantly broken.)
  • Gcc/Makefiles will be the supported platform for Linux, working on modern distros.
  • X-Code 3 will remain the supported compiler on OS X until we have time to do a Yosemite upgrade.  (A Yosemite upgrade is badly needed, but it’s also just a ton of work; I have not had time to even start on this.)
  • “RenderFarm” (the internal DSF tool we use for global scenery) will be the only non-MSVC-ported tool.

For libraries, Mac and Linux will continue to use the “libs” archive that exists now, which is a series of tarballs and a makefile that creates a static library pack for WED/Meshtool to use.  Libs is a GIT submodule.

For libraries, Windows will use a different sub-module that contains source materials and already-compiled Windows binaries for all needed libraries.  Windows users will simply have to get the submodule from GIT and they can immediately compile WED.  (This is already how WED on MSVC works, but we’ll form a submodule so that the main repo doesn’t get huge.)

For libraries, when we get to Yosemite, we may move OS X to a precompiled-binary strategy; we’ll have to see what the state of libraries is.

32-vs-64-bit

Right now the Linux scenery tools are compiled to the native ABI of the machine they are built on; binary builds are built on Ubuntu 12.04 LTS 64-bit, so those are 64-bit builds.

Windows is currently a 32-bit build; I believe Chris is working on both 32 and 64-bit support.

Mac build are limited to 32-bit due to the use of legacy APIs.

The long term direction of the scenery tools is 64-bit only!  At some point the “next” version of the scenery tools may be 64-bit only builds, and this may happen within the X-Plane 10 version run.  The scenery tools are free and not part of X-Plane itself; we don’t consider ourselves to be under any obligation to maintain 32-bit support indefinitely.

For the scenery tools, 64-bit support is a win because it allows the tools to access relatively huge source data sets.  There are global DSFs that currently can only be built on Linux because they require a 64-bit RenderFarm to load all road data without crashing.

Whither Betas?

There’s some restructuring to the various projects’ we’re doing as a result of all of this; I’m going to hold off WorldEditor beta until we’re done.  I’m hoping this will end in “days” – that’s all of the time Chris and I allocated for it. Therefore hopefully:

  • WED 1.4 public beta 1 next week. (I think I said that last week – I forgot to schedule in time to get the flu.)
  • MeshTool 3.0 public beta 1 next week too.  We’ve run a private beta on Mac/Linux and confirmed that MeshTool 3.0 basically works.  We’ll do a Windows build publicly.

We should also have a 10.35 release candidate Real Soon Now™.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in Development, Scenery, Tools | 9 Comments

An Update on Our Quest for the One Bug Base to Rule Them All

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
  • the Scenery Gateway itself.

All you need to do is:

  1. Create a free Scenery Gateway account and log in.
  2. Click the “Report a Problem” link in the navigation at the top of the page.
  3. 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?
  4. 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.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in Development, News | 4 Comments

X-Plane 10.35b2 and Other Betas

First, X-Plane 10.35 beta 2 is live.  If you had beta 1, X-Plane will ask to update.  A few bugs that made beta 1 unmanageable are now fixed:

  • No more crashes when using multiplayer.
  • Joystick axis assignment UI works.
  • EFIS App support is back in.

See the full release notes for more.

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.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in News | 36 Comments

I Nuked Your Bug

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:

  1. Allow overlay DSFs to change the underlying mesh heights of the global scenery underneath them.
  2. 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.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in Uncategorized | 15 Comments