Home | News | Backward Compatibility

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.