There is one particular library problem I see all of the time:
- Scenery pack A exports a pile of art assets to the library.
- Scenery pack B uses them.
- User X installs scenery pack B but not A, and can’t run X-Plane.
X-Plane provides a way to work around this: a library pack can contain an EXPORT_BACKUP directive that tells X-Plane “use this art asset if you can’t find it anywhere else” – it’s for place-holder art of last resort.
So scenery pack Bcould contain a library.txt with the backup art to allow it to function (badly) without scenery pack A.
But, even though OpenSceneryX provides this “backup” library, I see over and over again scenery packs with no backup, and confused users who don’t understand why their sim doesn’t work.
I am open to ideas on how to fix this.* One idea I had (which may or may not be useful): allow scenery pack B to list in its library.txt the scenery packs it requires by some human-readable name.
Then if/when X-Plane can’t find library files, it can provide a useful message like:
The scenery pack “Awesome Downtown NY” could not be loaded because you have not installed the scenery pack “OpenSceneryX.” Download and install “OpenSceneryX”, then restart X-Plane.
But I am skeptical: given the low adoption rate of EXPORT_BACKUP I am not sure that authors of scenery are paying a lot of attention to library dependencies.
* But not this idea: just load the pack without art assets. I strongly believe that if X-Plane allows broken data to load, the amount of broken data in the scenery packs out there will go way up. We have seen this happen over and over again; the quality of third party data is proportional to the severity of error checking.
Errr Ahhh, that’s not me, ahh err, that’s Mr. Tinkers fault.
Yea, that’s it, BAD! Mr Tinker. He will be punished.
But while we’re on the subject.
Are you saying that while working in WED1.2b one must be careful where one pulls art assets from?
Especially if one is working on scenery packs of close, adjacent urban areas?
Say 1) LaGuardia 2) College Point 3) Manhattan?
Since WED is the tool used to place art assets and only sees what’s in the XP custom scenery folder, is it possible WED could provide some sort of warning?
Exactly — if you have third party packs that export library art assets and you use them, you now depend on those libraries. There are a few things we could do:
– Code WED to filter out third party library art assets as an option – in case you aren’t trying to grab other people’s art assets or
– Code WED to copy the info about where it found the library art assets and then write it into your library file. The library.txt file would need a few new features to make this work.
Generally intentional third party libraries like OSX use clear paths like /lib/opensceneryx/ to prefix their object names.
Doing this automatically by WED is a good thing, does no harm, and at least WED pays attention to the lib-deps.
I’m sure OE does not take long to follow and
this is easier to use for the authors as the placeholders .
At first I was afraid we could lose a bit of flexibility of the lib-system.
As a example : No dependency on the pack-name.
We can rename,replace the lib-pack and the objects can be still found from a older DSF, as long as the lib/path/name is valid.
However , there could be strong deps ( version , name or something else ).
My first thought was :The info could also be stored as a parameter in the DSF.
But if it is in the library-file, the flexibility remains .
I think the declared name for dependencies would really be targeted at producing good error messages, not ‘enforcing’ anything. That is, if all lib paths resolve (the good case) there’s no need for x-plane to fail the scenery pack for some other reason.
Since the goal is good error reporting, what we need isn’t really a pack name, but rather a pack “description”, maybe with a URL – something that would let the user understand where to go to _get_ the missing pack.
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.
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.
I’m for benignly Not Loading an unfound asset because the user who didn’t create the scenery does not deserve an interruption. Go to town on the scenery creation tool, on the other hand. If WED were to create the library.txt file automatically then all the better.
If an irritatingly high level of nag is desired in X-Plane itself then a warning that dismisses itself after 5-seconds is good enough.
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.
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?
//wiki.x-plane.com/Library_File_Format_Specification
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.
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.
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_.
Hi Ben,
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
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. 🙂 🙂