Some of you may be aware of the excellent Backup Library that chris k originally built and now einstein maintains over at the .org. Having this library installed removes a lot of errors you get in X-Plane if you use a scenery package that needs a library, but haven’t got the library installed.
It basically supplies fake invisible objects, lines, polygons etc. that are used instead of the real ones, so that X-Plane has something to load rather than complain about.
After some discussions with einstein, we have decided to join forces so that OpenSceneryX automatically installs the Backup Library too. This means that you won’t need to download and install it separately if you have OpenSceneryX installed. The installer will also give you a choice whether to show visible or invisible placeholders for the Backup Library, so that you can choose to know whether you’ve got libraries missing or not. The visible ones will be bright red, so easy to spot!
Note that einstein will still be maintaining the Backup Library and the full version will still be available from the .org but it will be slightly different as the full version still needs to include a backup for OpenSceneryX itself in case you don’t want to install it.
This feature will be included in the next version of the library and installer.
Several users have raised an issue with the Steam version of X-Plane on the Mac. Because the default Steam install location is inside your ‘Library’ folder, and this folder is invisible, you cannot select anything below it in the OpenSceneryX installer.
To solve this, the next version of the installer will have a ‘Use Steam’ button on the Mac – this will automatically check whether the X-Plane Steam folder exists and if so, sets it to be used by the installer.
This work is done, but there is another feature being worked on at the moment (watch for the next blog post!), so a beta version will be released at some point once both new features are ready for testing.
It turns out that the problem people are seeing with the OpenSceneryX installer is due to the security features in Vista (specifically, User Access Control or UAC). This means that a program cannot, by default, create files and folders in areas of your hard disk that Vista thinks it shouldn’t, which can include the “Custom Scenery” folder inside your X-Plane folder. Unfortunately, this causes something of a problem for a program that is meant to install files and folders in there, such as the OpenSceneryX installer.
While I work on a fix for this, my suggestion to all Vista users is to run the installer by right-clicking it and choosing “Run as administrator”. This gives it elevated privileges that means it can write to your X-Plane folder.
Ok, so here’s the problem: When an object is first contributed a decision is made to publish it to a particular path (e.g. /objects/furniture/barriers/portable), the library is built and the object is published to everyone in the next release. Time passes and the library grows and authors start using the object…..
…after a while and a few more releases it becomes obvious that the original path the object was published to is not really very good… usually because a bunch of other objects get contributed and a better way of organising them springs to mind. A decision is made to move the object (e.g. to /objects/furniture/barriers/metal/1). The problem is that older scenery packages that reference the object at the previous path would break because they can no longer find it. To solve this, we have the concept of deprecated paths in the library – take a look at the docs for the above object – it shows that the object used to be published at one path, but from version 1.8.5 it is also published to another.
This makes newer versions of the library backward compatible with older ones and hopefully means that scenery package builders can always rely on their packages working with future releases of OpenSceneryX.
Um… That is until the library maintainer makes a mistake and forgets to add in a deprecated path when an object has moved, which happened recently with /objects/airport/vehicles/stairs which moved to /objects/airport/vehicles/stairs/1. Because there are so many objects in the library now, it is unlikely that I will spot these on my own, so if you discover a problem like this, please let me know straight away and I will fix it in the next release. Backward compatibility is a very important goal and errors like this must be fixed immediately.
I’ll blog again shortly with more technical detail on how X-Plane allows us to do all this.