Monthly Archives: November 2008

Don’t Copy Stuff From The Library

Posted on by
Reply

Today I had to ask a scenery author to withdraw their scenery from the Download Manager at x-plane.org because he had copied a large number of objects out of the library into his scenery package.

This is a call to all authors:

Please download the Developer Pack from the home page and read the instructions inside it – you do not need to copy any files to be able to use OpenSceneryX.  If you do, you are breaking the license and infringing the copyright of the generous people who have contributed to the library.

This has happened on a few occasions, always due to innocent mistakes and usually just one or two objects.  It’s easily fixed but it’s better if it doesn’t happen at all.  Please read the documentation in the developer pack – it’s very easy to use the library properly.

Old Liveries

Posted on by
Reply

Airlines change their liveries from time to time, but why should this bother us?  As I mentioned in a previous post, some collections of aircraft are published to shared paths and some are not.  If an author uses a path that several aircraft are published to then X-Plane will pick a random aircraft each time the scenery is loaded.  For example, most b747-400s are published to /objects/aircraft/jets/heavy/b747-400.obj but some one-off liveries (Air Force One, for example) are not included in this, so you will never get a randomly placed Air Force One – the scenery designer has to explicitly choose to place that aircraft for it to appear.

One specific category of aircraft that is excluded from random placement are those aircraft that are in historical liveries. Historical liveries are present in the library because some authors may want to use them under specific circumstances, however when randomising we don’t really want old liveries appearing, as it would look strange in a modern airport.

So when does a livery become historical?  Well, you may say, surely it becomes historical when the airline starts painting a new one on its aircraft?  Well, I say, but what if no-one has contributed the new livery to the library yet?  Should all British Airways aircraft simply stop being placed randomly the moment BA change their colours, until some generous person contributes a new livery?

The answer is no.  The old livery remains active and current until a new one is submitted.  At that point the old livery is moved into a sub-path (e.g. /objects/aircraft/jets/heavy/b747-400/british_airways.obj would move to /objects/aircraft/jets/heavy/b747-400/british_airways/historical/1984-1997.obj and the new livery would replace the old aircraft).

Virtual Paths

Posted on by
Reply

If you’re a scenery developer, and you open up OverlayEditor and see the list of objects in OpenSceneryX, you are looking at a set of Virtual Paths to the objects.  These are not real paths on disk, they are made-up.  Hopefully I’ve done a reasonable job of making up these paths so that it is easy to find the object you are looking for.  Sometimes this goes a bit wrong and I have to change things around a bit, see the previous post for an explanation of how this is done.

Virtual paths give us three benefits:

  1. The folder structure on disk does not have to bear any resemblance to the path that an object is published to.
  2. An object can be published to more than one (indeed, many) paths.  However, it is still the same object and is only loaded once by X-Plane.
  3. Several different objects can be published to the same path.

Item 1 is good for library maintainers – We can organise the files however we like, as long as the published paths stay the same as time goes by it doesn’t matter where things sit on disk.

Item 2 is good for everyone – This allows objects to be found in different places, so they can be organised under different schemes and found by the user more easily.  A good example are the static aircraft in the library – These are organised both by aircraft type and by livery…  So if you are looking for a B747 then you can find it under /objects/aircraft/jets/heavy/b747-400/aer_lingus.obj but if you are looking for Aer Lingus aircraft you will find the same 747 here: /objects/aircraft/livery/aer_lingus/b747-400.obj.

Item 3 is also good for everyone – Publishing multiple objects to the same virtual path means X-Plane can introduce random variety as the sim will pick a random object each time the scenery is loaded.  A massive example of this is /objects/aircraft.obj – Almost every aircraft in the library is published to this path, so if you use it you will get a random aircraft each time – a bit extreme!  Perhaps more useful are paths like /objects/aircraft/jets/heavy.obj (a random heavy jet) or /objects/aircraft/jets/heavy/b747-400.obj (a random b747-400).  Note that some aircraft are excluded from this, specifically historical liveries, house colours and one-off liveries.

I’ll blog a bit more about historical liveries in future, as well as blogging about the build scripts that are used to compile the library.

Backward Compatibility

Posted on by
Reply
Metal Barrier
Metal Barrier

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.