by Cristiano Maggi Revision History 04/20/06 Initial Draft
This tutorial explains how to convert ENV custom scenery to DSF overlay custom scenery.
The porting operation of an old custom scevery v7 format into a brand new DSF Overlay is quite simple, but it needs a little bit of attention. As first step let's check if we have all the necessary tools to complete the operation.
The placement of custom objects under v7 scenery system was stored into ENV files, we must first of all identify the cohordinates of the ENV file which contains such information. If we don't already know the right ENV we can easily locate it by opening WorldMaker and under the tab "Airports" search for our location. When found, simply change to tab "Terrain" and in the upper left of our screen the ENV cohordinates will appear.
Follow this example: we want to port LIMW (Aosta Airport) contained into the ITA2 package onto Overlay. Open WorldMaker and search for LIMW by typing the ICAO code on the rightmost field (or the name of the aiport in the left field) and press enter. After a while our screen will look like this:
Now select the "Terrain" tab to change the visualization and show up cohordinates in the upper left corner:
Here we are: Aosta is stored into the +45+007 ENV file.
With a very simple and quick operation of drag-and-drop we are able to convert the identified ENV into a readable text format by means of Env2CSV tool. Just launch the tool and drag-and-drop the ENV file on its window to see the build of a file with the same name of the original ENV file, but with .csv extension, in the same place of the original one.
Now open the CSV file with any text editor and search for the string "objects": you will find a section in the CSV file that will look like this:
Scroll down into that section until you'll find a path after the three cohordinates number of the first objects. This is the most delicate part of the whole operation because scenery system of v7 was much more tolerant that the new one is: if some custom object was placed, and its path stored, into the ENV file and then that object was removed from the scenery, X-Plane didn't care and worked as well just not displaying the missing object. Now, under v8 DSF format things have changed, if such an information is stored into the DSF and the object is not present in the scenery, X-Plane will quit.
You must be then very careful to check if the objects path definitions stored into the ENV file are corresponding to the custom objects you have in the "Custom Objects" folder of the scenery package, and REMOVE all the other custom paths (only those showing a path after the cohordinates).
The LIMW example we are using is very eloquent in this sense because in ITA2 there were a lot of custom objects made only of light dots, in simulation of night lights. We don't want to keep all those objects because we have better default night textures in v8 scenery and, as soon as we will have 3d buildings all over the world like we alreay have in the USA, all that light dots would make up only a bad confusion.
In the following screenshot you can see the selection of those "light" objects to get rid of them:
Once all the unused objects have been deleted our CSV file will look like this, containing exactly only the custom objects of our scenery pack:
The last operation to do is change the actual path with the one we would like to have in our future overlay scenery package. Since the new overlay system permits us to have as many "layers" (overlays) as we want, my suggestion is to design the new scenery package in the simpliest structure we can and to put custom objects together with their textures into a folder that we can simply call "objects" (but we can customize the name in the way we prefer.
We will then edit our objects' path this way:
ENV editing is over, we can now re-convert the CSV file into an ENV in the same way we made the inverse operation, Env2CSV tool works also in the opposite direction, giving us back an ENV file in the same location of the original ENV and the derived CSV, the new ENV will have the word "new" added to its name:
Now we have to launch the second tool, dsf2text, which will pop up a window that will look quite identical to the one of the previous application. Dispite to its name, dsf2text will recognize the ENV file, we will drop on that window, automatically converting it into a DSF Overlay file.
Note: If we want to convert into DSF Overlay a scenery package for which we are sure there are no orphaned objects, of course, we could accomplish this ENV to DSF conversion directly, without the need of ENV editing described before, but in this case we will have to preserve the original objects' path.
The editing work is over, we now only have to design the structure of the new overlay scenery package. Its name can be anything we like, but inside the main folder (destined to "Custom Scenery" folder) we must have:
Into the "Earth nav data" folder, then, we will have to make a folder with the "grouping cohordinates" to which our DSF depends, in our LIMW case the main folder should be +40+000. The eventual custom apt.dat file of our original scenery package must be put into here too.
In the "+40+000" folder, then, we will move our overlay DSF obtained before, changing its name for getting rid of the parts X-Plane would not be able to read (+45+007_new.env.dsf must simply become +45+007.dsf).
Last operations consists in copying all the custom objects from their original location, together with their textures, and paste them all into the "objects" folder we have prepared in the new package structure. Open the objects then, one by one, with a text editor, and correct the texture path to delete the path section that is no more needed. Change then the name of eventual LIT textures files which in v7 where in the format "textureLIT.bmp" and in v8 must be "texture_LIT.bmp" or "texture_LIT.png".
Note: If we converted into DSF Overlay a scenery package for which we were sure no orphaned objects were present simply using dsf2text, the original objects' path is still the one we must preserve into the overlay package.
We can now put our scenery package into the "Custom Scenery" folder of X-Plane, run the application, and choose the airport we just edited as starting location. If we have correctly accomplished all the described steps, we will be able to enjoy the old scenery also over Global Scenery.
X-Plane can perfectly interprete the old format of the scenery package, but if we want to update it to optimize performances we could make two things more: