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.
RT @XPlaneOfficial: Dev Blog Post: The Library: Public, Private and Deprecated http://t.co/IaQN3g8gCP #xplane
If we’ve used deprecated art assets in our submissions to Robin, will these submissions get rejected, and will the authors of the rejected submission be notified?
We haven’t decided. My guess is that over time, we will start to reject deprecated object use, but we’ll phase this in. We have not rejected any of the existing submissions based on deprecation or private library use, as authors would have no way to know this stuff.
For what it’s worth, private item use is a bigger problem than deprecated use. A lot of the deprecated paths show no OBJ at all in WED, and thus are unused but annoying in the hierarchy. By comparison, some of the private paths may have been used, and they do contain working art assets.
In the case of deprecation, IF a path is deprecated AND the art asset is in place, it’s likely there is a better replacement choice.
Please make sure we have a list in the “Global Airports” folder so we know which airport has been added with which .dsf. Thanks!
Looking forward to see the update.
I’ve done maybe 10 small regional airports around Australia and New Zealand. I’m going to upload a youtube video showing how I did a very simple one.
The changes you’re suggesting sound good. The library is confusing sometimes but at least it has the word filter.
Getting a proper workflow for submissions is good. If I want to update a submission can I just reemail it or is that going to be too taxing to manage?
My other primary concern is about using WED without an installation of X-Plane, ie on my laptop I want to put airports together, can I grab the airport data file for importing and then transfer the package back to my other PC when done?
Hi,
Right – one of the big motivations for private/deprecated is to clean the library. 1.3 will have even more filtering options, e.g. filter-to-only-default stuff, or filter to a specific scenery pack.
Resubmitting a pack is fine – we’re putting infrastructure in place to track that, and we got several ‘updates’ (where people sent revisions of their prior work) and it was no problem.
For a laptop, you can get by with a demo, but you unfortunately do need the library from X-Plane. If you really wanted to save disk space you could nuke the aircraft folder and demo terrain DSFs to save some disk space.
Hi Ben,
what about airports which have navaids that are not available in the default navdata? I’m implementing a small regional airport near my home, in north east of Italy. The real airport includes an NDB + DME radio aid, where in X-Plane only the NDB is already present. I simply added the missing DME via X-Plane tools. But what if I wanted to submit this airport for inclusion into the library? Should I send the customized navdata along with the airport package?
You need to submit the nav data to Robin by emailing a snippet of navaids to him directly. You can send him the navaids and the airport zip from WED in one email, but WED can’t auto-pack the navaids for you.
cheers
ben
Ben,
I am really happy that the community had taken on the challenge of developing airports for X-Plane 10. Now it is easy to say that X-Plane 10 is the peoples simulator. 😉
Over 200 right now is a great start, I am looking forward to them myself….
I have been building custom (small) GA airports for about 3 years. Initially, my objective was to learn to do the 3d building design and to develop a portfolio of objects that could be appropriately compared to your “lego” concept for populating GA airports in X-Plane. It soon became apparent that any such lego implementation would blossom into an ever increasing set of objects if they were to even partially fit the variations in buildings which are present on multiple airports and somehow even partially reflect the actual objects there.
The problem, as I see it, to make the generation successful, is to provide a means to scale the buildings provided in the leggo set in all directions, so that the base buildings provided (hangers, and simple block structures) can be made to duplicate the footprint of buildings seen from the air, and can be changed in their height. This requires the addition of such scaling be made available as a WED feature if that is at all feasible…and in addition, the invention of some means to invoke different colors and types of variations in the textures assigned to objects to provide further object customization. This then would require some special design of some of these basic library buildings for this purpose with the above capabilities in mind. It would provide the real means for approximating the layout of many of the airports you seek to populate and would make their “custom appearance” far more realistic.
As I see the present ( and probably incomplete) set of library objects, they are very restricted in their ability to recreate an actual ground layout because they have fixed sizes and textures.
Making a custom scenery layout of an airport’s objects has the primary requirement of custom size and shape recreation, and customized texturing. However the leggo concept could be very much improved in this direction if the above capabilities were implemented in WED and the accompanying object library of buildings.
Hi Bob,
I have _two_ comments on this.
First: a technology for buildings that scale in footprint and height exist already – facades. We have other technology in the autogen system that could be pressed into service as well someday.
Second: it is _not_ a goal of the lego brick library system and global airports to provide maximum accuracy for all world airports. It _is_ a goal to put plausible, reasonably typical buildings at reasonable locations.
So while we do think that we need more objects (for both better fits and repetition) and we do think that someday we may use facade technology for more kinds of buildings, if you are thinking now about getting exact color, texture, and fit matches for an entire airport, you may be thinking well beyond what we are trying to do.
The lego brick global airport system does not replace custom scenery or modeling the real-world buildings in a 3-d program.
Cheers
Ben