It seems that the scenery files are saved as a .pc2 file.
The bit you've written about is the bit that calls the .pc2 file, and says where it should go.
Code: Select all
FIL "0000000......whatever01.pc2" //So this is the bit that calls on the pc2 file. Techincally you could have a separate file somewhere else in the folder, though most seem to be located within the .fld.
POS Well, that's obvious...
ID 0 //Probably a unique ID if you reuse scenery files, so it can figure which one you mean where
END //well, that's obvious
So, the ID bit does make some sense, because you could have a PC2 file that is a runway approach light pattern or something. It's a standard design right? So why not reuse it? But each one will need a different position.
So. The actual PC2 file looks a bit more like this:
Code: Select all
PCK "00000000.pc2" 9 //This is the name of the PC2 package. The name is what it's calling on in your PC2/FIL section. The number after is the number of lines the file is, including the title. So in this case, 9. (This was my first stumbling block above)
Pict2 //Well, it's a PICT2 file.. Maybe there are other kinds
PLG //Polygon! I'm just going to look at this for now.. maybe in the future you can look at the other kinds
COL 46 112 10 //RGB colour
VER 146879.42 164321.21 //First vertex
VER 148259.09 119482.10 //2nd vertex etc etc.
SPEC FALSE //Specular (so is it shiny)
ENDO //End of this polygon. Now you'd do another one if you had one, so you'd then start again with PLG etc etc.
ENDPICT // that's the end of the PICT2 file.
so that could be saved as a separate pc2 file, or within the fld. I guess if it is serparate, it maybe doesnt need the PCK title?
...My map is still convexing
Okay, so it finished convexizing or whatever its called. Now! We have a map of GB! It's reasonably detailed... reasonably.... The coastline is made up of 2000 points. The other limit is that it is just the mainland. Since I'm going polygon>points, there is no differentiation between separate polygons really, so all the islands are lumped together, and that makes some weird geometry.
I was thinking, I could use the SRTM (Shuttle Radar Topography Mission) data of the UK, and convert it to a terrain file (not sure if that little app on here would cope... It's 300mb..), but I dont think YSF could cope either...
So, I'm going to give it a try
(Well, I'm going to scale it up. Its normal resolution is 90m... I'm going to use 360m because... well, it'll take all day otherwise)
Hehe, I killed excel...
This thing is going to be a monster..... I seriously doubt YSFLIGHT will be able to cope with it
Excel still can't cope... Having to do it piece by piece... 64Bit version of excel would be nice too... This one can only use 2gb ram
Turns out Notepad++ can't handle text files that are over 200mb.
So, where this stands:
I can't convert the entire SRTM terrain grid for the UK into YSFLIGHT at 360m grid squares (Which are pretty big, so that's probably the lowest level of detail I'm happy with) because I can't edit it from an excel spreadsheet into a nicely formated .ter file... (I guess I could write a python script to convert it, but I cannot be bothered.)
I'll try again with a lower (urgh) resolution SRTM map.
So, new SRTM map, lower res (1km squares). Still no joy, YSFLIGHT just can't seem to deal with elevation grids that are 30mb....Ah well, was worth a shot. If I have time (With lessons to plan for the coming weeks... we shall see) I may try bringing out some areas of terrain from the SRTM, so, maybe National Parks around the UK, and getting them as terrain grids. Might be the answer...