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 |
Quick note: 10.21 beta 2 should be out today – that’ll fix crashes for Mac users.
WED 1.2 beta 2 — it’ll be at least a few days. I have the submit-to-Robin code working, but I still have a number of export bugs open.
Posted in News
by
Ben Supnik |
10.21 beta 1 is here – since this is the first beta of 10.21, you have to run the updater by hand and check “get betas” to see it.
This will be the only 10.21 beta, so please go try it now. Give it a quick once-over if you make custom scenery or a custom airplane. We’ve tried to put in a whole pile of low-risk bug fixes, but better to test than find out that something went wrong the hard way.
Release notes here, bug report form link is on the right.
One note about KATL: this update contains Tom’s KATL building layout, which is built entirely out of library components. It lives in the “Global Airports” custom scenery pack – this scenery pack will grow over time to contain all airports submitted to Robin’s global airport database.
Posted in News
by
Ben Supnik |
I have a lot to blog about this week, but before I can get into any of it, let me describe the process of recutting DSFs.
Alpilotx and I are now working on DSF recuts. The recuts will incorporate a few important changes:
- Bug fixes to the OSM import code. Some of the major cases of ‘missing water’ (e.g. Botany Bay) were due to a bug in the code that imports vector water day from OSM into our DSF generator. Once we fix this code, recut DSFs will get back water that sould have been there but was “lost on import.”
- Newer OSM data. The OSM data in the simulator now comes from approximately July of 2011. OSM is growing fast and being improved every day; for the recuts, we will take the latest data. If water was missing because it was not in the map in 2011, but that water is present now, recut tiles will get the new water.
- Airport boundaries from the latest airport file from Robin. Due to a last-minute data screw-up by me, many airports in the original DSFs were cut with very old airport data, and thus the airport boundary is wrong or missing. Even the airports that were cut with current data have the airport areas from November of 2011. Recut tiles will use the lastest (March 2013 when I last checked) data.
- Better land-class allocation. While the source land-class data that alpilotx prepared for me is very, very good, the resulting land class in the DSFs is sometimes inaccurate due to the limits of the algorithm I apply to it. I am working on improvements to that algorithm. The details of these changes are probably too technical for this blog, but the short of it is that I am trying to fix as many of the algorithmic problems that we’re not happy with as I can in the short amount of time I have been allocated.
A Tactical Recut
At this point you are asking the two most important questions: which tiles will you recut and how will you get them? The answer to both is: we are starting the process by recutting a small number of tiles that we think are most important to recut, and pushing them out over the network as part of the update process.
At this point we have enough bug data from users that we have a pretty good idea of which tiles need to be recut first. For example, trees on Chicago’s runway, Botany Bay not existing, and Edwards AFB containing a real (and not dry*) lake have all been reporting about 5,290 times each. So we will pick the first set of recut tiles ourselves to fix the most visible, highly reported bugs.
But the goal here is also to start an assembly line that can mostly run by itself. That is, once we get these bugs fixed, we can potentially recut a fixed number of DSF tiles every month and include them in an update, which will move us closer to having the scenery be “live” like the sim and not frozen for the entire version run.
I think moving to a live model for the base DSFs is an important step that we have to make. Back in X-Plane 6 when I first started flying X-Plane as a user, Austin sending out patches with a new version of the sim every month or two was viewed as crazy. Look at how far we’ve come: at this point application updates are built into the Apple app store on iPhone (and the Mac app store), and if you don’t push updates, users want to know if you’ve been hit by a bus. Updates are the norm.
That change is completely logical: back when I started working on commercial software (in the 20th century) distribution was by CD-ROMs, which were mostly sold in stores. Once your software went out, that was it, so “done” was “done”.
Now software is mostly distributed over the internet; with constant connectivity and increasing bandwidth, it would be crazy for a company to not respond to its customers needs and requests by issuing updates. One of the most important properties of software as a “building material” is its flexibility — if users want software to do something different, you can easily change that software. With widespread internet connectivity we have the matched distribution to go with the flexibility of the software itself.
This recut is not a global world-wide recut; I do not know when or even if this will happen. Instead the recut is a first step into keeping DSFs “current”, and the beginning of an on-going process.
The Next Train Leaves in 10 Minutes
The other question that I hear a lot (besides which DSFs and how will I get them) is “when do I need to finish my OSM/apt.dat mods to get them into the recut.”
My goal with incremental periodic recuts is to avoid this issue entirely. Once we recut a DSF, the cost of recutting it again is very low — we just hit “go” on the DSF generator and replace the files in the update.
In other words, don’t worry about when you “have” to get your updates in by. We will recut tiles, and if you make a useful change after the tile is recut, we’ll recut it again. Recuts should be like a train that leaves the station every 15 minutes, not once a week.
(With Robin republished the apt.dat on a regular basis again, apt.dat updates are already like this.)
Executive Summary
TL;DR? Here you go:
- We are recutting a few tiles at a time, not the whole world.
- Recut tiles will come as part of the automatic X-Plane update process.
- Tiles may be recut multiple times to gather new improvements, so don’t worry about “missing” an update when you improve source data.
- We are fixing import/programming problems in the first set of recuts.
- We have enough bug reports on tiles now, we don’t need more yet.
* I’m still not sure what happened at AFB, but my guess is that our importer saw “lake”, got very excited, and ignored the word “dry”.
I have a bunch of stuff to post about in detail, so let me first clear out the “what’s going on” category.
- I’m not actually going to law school, and we’re not canceling X-Plane to become a non-practicing entity. That was an April Fools Day joke.
- We’re working on the finishing touches to X-Plane 10.21, which will go into beta soon and have a short beta period. 10.21 is almost entirely bug fixes; I’ll write up more detailed notes on this later.
- I have a new semi-official beta of MeshTool 2.x that fixes bugs; if you use MeshTool and would like to test it, poke me. I have not had time to get a MeshTool 3.x (that creates v10 DSFs) working yet.
- I’m working on a new beta of WED, one that includes the “submit-to-Robin” work-flow for submitting airports built entirely out of library parts.
- Alpilotx and I are working on DSF recuts. I’ll post more details on this process in another post – there’s a lot to say about it.
That’s a rough picture of what’s going on – details to follow.
Posted in News
by
Ben Supnik |
