When we first re-coded the scenery engine for v8, my experience with ENV packs (also forgiving) was the same as what Jonathan saw with MSFS: you’d be shocked how many ENV-based packs were missing some or all of their OBJs, either by being in the wrong place in the pack or just not being there at all.

My being a hard-ass on this isn’t just to be a jerk — it’s to fix a real problem that was clearly happening in the previous-gen scenery format!

One other note: these problems (missing art assets) can very easily be tested by the authors with 100% reproducibility in a single load of the sim. If this was an intermittent bug I’d say it needed to be less fatal. But if you ship with missing art assets, it means you didn’t load your pack _even once_.

Suggest you look at OpenSceneryX’s “Placeholder” library in their developer pack.

I’m with Ben on being unforgiving:- MSFS was extremely forgiving about missing libraries etc and didn’t even warn the user or the scenery package developer. As a result, you would not believe the amount of badly-formed MSFS scenery packages out there, including malformed references to library objects, misspelt references to library objects etc.

I don’t think there’s a magic solution to this problem. But my X-Publish tool warns the author if they’re using library objects without a backup library.txt. WED could do the same on export.

I believe that that listing is correct. As far as I can tell, no new library.txt features have been added post 860. But I will check more thoroughly later. the stuff listed there _does_ work – nothing’s been dropped.

I may be guilty of this too. So I’m researching just how to add the export_backup command to my library file.

I have one question just to make sure I’m doing things right.

The most current library file format specs I can find are dated from 2006. Is this still the most current version?

http://wiki.x-plane.com/Library_File_Format_Specification

That’s a good question. If packs are tagged wrong, the error message is unhelpful some of the time.

On the other hand, right now the error message is helpful _none_ of the time, so it’d be hard to do worse, even with unreliable data. 🙂 🙂

Yeah I agree – we need new tagging and directives to make a good user experience.

Fortunately the number of _sources_ of lib paths is pretty small, so getting a few key libraries (e.g. OSX, etc.) tagged would go a logn way.

Seems,this can only be done by the author .

For WED ,the known things are the lib/name and the dir-path on the build-machine.
Only the author knows about the install-instruction and a download-URL.
Unfortunately , no automatism possible.

I believe a perfect solution is not possible: (a) assets are only known by a path which is not required to indicate the providing pack, (b) Laminar does not have control over the scenery development workflow as the file formats and semantics are public.

If either (a) or (b) were false, then a solution to your request is straight forward.

The providing pack is only sometimes knowable. Laminar has only partial control of development via WED.

I think the best you can do is educate developers (including, perhaps, indirectly punishing them through their users, but you may take collateral damage). In the tools you provide give all help to alert developers of a potential problem.

I don’t think that collecting and embedding package information at development time helps. You do not have control over the quality of this info, even in WED. Presenting misleading info to the user comes with risks. Do you want to take the risk?

Kind regards,
Ropeless

I don’t think I’m going to convince you, but here’s why I don’t buy it:

There are two kinds of packs:
1. Packs that use export_backup. When these packs are bug free, they will NEVER fail the library, and there is no variation based on the deployment system. So any error exposed to the user is one the author could and should have fixed up front.
2. Packs that do not use export_backup. They should start using export_backup (or some other mechanism that is subject to this discussion.)

In other words, the users shouldn’t see this error because the authors shouldn’t be exposing them to dependencies.