I posted WorldEditor 1.2 release candidate 4 a few days ago. If you are using a WED 1.2 beta, please grab this latest release candidate. If we don’t see any show-stopper bugs in a few days we’ll call it final.
Thanks to Mathias for finding and helping squash the last few bugs; the bugs in the release candidates have all been oddball cases where clicking with multiple mouse buttons induced multiple commands at the same time; the program was usable by avoiding these cases, but in the rare case WED could crash. Release candidate 4 should fix that.
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.
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.
give you information about the wings – in particular, they tell you the degrees of deflection of the flaps, elevators, etc. etc.
But what number do you use for N?
The answer is: you pick “N” depending on which airfoil you are animating!
In X-Plane, the horizontal and vertical stabilizers are “wings” too – we call anything that has an airfoil a wing. So you use this table to pick an N that matches what you are doing.
The moral of the story is: pick an array index that matches the part of the plane you are trying to animate!
Unusual Airplanes
I said “usually not good” above because there are airplanes with rudders on the wings (think of a flying wing) or V-tails where the tail is half-rudder, half-elevator. The rule still applies: use the index that you are animating! So if you have a rudder on your wing, then use index 0 (left wing 1) for the left wing, etc. The important thing is to pick an array index that matches the Plane-Maker part.
Why Is It Like This?
If you understand what was written above, you should probably stop reading now. And if you didn’t understand it, you should probably stop reading now.
Okay then. Why are the datarefs like this? The answer is that X-Plane is a completely flexible simulator: it lets you put any control surface on any flying surface. If you want to make an experimental design with elevators on the wings, X-Plane is not going to tell you that your idea is stupid. (I might tell you that the idea is stupid, but you can ignore me, because the only airplane I ever designed from scratch in Plane-Maker couldn’t take off without JATOs.)
In particular, because any flying surface can have any control surface, the datarefs are set up with array indices for all flying surfaces for all control surfaces.
But if your airplane does not have rudders on the wings, the value of those daterfs won’t be useful – they might be ‘correct’, they might be zero, they might be wrong. Don’t trust them! Use the correct array index for the correct wing and your plane will work correctly.
WorldEditor 1.2 Release Candidate 1 is now available here. Please try it! If you have a scenery project you use, please export using WED 1.2 rc1 and report a bug immediately if the export does not work! My thanks to the testers who have helped find the bugs in the 1.2 beta run.
If we don’t find any new show-stopping bugs, WED 1.2 will go final in a week or so.
Update: There is a bug in WED 1.2r1 on Windows that stops all art assets from being found in the library. I think this is responsible for all of the bugs reported against the RC. (This was from a change I made while my PC was down that I should have checked on Windows.) RC2 will fix these bugs.
Update 2: Release Candidate 2 is now uploaded; this fixes the one underlying bug that caused a lot of reports. The bug was that art asset location from the library was broken on Windows. This caused failed previews, facades that were rings and not fences, and red question mark objects. This is fixed in RC2.
I’m not sure what will go into the next WorldEditor release, but X-Plane 10 scenery usability features are on my short list.
The ability to create and edit X-Plane 10 road overlays.
Better options for managing overlay orthophotos for airports. (The current “make orthophotos” command is a stop-gap.)
Possibly the ability to create base meshes (by importing data – WED would then run MeshTool for you, so that you don’t have to write a script).
If your add-on uses LuaJIT (e.g. via SASL, Gizmo, FlyLua, or directly) then this tool may help. It’s a special build of X-Plane 10.21 for 64-bit Mac that can show total Lua memory use. Use DataRefEditor and filter on “lua” to see the numbers.
Since Lua uses garbage collection, you’ll see the number rise up and then “fall” periodically as garbage gets cleaned up. Non-Lua allocations by plugins are not counted.
If you use LuaJIT in your add-on (or a plugin that uses LuaJIT), please try to keep the amount of Lua memory used below 300 MB or so – more is available, but if you use it all, your plugin won’t inter-operate with other plugins.
That got your attention, eh? Sorry, this is not a tip on how to tune your X-Plane system; it’s a tip for aircraft authors to make sure their 3-d cockpits are running at maximum performance.
Prefill is when X-Plane blocks out the clouds that will be behind the airplane cockpit. The biggest cause of GPU slow-down is cloud rendering, so reducing the area that the clouds have to fill is really important.
In the 2-d cockpit, X-Plane pre-fills automatically. But in a 3-d cockpit, the airplane author has to specify which objects should be used to pre-fill.
Aircraft Authors: go watch this video or read this page to learn how to set up pre-fill in your aircraft! If you aircraft has a 3-d cockpit this optimization is very important!
The C: drive on my Windows box died over the weekend. I mention this so that you can ask this question now (when my drive failed) and not later (when your drive fails):
What’s your plan if you have a hard drive failure? Do you back up regularly? Could you rebuild the machine from original install disks? Would the amount of time it took to restore the machine be acceptable?* If you make backups, would the data loss between what you had and the latest backup be acceptable?
The problem with hard drives is that they fail infrequently; my wife has never experienced a hard drive failure in the decade+ that she’s owned a laptop. The result is that I’ve known too many people who haven’t given the problem of hard drive failure much thought until they had already lost data. A hard drive is an electro-mechanical device…with moving parts…that spin really really fast. It’s amazing they don’t fail more. Think about backups now!
For backup these days I like 2.5″ USB drives – they’re fast enough, small, store a ton of data, and they don’t require an annoying power cable. You could use one to back up several computers.
Nag over…WED 1.2 is almost done – the remaining bugs are Windows-related and will need to wait for a replacement C: drive, which is in transit. So perhaps we’ll get an RC1 going this weekend.
Update: when the replacement drive arrived, I used Trinity Rescue Kit to boot from CD and do a drive-to-drive copy using the tool ddrescue. I do not recommend anyone ever have “I’ll rescue my drive” as a data safety plan – it’s a terrible plan. But…in my case I appear to have gotten lucky; the rescued image is bootable. This is a nice-to-have in that it saves me a few hours of reinstalling Windows + MSVC from scratch. (On the other hand, I don’t get that minty-clean feeling of reinstalling Windows from scratch with a clean registry.) So…chkdisk is running now and I should be able to kill off remaining WED bugs “real soon now.”
* For my Windows and Linux setups (two drives that are alternately used in one machine) my approach has been “rebuild it when it fails”. For Linux this has already worked well – my Linux drive died a while ago and a total rebuild from a new Ubuntu install DVD was quite fast. We’ll see this week whether putting a Windows box back together can be done in a reasonable amount of time.
I’ve just uploaded some new videos to the official X-Plane YouTube video channel. These videos are screencast tutorials for airport authors to help them understand the ATC Airport Flow feature in X-Plane v10.
ATC Airport Flows are essentially a set of rules that control how the runways are used for airport operations. An airport like Chicago’s O’Hare (KORD) for example has 7 runways (14 different takeoff/landing directions)! ATC does not simply put aircraft wherever they feel like in the moment or there’d be a massive aluminum traffic jam. They have a set of rules that control which runway(s) are in active and inactive at any given time. These rules are typically based on two main criteria: weather conditions and time of day.
In the real world, at major airports, traffic studies are done to decide which runway combinations are most efficient for traffic flow, safety and workload and those combinations of runways become active when the conditions are just right.
Once the controller deems certain runways active/inactive for the current conditions, there are yet more rules to determine which types of aircraft use each of those runways. For example, if a small Pilatus is flying into KORD, I strongly doubt they’re going to block up their major runways for arrivals for a small single engine turbo prop. They’re likely to put him on a smaller accessory runway. Also consider some airports which only use certain runways for arrivals while other runways are only used for departures. This is often done for noise abatement or obstacle avoidance. These types of rules can be included in the ATC Airport Flow.
Our goal was to give authors enough granularity to closely mimic the way real airports are run so that when X-Plane’s ATC is in action, it’s towers can make similar decisions to the real controllers.
WorldEditor: WED 1.2 beta 3 is now out – see the WorldEditor page for download links. Beta 3 fixes the broken orthophoto exporter from beta 2, fixes jammed file-open dialog boxes on OS X, and has a handful of other fixes.
WorldEditor is open source, so you can see the exact changes made here.
I am hoping that WED 1.2 beta 3 will be totally stable and usable; the remaining open bugs are mostly UI quirks. If we find more work-stopping WED bugs, I’ll try to cut a new beta once a week until they’re fixed; after that WED can sit for a few weeks, then go final.
MeshTool: MeshTool 2.1 is released. This is an incremental update to MeshTool 2.0 with bug fixes and a new “contour” option that lets you use a shapefile to force specific contour lines into your DSF. See the README for details, and the MeshTool page for download.
I have done some work on MeshTool 3.0 but it’s not ready for beta yet.
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.
