The post Thank you Cloudflare appeared first on OpenSceneryX.

1. The Mac installer now provides support for the default Steam location.  A new button allows you to select the Steam folder if it exists.
2. The installer now includes the Backup Library that chris k originally built and einstein continues to expand and maintain.  This means that if you have OpenSceneryX installed, you no longer need the Backup Library.  The installer allows you to choose whether the placeholders used are visible or invisible – the visible ones should be bright red.
3. The installer has been rebuilt using the latest version of the Xojo development environment. This means that the Mac version is now a full Cocoa application.

We need some testers to try out this beta and test the new features, as well as ensuring that no bugs have crept in.  Although the third item above sounds innocuous, a lot of things have changed under the covers so it needs a good test.

WARNING: If you are not happy testing betas, which may have bugs, please skip this and wait for the full release version.

However, if you would like to help out, please either reply to this post (you’ll need to register as a user of the site if you haven’t already) or simply get in touch using the contact form.

The post Beta Release of Installer and Library appeared first on OpenSceneryX.

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.

The post Vista vs The Installer appeared first on OpenSceneryX.

This post will cover the final part of this process – How the library is released for download.

Stage 10a: Final Pre-release Jobs

The “Enhanced by OpenSceneryX” logo is re-made with the new version number and the release notes are completed. A sitemap for the new website is generated using Google’s own sitemap_gen Python script.

Stage 10b: The Manifest

The manifest serves an important process, described here.  The next job when releasing the library is to create it, and this is done automatically.

Stage 10c: Compression

The installer needs every file to be available, individually zipped.  So to prepare for this, a script is run across the library which zips each file.  Additionally, the entire library is zipped into a single archive for those users who have trouble with the installer. Finally, the new version of the website is compressed for ease of upload.

Stage 10d: Upload

All the compressed files are now uploaded to the web server, into a temporary location.  In total the upload is about 0.5Gb, so it takes a while and the old version of the site is still served up to users during this process, to minimise downtime.

Stage 10e: Uncompression

All the files that were compressed for upload are now uncompressed on the server, still in a temporary location.

Stage 10f: Making it Live

To make it live, the home page of the site is replaced with a “Site temporarily unavailable” version, all the current files and folders are moved to a backup location and the new versions are moved to the live locations. Once this is done, the new home page is deployed and the release is complete.

Stage 11: Announcements

Finally, various announcements are made in forums and messageboards, letting people know that a new version has been released.

The post How the Library is Built – Part 3 appeared first on OpenSceneryX.

This post will cover the process of building and testing the library while it is still under development.

Stage 7: Build

As contributions are added over a period of (usually) a month or two, development versions of the library are regularly built so that it can be tested and problems fixed. The build script that compiles each library release does a lot more than just copying files into a folder structure, I’ll blog about the details of this another time, but several options are available for publishing an object to multiple paths.  The build script simultaneously creates all the documentation for the library and also the developer pack, both of which will eventually be uploaded to the website.

Stage 8: Test

After a batch of objects have been added, the built library is copied into a local X-Plane Custom Scenery folder.  Then I’ll add the new objects to a test scenery package using OverlayEditor, kick off X-Plane and see what they look like.

Stage 9: Revise

If any objects look odd then they are loaded up into Blender and modified and we return to stage 7 again.

Stages 7 to 9 are repeated many times as contributions come in, until there are enough to justify a new release.

Stage 10: Release

Finally, once a decent number of objects have been added, a decision is made to release the new version into the wild.  The release process involves doing a series of things, the details of which will be in the final episode…

The post How the Library is Built – Part 2 appeared first on OpenSceneryX.

This post will cover the first part of this process – The initial contribution of the object.

Stage 1: Arrival

The object (or much more often, collection of objects) arrives as a zip file.  The contents of this zip can vary hugely – some contributors send in stuff that is almost release-ready, i.e. every object in a separate folder, every object with a screen-shot, even sometimes with an info file. Sometimes it’s just a collection of objects and textures in a single folder.  Whatever it contains, every object is examined, doing the next stages. Obviously the time taken by the whole process varies depending on how much work the contributor has already done.

Stage 2: Quality Assurance

All objects are examined with a quality-control eye.  This involves assessing the overall ‘look’ of the object, making sure it’s good enough quality to be added. The complexity of the model is also assessed (number of polygons) and the size of the texture.  Obviously the size and nature of the object is taken into account in this assessment – I won’t accept a car with 40000 polys but equally a static aircraft that only has 10 isn’t going to be very pleasing.  Texture efficiency is more strictly monitored nowadays, unnecessarily huge textures will fail QA (although if this is the only problem with the object, I’ll do the texture re-scaling at stage 3).  If any object fails at this stage, I’ll feed back to the contributor with some positive suggestions on improving it.

Stage 3: Copyright

If the contributor hasn’t supplied copyright information about the contribution(s), the next thing that happens is they get an email back asking for this information.  Nothing further will happen until copyright information has been received for both the object model and the texture – the author of every contribution must be supplied or it gets deleted.  If the contributor hasn’t already obtained permission from the author(s) then every one of them gets an email asking whether they will allow their work to be included in the library.  Usually I ask for blanket permission for all of their work, to save time later if someone else contributes something from the same author.  (Incidentally, all these communications are archived).

Stage 4: Corrections – Origin, Alignment, Scale, Texture

If the object has a definable ‘front’ (e.g. aircraft, buildings) then this is aligned North.  In the case of objects that have a ‘nose’ (e.g. vehicles) then this is aligned to the origin (0, 0) otherwise the origin is typically set to be the centre of the object. The object scale is checked as it’s amazing how many objects need to be dramatically scaled to the correct size. All the geometry work is done in Blender, and care is taken to alter all levels of detail (LOD) if provided.  Finally the texture is scaled if necessary, using either The Gimp or GraphicConverter.

Typically the screen-shot will be taken at this stage if one hasn’t been provided.

Stage 5: Primary Categorisation

This involves deciding on the main place that the object is going to appear in the library and simply creating a folder for it on disk. This is getting easier and easier to decide as the library has taken shape.

Stage 6: The info.txt File

The info.txt file contains all the information about the object – The title, copyright owners, whether it is animated, as well as any secondary categories that it should be published to.  This file is read automatically by the script that packages up the library, so it uses a standard layout that can be easily read by both humans and machines.

Stage 7: Commit to the Version Control System

At this stage all the new files are committed to the version control system. We used to use Subversion which was kindly hosted by Indi, but nowadays it’s all on GitHub. Without using a system like this it would be impossible to manage the large number of files in the library.

In the next episode I’ll talk about what happens next – the building of the library.

The post How the Library is Built – Part 1 appeared first on OpenSceneryX.

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).

The post Old Liveries appeared first on OpenSceneryX.

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.

The post Virtual Paths appeared first on OpenSceneryX.

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.

The post Backward Compatibility appeared first on OpenSceneryX.

1. The installer firstly checks whether it needs to update itself and will tell the user to download a new version if one is available.
2. Next it scans the user’s existing local OpenSceneryX folder (if one exists), gathering information about every file it finds and creating a CRC checksum for each.
3. It then downloads a manifest from the OpenSceneryX website.  This is an XML file that contains an entry for every file that exists on the server, together with its file size and a CRC checksum.
4. Next, each entry in the manifest is compared to the information from the local file system and a list of new, changed and deleted files is generated.
5. The installer then deletes all the local files that it no longer needs and downloads all the files that are new or that have changed.  It uses a standard HTTP (web) connection on port 80 to avoid firewall issues and every file that it downloads is individually compressed to reduce bandwidth and download time.

The basic principle will stay the same, but the installer is currently being revamped to be more user-friendly and will present a standard step-by-step install process, describing what it is doing at each step. Not sure when this will be out, but “soon” is probably quite a good estimate.

The post The OpenSceneryX Incremental Installer appeared first on OpenSceneryX.