TIPS & TRICKS

Oh boy! Sometimes people do things that they shouldn't, without knowing that they shouldn't and next they're putting their stuff somewhere so you can download it. Nice, but no, it isn't.

An example: at www.avsim.ru I found several sceneries for XPlane. One was for Hurghada/HEGN. Well nice, I was already sitting there, downloaded the scenery, installed it and fired up XPlane once more. 3 minutes later it crashed to the desktop, showing a note "object x missing". Would you start at Rome and then fly to HEGN, you'd probably crash closing in on HEGN. So much for the flight! Anyway, I thought "let's fire up the Overlay Editor and find out what's wrong". Unfortunately also Overlay Editor wouldn't load the scenery, it simply hung up whilst loading objects. Damnit!

But as the Jerries already said quite some decades ago, "Vee have vays of makink you talk!", so do we. Get the tool XGrinder, it's free available. Fire it up, then go to your Custom Scenery folder, to the HEGN section, go to the subfolder "earth nav data" where you find another subfolder "+20+30" and get the +27+033.dsf file into the Grinder box. Hey Presto! and you'll find a +27+033.txt file after a while. Load it into Notepad or Wordpad and start reading. You'll find a few lines like this:

OBJECT_DEF ruscenery/buildings/radaraorl85.obj
OBJECT_DEF ruscenery/buildings/Mast5.obj
POLYGON_DEF ruscenery/polygons/lightspot1.pol

Hah! In this case those three are the bloody criminals... since YOU don't have a directory "ruscenery/buildings", or a "ruscenery/polygons". Hmmmpff, how do we solve that? At the Avsim Russia site I couldn't find anything alike at all, so...

Izzah simple: remove them from the file. Now it gets nasty... the first part of the file lists all the Object Definitions, starting at 0 and ending wherever (but they show no numbers, so count carefully). The same goes for the Polygon Definitions, also starting at 0 and ending wherever. Then comes the list where all those objects literally are located and here they are called OBJECT 0 up till OBJECT 2771 if you're unlucky.

In the case above the two objects not available were listed as OBJECT 179 and 183, by careful counting (remember you start with zero!). In total there were 188 objects defined, so when you remove 179 and 183, the next ones get new numbers. Not in the Object Definition list (they are simply removed there) but in the following Object location list! The same of course goes for the polygon that is removed. So somewhere in the location list you start to renumber objects. Sometimes an object is only used once, but it could also be 200 times. Be careful, don't do this when you're feeling like "I shouldn't have taken all those beers last night" or you'll mess up more than you'll be fixing. So in the example above the line in the location list starting with object 179 should be removed, then object 180 will get a new number 179 and so on. Capiche?

When you finally think you manipulated the textfile OK, drag it back into the Grinder window and Poof!, Grinder converts it into a new +27+033.dsf file, which you put into the right directory of course.

NOW you can go to Hurghada and enjoy the scenery. If the blawdy Russians had used their heads they would have put in those files in the general Custom Scenery folder and you wouldn't have needed to go through all those things, but hell, they're also humans, remember? To be honest, they also didn't know where to put the PAPI lightsets along the runway, if you try to land a 747 by using the PAPI lights, the runway will appear to be very short... despite its length of 4161m. That however can be fixed using WED.

For those flying a lot in Russia: a lot of their sceneries use Ruscenery, so perhaps it would be easier to get the stuff from http://ruscenery.x-air.ru/ where you can find it as RuScenery.zip (253 MB). Extract the folder ruscenery to Custom Scenery and your problems are over. Since it gets updated every now and then, it could be wise to download the Winupdater.exe too. Consider it as a Russian XOpenscenery thing.

I have been talking about putting an object somewhere, where it isn't officially located. Especially if the structure consists of hundred(s) of individual objects, all with their own centers and angles to put em into to show up right. I'll show a simple example:

OBJECT 26 33.80533684 27.18913367 344.997940
OBJECT 27 33.80533684 27.18913367 344.997940
OBJECT 28 33.80534066 27.18910315 344.997940

Suppose these are three parts of a total structure and they all are located at 33.8053somewhat North and 27.1891somewhat East and they shud be put there at a heading of 344.997940 degrees. But you want them in the tile 52.20 North and 4.40 East. Those 3 objects are easily imported into the scenery area "Hush" you were creating, then take the heading they should be put into from the list and move them around until they are exactly where you want them to be. But now the structure consists of 299 individual objects all with their own centers and headings. Again, first create a text file with Grinder from the relevant dsf file. Copy the relevant Object Definition lines and the relevant Object Location lines into a new textfile, which you need to call after the tile where they should be placed. All north locations 33.etcetera should be changed into 52.etcetera and the east locations 27.etcetera should be changed into 4.etcetera. Here you simply use the search&replace function. The object location lines however now need to be renumbered from 0 to 298, remember? Add the relevant header and footer lines and then shove the file back into Grinder which will put a nice output file in the right directory. Err, the right headers and footers? Yessir, if that is no good, you'll run into new problems. So the best is to create a new scenery set in the Overlay Editor, at the right tile, simply add an object there, save the set and you will have at least a basic dsf file for the location with the right headers and footers. After that start adding your stuff. Also, don't forget to copy all the needed object files (together with the needed texture files) into your Custom Scenery/Hush or XPlane will crash next time you fly there. As mentioned somewhere else, I moved Heerema's Thialf from south of the Faroes to the central North Sea like that :-) Thialf is a big crane-barge consisting of 70 individual objects, all with their own center and heading. See the picture on the main "XPlane" page.

 

http://marginal.org.uk/x-planescenery/tools.html for the Overlay Editor and FS2XPlane

http://scenery.x-plane.com/tools.php for WED and the XGrinder stuff

Overlay Editor is for 3D stuff and to put polygons around; WED is for the basic airport layout incl. tower positions, beacon positions, PAPI positions and signs; FS2XPlane to convert FS/FSX scenery into XPlane stuff; XPlane itself is used to change/add NDB's, VOR's, ILS-es and the like.

In case you run into a scenery where a railroad, high-voltage line, road, houses or even trees are interfering with a taxiway or platform, simply use Overlay Editor to create socalled "exclusion zones" for these.

More stuff concerning converting MSFS sceneries to XPlane ones:

I found in a lot of sceneries made by FISD regarding Finnish airports there were a lot of flaws with airport lighting. Even when apt.dat said there would be centerlines lit, or runway edge lights they wouldn't show up. Around Xmas I was taxiing around at Helsinki in a snowstorm and although I know the airport very well, I almost got lost. Hell, where are my lit centerlines (not talking about the airport signs which were no longer visible). Hmm, I know they must be there, so where are they?

It turned out after conversion you have an object in your scenery which prohibits those lights to be shown. Two ways to solve it: the first one needs digging. Which object can it be, next you maybe find it and then check the object file where it comes from (coz' it comes from a BGL file). Delete everything, go to the MSFS package and delete the BGL file where it comes from, and convert again. A lot of work. The other way is checking the obj file in a text editor (yessir, it's plain text) and go to the end. There could be an attribute line saying ATTR_layer_group taxiways +3, which you can change into ATTR_layer_group taxiways -1, which also solves the problem. Next it could be possible that the conversion also provides you with an apt.dat file where all lighting is turned off.... so you gotta switch it on again in that one :-) Hmmpf, so much for MSFS sceneries... Happy hunting!

One final note on "How accurate is XPlane? A few things to consider: on Earth we calculate in nautical miles. Or better said: in degrees, minutes and seconds. 1 minute in north or south direction equals 1 nautical mile or 1852 m. No matter where you are, at the North Pole, the Equator or the South Pole. But, in east/west direction it does matter. Roughly spoken, at the Equator it's also 1 nm=1852 m, but the further you get north or south, the smaller the actual distances get. Close to the poles 1 minute difference in east or west direction is no longer 1852m but a lot less! Now, XPlane calculates in degrees and decimals thereof. Internally it calculates up to 0,00000001 degree. Thats 1,1 mm difference at max at the Equator, the further north or south you go it is still 1,1 mm in N/S direction but again less in E/W direction. Suppose you travelled all the way up from London to the North Pole and you're one footstep away from it. Then you could be standing at 89 degrees, 59 minutes and 59,9 seconds North, 0 degrees East (or West, your choice). The person next to you on your right also one footstep away from the Pole would be standing at 89 degrees, 59 minutes and 59,9 seconds North as well but at 90 degrees East... Would you be at the same longitudes but on the Equator, you would be 5400 nm apart. Somehow XPlane screws up here when calculating real distances in E/W direction at high latitudes. Go to ENSB at Svalbard. There is an ILS system to runway 10 there. The old XPlane usually has a range of 10nm for the GS system. Try to do an ILS landing there, and your GS comes alive on very short finals to the runway. Actually XPlane calculates the miles correct (because 1 mile equals 1 minute) but you better turn up the range for the G/S transmitter (and the LOC one too) to 50 nm there in order to have a practical usable system. Oh well... but now for the real weird part: since we are manipulating in XPlane already (map view, edit mode) add a standalone DME at the runway near the GS transmitter, make it operate on 108.00 MHz, give it a name (ENSB-DME) and ident (SVL) and make the range 50nm. Now take off, turn back to a heading of 280 and fly some 10nm out and turn back into the ILS (which has 18nm range on the LOC and 10 on the GS). At some point the DME will tell you you are 10nm away, but both your LOC and GS will be dead or wacky in indication. It means that here (actual DME distance) XPlane calculates in real nm, while with LOC and GS it calculates with geographical minutes, which are absolutely NOT the same in E/W direction as nautical miles... Austin, please explain!

Page revised 27.12.2012