10.25 is coming along well; if nothing really bad happens, we should have a beta either for this weekend or next Tuesday. There are just a few remaining bugs left.
I’ve been looking through the collection of submitted lego brick airports, and I am impressed with what the community has done. In the collection I count 237 customized airports, with a total of 32,152 object and .agp placements. So I am thrilled that people are using WED and starting to bring life to their local airports.
(I’ll post some pictures and we’ll have an official list later; right now I’m still in the process of checking the airports to make sure they don’t crash the sim, etc.)
There’s a lot more to blog on the subject of airports and WED, but one thing has become immediately clear from seeing people’s work and the questions that have come up from LR employees: the library is a big cluttered mess and it makes it hard to find and use art assets properly.
The WED 1.3 code (available in GIT for nerds) already has better library filtering and sorting (another one of Ted’s contributions) but I’m trying to get a very basic quick filtering feature into WED 1.2.1 and X-Plane 10.25: categorization of the library.
In my current design I have three categories:
- Public. This is the stuff you should be using to make scenery packs. The lego airport bricks are all public.
- Private. This is stuff we meant to use as sub-parts of other art assets; they really should not have been exposed in the library. (The right thing to do is to use the parent art asset.) Often the private sub-parts contain fractions of a complete art asset and don’t make any sense on their own.
- Deprecated. This is stuff that used to be public, but now isn’t a good idea to use. Often the deprecated art assets contain empty stub objects, in place only to keep old scenery packs from crashing. For example, there are actually library paths for X-Plane 7 ENV radio towers – these would be marked as deprecated.
The categories affect WorldEditor, not X-Plane! If your scenery pack uses a private art asset, it will work just as well under 10.25 as it did under 10.20. The goal is to filter the library in WorldEditor, so that authors can:
- Find the good stuff faster.
- Not use internals and old stuff by accident.
In its first revision, WED 1.2.1 won’t yell at you or flag you if an art asset is private; it just won’t show it in the library for additional use. We’ll work on a more refined set of interfaces in WED 1.3.
This is a major architectural change to the library, and I’m not thrilled to have to shotgun it into X-Plane 10.25. But the situation right now is pretty unmanageable, and I hate to see people adding private art assets into their scenery for any longer than necessary.
Authors: comments welcome! If this is going to break how you make scenery, please say so. If there are other ways you think this feature should work, please say so.
Everyone else: I’m going to be a hard-ass and delete off-topic comments. This post is for authors to discuss public, private and deprecated library paths only.
Now that the final season of Breaking Bad is over, we can finally all get back to work on X-Plane!
I kid – while it is true that we maintained an internal betting board on the ending of the fifth season of breaking bad, we’ve actually all been heads down working on new code for the last few weeks. A few bits of status update:
It looks like we will cut a 10.25 with new art assets after all. Currently in the queue: Albert’s new terrain textures, a few library tweaks to get the sim ready for DSF recuts, revised urban terrain textures for cold wet climates, and texture optimization for the airport scenery library.
About those urban terrain textures: Alex has revised urban terrain textures for cold wet climates, and they’re a nice improvement over what we shipped. Our goal is to use the new revised urban textures for all climates, but we don’t have the variants yet. I’m going to put the cold-wet ones into 10.25; we’ll get the rest out when they are available. (Why delay a fix for New York just because we don’t yet have a fix for San Diego?)
I’m working with Robin to try to get some user-submitted lego-brick airports into the update.
Alex has a bunch of partly done autogen work, but based on my last discussion with him, it looks like it needs to go into a bigger AG update and can’t be distributed in pieces, because a lot of the autogen shares common textures and objects for performance.
10.25 won’t be a big code change – we’ll have a fix for Foreflight compatibility and a few other small bug fixes, but 10.30 will be the next major code-changing release. The goal of 10.25 is just to get art out.
Alpilotx is re-importing OSM data this weekend; I’m not sure what the time frame will be for DSF recuts, but my goal is to make sure that 10.25 can run recuts. This way we can push recuts before 10.30 if that’s how things get done.
Posted in News
by
Ben Supnik |
Over the last few months we have been lucky to have Ted Greene working for us as a summer co-op student. You may have seen his commits if you look at the open source WED repository. Ted is heading back to school now, so this post both discusses a little bit of what he accomplished and serves as public recognition of his hard work.
Ted spent the summer working on ‘workflow’ items for WED – that is, things that make WED easier for authors to use. One of the main features he implemented was a new ortho-photo importer.
If you have a GeoTIFF you wanted to use in WED 1.2, the process goes something like this:
- Make an overlay image out of your TIFFs.
- Run the “make orthophoto command” which will create .pol files and place them in the project.
- Delete the original overlay image, which unfortunately looks almost exactly like the POLs in WED.
- Resize the TIFF to a power of 2.
- Grind the TIFF in XGrinder.
- Edit the .pol file in WordPad to use the DDS file.
- Edit the .pol file i WordPad to add LOAD_CENTER (if you remember) – good luck getting all of those numbers right!
- Export your scenery pack.
- Get some astonishing error in X-Plane, because the odds of getting all eight steps right is approximately 0%.
The new process with Ted’s code is much better:
- Import the TIFF files into WED as orthophotos.
- Hit control-B to build your scenery pack.
- Go get a coffee – WED is grinding your TIFFs to DDS for you, which is a time-consuming operation. Don’t worry, it won’t grind them again unless you change the source file.
- Open in X-Plane and enjoy your orthophotos – with correct load-center directives!
No hand-editing pol files, no chance for human error, and of the four steps, two you already do now and one involves beverages. What’s not to like? This screenshot shows the results of importing the TIFF files into WED and the resulting scenery pack.
This level of automation is how all of the scenery tools should work and it’s nice to finally reach a point in WED where we can add this level of convenience.
For The Nerds
WED is an open source project, and this next part only affects users trying to work with the WED source code. (If you are not a programmer, you may want to skip to the next section.) Ted’s finishing the new Orthophoto importer completes the removal of CGAL from WED.
CGAL is an open source library that is critical to the DSF generation code that makes the global scenery. CGAL is also a very complex, heavy-weight library that can be quite finicky about compilers, brings in a lot of dependencies, and is generally hard to work with on Windows.
By dropping CGAL for WED, it makes the WED code significantly more accessible. Ted created a complete MSVC 2010/2012 project for WED, so you can just download MSVC Express, open the project and hit ‘compile’ – all of the libraries are included in the repository in binary form.
(For Mac users, unfortunately we are still stuck on X-Code 3.2/10.6 – to move WED to the modern development tools we will have to purge old APIs that Apple has dropped – just like we did on Desktop.)
We are not dropping the makefile system we use on Linux, and it should even still work on Windows, but finally mingw is no longer a requirement to get started.
Removing CGAL from the project should make a Lion-compatible Mac build possible too at some point.
Upcoming Releases
At this point I expect to do a WED 1.2.1 bug-fix patch relatively soon with a few usability fixes. Ted’s work will go into WED 1.3; I don’t know what the release time frame for 1.3 will be.
Posted in Tools
by
Ben Supnik |
…are greatly exaggerated. I was out of the office last week on vacation (for the first time in 2.5 years) and didn’t bother to post first. Austin and Chris were also out on vacation for at least a week each.
We are not dead, we are not out of business, and we are definitely not stopping development of X-Plane 10! Austin has been working on X-Plane since approximately 1637 (well, the 90s at least) and he is not going to stop now.
Stuff We’re Working On
I am still working with Alpilotx and others on DSF recuts. This work is moving forward, but my side at least is going slowly because I am also working on other features that are pre-release and have not been announced.
I also had some time to do some OpenGL modernization over the last two weeks before vacation. This code does not directly improve X-Plane, but it sets us up to improve performance: once we have more modern code we can get access to newer GPU features.
Upcoming Releases
At this point I am looking at two releases:
- Some kind of short-beta release to roll out new terrain textures, some of the userr-submitted lego-brick airports, and possibly a few small bug fixes.
- Then a long-beta release, where we could put a major feature or two, and also ship code that needs more serious testing (e.g. the OpenGL modernization).
Over the last few years that I have been working on X-Plane, the time between major patches has been steadily increasing. Back in X-Plane 7 or 8, we might have a major patch every three months; with X-Plane 10 that interval is more like six months. I think this longer time between major betas is good for X-Plane 10:
- It lets us run longer 8-week betas without being in beta perpetually. This gives third party developers more time test.
- Fewer larger patches means less work for third parties, since a major patch means retesting add-ons.
- X-Plane 10 is a much bigger product than X-Plane 6 – it needs a longer development cycle.
Still On Fire?
The other factor making it seem quiet around here (besides slower major betas and the occasional time off is that we are finally moving out of fire-fighting bug-fix mode into doing structured development. When we were fixing bugs in X-Plane 10.0 as fast as possible, a bug fix was followed by a beta and announcements as quickly as possible.
Now that we have a stable 64-bit build out, we’re writing code that looks to build the future of X-Plane, rather than just fixing its past. So the quiet you hear now should hopefully turn into good features in the future.
Posted in News
by
Ben Supnik |
X-Plane 10.22 release candidate two is now officially final – if you did not participate in the beta program, you will get the update via auto-update. This build provides X-Plane-managed memory allocation for Lua-based plugins on Windows, which should help the problem of Lua plugins running out of memory.
If you have add-ons based on SASL 1.0 64-bit, you will need to get an update from the airplane vendor that uses SASL 2.0! Please do not report SASL 1.0 64-bit crashing on Windows; this is a known problem with SASL 1.0 64-bit that was fixed with SASL 2.0 64-bit.
Posted in News
by
Ben Supnik |
WorldEditor 1.2 is done and declared final!
Laminar Research, creators of the X-Plane flight simulator franchise, is pleased to announce the availability of WorldEditor for X-Plane (WED) version 1.2.
WorldEditor is an airport scenery creation and editing tool for Laminar’s X-Plane. WED is intuitive and easy-to-use, as it features drag-and-drop scenery creation in a graphical environment that is designed for the typical X-Plane user.
WorldEditor takes a graphical CAD-like approach to creating airports. All airports are made up from a collection of different items or entities of a specific type. For example; runways, taxiways, windsocks, signs, and buildings. A runway has length, width, surface type, lighting and taxiway signs for example. WED is organized to create and edit each of these different items on an individual basis, so a user can add an item, then edit it’s characteristics or attributes at will.
A key feature of WorldEditor is the ability for a user to create an airport scenery and then send his or her creation to Laminar’s airport scenery database service. Once checked by Laminar for acceptability it is then included in the airport data when X-Plane users receive automatic X-Plane updates from Laminar.
Robin is ready to accept submissions of airport layouts including ATC traffic flows and default airport object placements using the new “Export for Global Database” function. We are also working on tutorials and additional documentation beyond the WED user manual.
X-Plane 10.22 release candidate one is now posted. If things go well, we should be final in less than a week.
Aircraft authors: if your airplane uses 64-bit SASL 1.x for Windows or Linux, update to SASL 2.0 as soon as you can! The old 64-bit SASL 1.x builds do not correctly support LuaJIT memory management, and will not run on X-Plane 10.22 and newer.
Albert has new terrain textures to release, but I think we will put this in a separate update (e.g. 10.25) to keep the 10.22 patch small. I think that the next autogen update is not ready yet.
Posted in News
by
Ben Supnik |
A new 10.22 beta is out – it fixes a crash-on-startup in beta 1 that some users were seeing.
If you can’t auto-update (because the sim crashes before the update message appears) simply run your installer, pick update, and check “get new betas”.
Posted in News
by
Ben Supnik |
There are a number of changes to how X-Plane 10.22 beta 1 handles memory for LuaJIT plugins.
Windows and Linux 64-bit: X-Plane Manages Memory
Previously, 64-bit Windows and Linux LuaJIT plugins had to allocate their own memory, and often they did not succeed. 64-bit LuaJIT can only use certain special areas* of memory; if, by the time a LuaJIT-based plugin loads, some other code has used all of that memory, then the LuaJIT plugin cannot operate.
With 10.22 beta 1, X-Plane pre-allocates as much low memory as it can and then provides it to LuaJIT plugins on demand.
This change should fix problems where LuaJIT-based plugins run out of memory, fail to load, etc. on Windows with lots of scenery packs and rendering settings cranked up.
If you ship a plugin that uses LuaJIT, make sure your plugin can use the memory provided by X-Plane. The process for doing this was defined during the X-Plane 10.20 beta and has not changed, so plugins that are coded correctly will just work.
OS X 64-bit: Crash Fix
Previously for OS X, when a LuaJIT used up all available low memory that X-Plane had reserved, X-Plane would crash. This was a bug in our code; X-Plane now correctly simply tells the plugin “sorry, we’re out of memory for you.”
I have said this before in forum posts and I will say it again: your plugin should not exhaust Lua memory! There is typically over 1 GB of LuaJIT memory available; if your plugin exhausts it all, your plugin is doing something wrong.
So it’s good that this won’t crash, but if there were plugins that were causing this crash, those plugins probably need to be carefully examined – their memory use was way too high!
New Stats to Monitor Memory Use
There are two new “stats” in DataRefEditor (pick the “show stats” sub-menu option) for Lua memory use: lua/total_bytes_alloc and lua/total_bytes_alloc_maximum. The first one tells you how many bytes of memory all Lua plugins are using, the second shows the highest memory allocation ever recorded. A few notes:
- This only measures memory use provided by X-Plane. So 32-bit plugins will show “0” for both, because in 32-bit plugins, X-Plane does not provide memory to Lua.
- Lua is garbage-collected, meaning it allocates memory for a while, then periodically throws out unused stuff. So it is normal to see this value slowly rise over time, then periodically drop down by quite a bit. It is not normal to see these values increase indefinitely without ever dropping down.
- If your 64-bit Windows plugin uses LuaJIT but registers “0” for lua/total_bytes_alloc, your plugin is not getting memory from X-Plane and is not working correctly; fix your plugin ASAP!
- This memory includes allocations by Lua scripts. It does not include memory for textures, sounds, and other “native” resources provided by SASL or Gizmo. So you should not see a 4 MB allocation just because you made a 1024 x 1024 texture, for example.
* The lowest 2 GB of virtual memory, to be specific. Most other code running in X-Plane (the sim itself, the OpenGL driver, OpenAL, the operating system, other plugins) can use any memory, but they tend to consume some of this “LuaJIT-friendly” memory during normal operations. Thus X-Plane’s strategy is to pre-allocate the LuaJIT-friendly memory and reserve it only for LuaJIT use.
X-Plane 10.22 Beta 1 is available now (release notes, bug reports). To get this beta you’ll need to check “Get New Betas” in the X-Plane 10 Installer’s update screen.
This is a very small bug fix patch; there will not be an art asset update, and we’re only including three fixes that we think are critical enough to release ASAP, as well as support for the latest Xavion iPad app.
I will comment on Lua memory allocation in a separate post.
Landing Gear Problems
Plane-Maker 10.21 has a bug: when you save your airplane, the weight distribution coefficients for landing gear are calculated incorrectly, causing the plane to tilt or lean on the runway. Astute users noticed that resaving the plane in Plane-Maker 10.20 fixed the problem.
This bug is fixed in Plane-Maker 10.22; if your plane has “the leans”, just re-save it in Plane-Maker 10.22 and the problem should resolve itself.
This bug was always a bug in Plane-Maker, not in X-Plane itself; airplanes whose data was not saved incorrectly would fly correctly in 10.21, which is why it took a while for the bug report to get to us.
Copy Protection
First: let’s agree to disagree re: copy protection. No one likes copy protection, and we can all agree that copy protection is always imperfect. (That is, it never avoids annoying users completely and it never stops piracy completely.) Users who buy products and the companies that sell them often disagree about where to draw the line between deterrence and annoyance.
So please: no rants about how awful DVDs are in the comments section. The goal of this part of the post is to explain what we fixed so that users who have seen a known bug can have better situational awareness.
X-Plane 10 “remembers” that you have inserted X-Plane DVD 1 recently, so that you do not need to have the DVD constantly in the drive to fly. Right now X-Plane needs to see DVD 1 (for each product you purchased) every seven days or so.
Every now and then we get a bug report from a user where the process of saving the DVD information fails; due to a bug in X-Plane 10.21 and earlier, when this process fails, the DVD would not enable scenery loading at all and the user interface would tell a global scenery user that a regional DVD was found. This was very confusing and also annoying (since it stops paying customers from using the product).
The bug in X-Plane is fixed in 10.22; furthermore if the preference-saving process fails we now put up a message for the user to contact tech support; previously it was a small item in Log.txt. If this preference-saving process fails, we want to know about it and fix it. (So far the only cases we’ve seen are Hackintoshes with hardware configuration issues and one case of a borked network preferences file.)
Water, Water Eveywhere
There is a separate bug in the copy protection system that I couldn’t fix for 10.22; we’ll revisit this issue for 10.30. The issue is this:
- When X-Plane needs to see your DVD to get out of demo mode, it tells you after you have started your flight.
- By that time you are on a runway that is all water.
- When you insert the DVD, does not reload scenery; you have to go to another airport and then come back to your original airport to “force” a scenery reload.
This behavior is confusing – X-Plane says “now you can fly anywhere in the world” but where’s your scenery? We get a fair number of tech support calls about this. The problem is that if we reload scenery when the DVD is inserted and your airplane is on the runway (in water-world) then once scenery is reloaded your aircraft is underground and your aircraft is destroyed. So a fair number of things need to change (e.g. when we check for the DVD, what we do when we find it) to fix this use case. That’s too much change for 10.22 and will have to wait for 10.30.
