Selection of items
When selecting any item in the map pane, WED now prioritizes the items by a what appears to be on top when viewing the scenery in X-plane. So if you click on any .OBJ in the middle of a taxiway – it always selects the .OBJ, line marking or ground painted taxi sign rather than the underlying taxiway. Similarly, it selects the facade or forest rather than anything that is flat and draped on the ground.
Technically, this means object type and LAYER_GROUP rather than WED hierachy based prioritization.
Exclusion zones and airport boundaries are now kindof “hollow” items, they can no more be selected by clicking inside of them, but only by their frame/outline or perimeter. That should greatly help with not having to lock or otherwise get those large area items out of the way.
All items can now be single-click selected, even if they are located within the area of an already select item. This eliminates the need to de-select (CTRL-D) e.g. a taxiway every time the last attempt to click select a .OBJ turned out to be just a bit to far away. And therefore accidentially selected the whole taxiway underneath it instead.
Drag-moves are now subject to some “stickyness” , i.e. the move/copy only starts after the drag exceeds a few pixels. This helps avoiding accidential very short distance drag-moves. Once the item has “broken free”, the item can be moved back to within a single pixel of the initial location, so small moves can still be achieved.
Several bugs that prevented adding bezier handles to nodes under some conditions or selecting very closely spaced items are fixed as well. All operations now require a click no closer than 4 pixels from the “correct” location. Any very closely located items having the same piority (like two nodes of the same polygon) are now selected using a “whatever is closest” strategy, rather than having overlapping bounding boxes prevent access to all but one of them.
Validation warnings and results browser
Some validation issues can now be a warning only, rather than a hard error. This allows WED to try more validation of frequently found problems, even at the risk of creating a few false alarms in rare cases. If such a warning is ignored for gateway submissions, the gateway moderator will determine on a case-by-case base if the issue can in fact be waived or still reject the scenery submission.
After validation, a full list of ALL validation issues will pop up, allowing to browse and zoom to / highlight all issues to help planning out the work required to pass validation. This also allows to select multiple validation errors to e.g. select ALL duplicate vertices in ALL polygons – allowing to fix all with a single editing operation.
Validation now catches all types of self-intersecting polygons. Previously there were certain cases of bezier-curves that caused taxiways/polygons to stop showing up at certain zoom levels or not at all in X-plane, despite they looked fine in WED or vice versa.
The coordinates and names of runways need to be exactly in sync with the CIFP data used by X-plane for FMC SID/STAR and GPS approaches. For this reason, gateway airports are occasionally edited by a script by “WEDbot” to achieve this, but any user re-submission that touches the airport may break this effort. WED now validates the runways against CIFP data oit obtains direct from the gateway server and requires the runway threshold to be within 10m of the exact location. Note this is the thereshold – the wide white bar only.
There is a separate warning only if the displaced part of the runway (the optional part from the end of the runway to the threshold – with the centerline arrows pointing towards the displaced threshold) mismatches official documentation. Some of the CIFP data mis-states that displaced distance, so it is a warning only. Please thoroughly verify such warnings against current orthoimagery and draw as per current real world markings.
A *lot* of ATC flows on the scenery gateway are non-functional because of misunderstandings how flows work. The most common mistake is to define one flow per runway and then expect that X-plane somehow finds all flows that fit the current weather pattern and uses them all togther. But that’s not how flows work. Validations will now try to find such duplicate condition flows (that are effectively never ever used) and will warn about it.
The airport naming is covered by several new errors (like ALL CAPTIALS – THATS SHOUTING IN THE INTERNET AGE !) and warnings if undesired elements are included in the names.
Smart runway rename
When a runway is re-named due to magnetic variation changes, not only the runway name, but also all ATC taxiroutes, flows and taxisigns need to be fixed up to reflect the changed designation. WED now will detect such edits of a runway “name” property, find all these references, update them and let you know. This greatly helps when the runway validation tells you it’s missing some runway at that airport – which usually means some existing runway was recently renamed due to magnetic variation changes.
More library item previews
Type 1 facades are now displayed in the library preview panel. Please be patient – the more complex “type 2” facades as used in all airport terminals and the new terminal kit are not showing, yet.
Many library items come with multiple variants that X-plane will select at random from when placed in the scenery. For such items, a button will show up to view each variant. But keep in mind – there is no way to tell X-plane to always use a specific one. Its just a true “FYI”, only …
All forest/facade/object previews will show some textual information about their size and features available.
The World Map in the background now has 9x the resolution and shows true X-plane ground texture colors.
ATC taxi route names are displayed in the ATC TAxi & Flow view – please verify them for consistency, as the X-plane ATC uses and even speaks these names when providing taxi instructions.
Don’t import from the apt.dat for gateway airports
The apt.dat and .dsf formats are lossy, i.e. they contain less information and use less precision than a direct import of the airport from the scenery gateway. WED will now warn anytime it detects such an import for an gateway type airport.
Upon im/exporting to/from the gateway WED will now also show warnings if the gateway is currently not accepting new submissions for that particular airport.
Facades without roof’s or filled areas, like fences and skylights in the XP11.10 terminal-kit are now allowed to have 2 nodes only – previously facades of any type had to have 3 nodes minimum.
Two bugs were fixed, too – these prevented selecting certain wall types in the terminal-kit facades and displayed some facades as being “closed rings”, rather than line-type items in the map window.
Georeferenced image “geotiff” import used to require mercator projected, WGS84 referenced coordinates. On Linux and OSX it will now understand pretty much all coordinate systems defined in the EPSG standards – although WGS 84 lat/lon coordinates are still the preferred encoding.
Display speed and memory use
When zooming in at airports with very large, single piece taxiways, the WED display speed used to slow down significantly.
The 64-bit versions of WED (OSX & Linux. Windows is still 32 bits, only) used a lot of RAM with large sceneries, e.g. im/exporting the *whole* global airport scenery (thats what WED is used for at LR, all 28,000 airports in one scenery !) maxed out a 16GB RAM machine. Now its down to near half that and everybody else gets a small speed boost, too.
Some user adjustable settings (like meter vs feet) are now moved to the File->Preferences (OSX: WED->Preferences) menu, stored in WED’s global preferences and no more loaded/stored with each individual scenery file.
We made it people!
This release encompasses all of the beta. You can read through the beta notes for more details, but, here are the highlights:
We could not have gotten this far without the incredible support of our beta testers, new authors, bug reporters, and all the wonderful artists who give us the inspiration and energy to make this product better! It has been an incredible journey diving into this facet of the community and I look forward to even more releases, including VR manipulators, full WYSIWYG lights, and more!