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 |
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.
The last few weeks have felt like a bit of a Nine Inch Nails song (more or less) – in my weekly status report it’s “finish X-Plane 10.21, get WED 1.2 out.” Another week, another few bugs fixed. Are we there yet?
First WED: 1.2 release candidate 3 (!) is now posted. You can see a list of changes here. Two changes may be of interest:
- On Windows, the control key can now be used to apply changes to every selected item in the selection-property editor. In other words, select a bunch of nodes, control-select them all to a certain edge type, they all change at once. (This has always been possible with the option or alt key on Mac/Linux, but the alt key pops focus to the menu bar on Windows.)
- Keyboard commands are now delayed until after the mouse button is released. A user discovered a case where WED could be crashed by running two commands at the same time by drag selecting and picking control-G (for group) at the same time. WED now always defers keyboard-to-after-mouse. This is a risky change, but I want to make sure we kill off all of these bugs; WED’s undo system requires that no two edits happen at the same time to avoid corrupting the document.
Anyway, please report bugs on the scenery tools bug base.
Second: we’re looking at shipping a Lua memory allocator for Windows in a bug fix release to X-Plane 10.21, rather than waiting for X-Plane 10.30.
If you haven’t been following along at home on this, the short version is:
- SASL, Gizmo, FlyLua, and other plugins use LuaJIT.
- 64-bit LuaJIT has special needs when it comes to memory allocation.
- On Mac, X-Plane provides a special allocator to plugins to keep LuaJIT fed and happy.
Originally we planned to provide allocators on Linux and Windows in 10.30, but our new thinking is that we don’t want to wait that long; we have some things for 10.30 that may require a full-length beta (e.g. at least four weeks) so rather than wait for a summer patch, we’re investigating whether we can ship Lua allocation now.
Posted in News
by
Ben Supnik |
But if you run 10.20, you probably already know that from the auto-update.
I’m hoping to have a beta 3 of WED this weekend with a fix to the orthophoto exporter and the 10.8.3 file-dialog box problems if we can figure them out.
Posted in News
by
Ben Supnik |
X-Plane 10.21 rc2 is out; this recut of the release candidate backs out most of my changes to the lights; in hindsight my change was too ambitious/crazy at way too late of a point in the release process. The runway lights will still look better in 4x SSAA, but (like X-Plane 10.20/10.11) they will look dimmer if your monitor is bigger.
We’ll do something more involved with the lights for 10.30 when we have time for a proper beta test, and when Alex is around to look at my changes and tell me I’m an idiot.
Update: We are going to release a new release candidate (10.21 rc2) tonight that puts the light sizing back to normal, while still fixing the SSAA bug. This will have two effects:
- Runway lights won’t be as bright as in the RC. Sorry guys, we will get this fixed, but clearly it’s not something that I should try to change by jamming a code change in at the last minute.
- Airplane lights will look the same as they do in 10.20 and 10.11.
The rest of the original post follows…
I jammed a change into X-Plane 10.21 rc1 that maybe wasn’t such a great idea: in X-Plane 10.21 the light billboards get bigger when your screen resolution gets bigger.
The idea behind this change is that the percentage of lit pixels in the night scene should not get smaller when you go to a bigger monitor – if they do, then the night scene looks dark. In X-Plane 10.20 (and 10.10 and 10.05!) the billboard sizes are fixed in pixels – in a bigger monitor they tend to be tiny little dots, potentially harder to see.
This change makes a mess of aircraft lighting, and almost certainly needs to be changed (again) for an RC2. But the choices aren’t good.
- If we keep the old behavior (light size is constant in pixels) then authors have a lousy choice: make the lights too big in a small window or too small in a big window. There’s no way to get your billboards to look good on a laptop and a 1440p monitor. This is what authors have been living with, and it’s lousy. If you make a plane, you know that your lights only look right if the user has the same screen resolution as you – something you just should not assume.
- If we take the new behavior, what size should the lights be? We have to pick a screen size to use as “official” from 10.20. In rc1, I picked 1024 x 768 – that is, the smallest resolution we support. This choice makes the runway lights look good, but virtually all airplanes are going to have lights that look too huge.
So I am considering one of the following choices:
- Match the 10.21 lights to 1020 at 1080p (or some other intermediate resolution), in the hope that most airplanes will look good on average.
- Revert the change entirely (and keep only the fix for 4x SSAA) and solve this in 10.30. This isn’t good because (per above) authors are again stuck with the airplane only looking good at one resolution. But at least in 10.30 we could do something more clever (e.g. different behaviors for old and new airplanes or who-knows-what-else). Alex is still out of the country, so the thought of punting this until he can look at the results of some of the choices is tempting.
- Apply mixed behavior (e.g. different math for scenery vs. airplanes). With anything “clever” like this, we risk the equations getting complicated, with too much fine print for authoring.
Anyway, I think it’s 95% likely we’ll cut an RC2; I’ll post something when we pick a strategy.
If you haven’t participated in the 10.21 betas, run the updater and click “get betas” to get it. Release notes here; report bugs here.
If you have a custom scenery pack, please try it on this RC! There have been a few changes to the facade engine to fix cases that were clearly broken in 10.20; please check your scenery to make sure these changes didn’t cause some other problem that I didn’t see in my testing.
First, 10.21 beta 2 is out – but if you had beta 1, you know that because the sim automatically tells beta testers about newer betas. Release notes here.
The big fix is a fix to crashing on OS X that was affecting the CRJ, other plugins, and anyone who tried to resize the sim’s window. The bug was introduced in an attempt to fix the not-working command key (which in turn broke when we rewrote the UI code for 64-bit). Hopefully we now can have 64-bits, a command key, and a resizing window all at once.
Performance Issues, or Lack Thereof
I have seen several bug reports reporting framerate loss in 10.21, and AlpilotX says he saw the same thing on forums. There is only one known cause of framerate change (and it could be an increase or a decrease): the autogen art mappings were changed in 10.21b1 to use smaller buildings for rural residential areas. With different autogen, we can have different fps.
Fortunately, X-Plane 10.20 and 10.21 can have the application interchanged with the resources of the other version, which makes it possible to test whether a performance problem was introduced via the autogen change or the sim itself.
What I found first is that there is no change in the performance of the sim’s engine from 10.20r3 to 10.21b1 to 10.21b2. Framerates between them were within the 2-3% random variance that you can get with the framerate test, and the pattern was random, not directional (e.g. sometimes 10.21 was faster, sometimes it was slower, indicating that the difference is random noise, not data).
The second thing I found was that there was no meaningful performance loss from the autogen – I saw perhaps a 1% fps loss, which is well within our error margins (or at least, nothing like the “sim is unusable now” reports I received).
Now that doesn’t mean that there isn’t a problem – just that my particular measurements don’t see it. So…
Please do not report new bugs going “but I see a fps loss on my machine”. That doesn’t do me any good.
Instead, let me give you some links: 10.20r3, 10.21b1, 10.21b2. If you see a fps loss, use these links to get the old apps. Use the updater to go down to 10.20 (for old autogen) or up to 10.21b2 (for new autogen), then try all three apps on the same X-Plane!
If you can find a framerate loss in this case, then investigate and report it with rendering settings and a reproducible case (e.g. sit on runway 36L at KSEA, etc.). Try to remove third party add-ons if possible because they make it difficult or impossible for me to reproduce your conditions.
Posted in News
by
Ben Supnik |
