I thought I'd try my hand at adding (and TM'ing) a new airport, specifically, 21W (Ranger Creek in WA).I was able to add airport, runway, and comm records with no problems, and make DEX files so other folks could do that too.But now I've run into a problem. The TS'ed elevation grid, with its higher precision elevation data, differs in hight from the default grid by quite a ways (around 900 ft, if I recall right). No problem, I don't care much about the default elevation grid, but my airport sits right smack in a hilly area. I presumably can find a way to flatten the terrain (although I don't think I can use the flattenator) - but what happens when I want to distribute my airport? Seems like everybody would have to go through the same flattening process, which looks a bit painful.Is there a way I can package up just a correction to the TS elevation data around the airport? Does anyone have experience with packaging up airports for distribution which require flattening?John/madmax

JohnIf you distribute either your scenery pod, or the data files needed to TS that tile, then users who create that pod will have the same elevations that you do.If users first apply the dex file before slicing then the slicer should take care of it.Just distributing the dex file(s) will not allow other users to get the elevations required.Colin

Colin - Thanks for the reply. I was hoping to avoid distributing the entire scenery POD, because, well, it's enourmous :). The entire globe tile is around 450 Mb, so I just hoped to distribute a smaller POD containing my TM'ed airport.However, maybe I can just distribute the smaller elevation file (.ras, right?) and people can re-slice that area if they need to.Or maybe I don't even have to do that - if I understand you correctly, it sounds like once I import the runway and airport DEX files into Fly2, that the slicer will take care of the flattening? That'd be great - I'll experiment with that tomorrow. It'd still be a slight PITA for people to have to do that, but, I guess, it's not so bad.John/madmax

John:The slicer creates four files one for each 1/4 Global Tile: G00.TRN (SW), G01.TRN (NW), G10.TRN (SE) and G11.TRN (NE). What you could do is upload the .DEX on one hand and these files in a POD. Depending on where exactly within a 1/4 global tile the airport is located, you may need to include .TRN files from adjoining global 1/4 tiles. If you don't, there will be big gaps or tearing in the user's scenery.Let me know (send me a private message) if you need help with flattening and/or with determining which .TRNs to modify and include.Take care,Alejandro AmigorenaCheshire, CTFly! II Beta Team MemberAthlon XP 1800ABIT KR7A-RAID768Mb RAMMSI GeForce 3 Ti 500 64MBSB Audigy GamerCH Flight Yoke USBCH Pro Pedals USB

John,You could distribute just a small pod and the dex file. That should work so long as you include all the trn files created. The troulbe with that ides is that you would have to find out just how many globe tiles the dem data covered and export all the trn files for those affected.Distributing the .ras file would work and would probably be easier.It would still involve the users having to slice the scenery area, but just with the dem data, which is pretty quick.The steps would beImport the dex files, then slice the dem data then add your pod to the scenery folder last. That way the slicer would 'know' about the airport before slicing the dems.Colin

I tried re-slicing that tile last night, and the slicer did flatten the area around the airport, but not in a very good way. The airport is supposed to be in a valley, but instead, the slicer raised the area around the airport by 600 (!) feet, so the runway elevation is way off, and it looks goofy because it's on this huge raised area above the valley floor.Hmmm...John/madmax

JohnThat's a shame. Looks like the .ras file is the way to go, then :(Colin