A naive answer that doesn’t involve X-Plane tech would be:
– Authors list their dependent libraries in their scenery pack’s install instructions.
– Users look at that list when they install the scenery pack.
– Users can look in the library to see it’s version and get new ones.

That’s a lot of manual steps though. 🙁 The only thing my proposal will do is make the error message spell out that you should have done those things by hand. 🙁

I think we -have- to list all missing libraries on the first problem. Since we don’t know which art asset is from which library (an art asset might be from more than one) all we can do is collect all of the libraries in x-plane now, the dependencies registered with this scenery pack, and show the “missing” diff.

My 2cents, display all missing libraries and then reject. As an end user I’ll highly appreciate it, since I won’t need to encounter the same error for the one I was not aware off.

Keep up the great work.
Saar

I was thinking about a “third-party-installer” myself, with dependencies and everything. It would certainly help!

Re: version, not sure… I usually like static names not changing at all for better identification.
Re: link: Could work. Point to LR, and then from LR point to the correct site. (kinda like a database – but let users “update” it?) I think the average user needs more help than “OpenSceneryX not found”

Well, it _sort of_ solves the problem. 🙂

It converts the penalty for not having libraries from “I can’t run” to “I don’t see any 3-d stuff.”

The user -still- isn’t seeing the scenery pack -the way it was meant to be seen-. In fact, you could (perversely) argue that running with place-holders is worse: the user doesn’t realize he or she is missing a library, and just goes “that scenery is not very good.”

Cheers
Ben

The spec has the version number separate from the library so that we can identify the case where “we have this thing, but it’s not new enough”. This is necessary because otherwise:
– Each library has to introduce a new dependency name when it introduces new art assets.
– My library 3.0 thus has _3 names_.
– Thus when you use my library you pick up 3 dependencies.
– Thus when you run your pack without my library, you are missing “three things”: Ben’s lib 1.0, Ben’s lib 2.0, Ben’s lib 3.0.

And a user goes “oh noes, I can only find Ben’s lib 3.0 on the net, where do I get the old ones?”

By having the version separate, we can have a ‘greater than’ policy, and thus only Ben’s Lib 3.0 is written in.

I think serving people’s third party content definitely goes way beyond this proposal!

It does beg a question, however, whether in the long term that is a better solution…there aren’t -that many- common third party libraries; if X-plane could install them, it could resolve the situation. That’s a big jump though; right now X-Plane never installs third party content.

Re: version number, I think the version number in the RFC is implicitly a minimum; if a library wants to make a ‘breaking’ change it needs to pick a new “dependency name”.
Re: link, I’ll think about that. If the library’s hosting moves, the URL might become counter-productive – an alternative is to have the error message go to a LR support web page that explains (in detail) how to find a library and common places to look.