Problem with fs9, afcad v 2.21 trying to move airport get CTD

[drskyking 0]

I am trying to move the small airport I fly my Aeronca Champ out of, 0NY7, 20 miles NW of Albany, NY. I used AFCAD2004 to move the runway where I wanted it centered, 4-22, and created the grass 10-28 made last year. I save it, new height is 915 feet, not 940 also, as AF_0NY7.bgl into Addon scenery/scenery folder as I do with other airports, restart FS9 and when I try to go to KSCH about 16 miles from 0NY7, as soon as the initial load taskbar gets to 2% I get crash to desktop unless I remove AF_0NY7.bgl. ANy idea what is going wrong? I can change the stock runway width and texture and save the new bgl, but as soon as I try to move the runway, CTD!! Thanks. Robert

[jvile 1]

RobertYes you will get a CTD if you try and move a STOCK airport to far from its origial LAT/LON value.AFCAD does not move airports. I continue to see post where designers say they are relocating airports using many different techniques but none of them will work properly.Some designers even decompile a root APnnnnnnnn.bgl and change LAT/LON values and then compile using the MSN BGLCOMP compiler. This destroys as many as 250-300 other airports (taxiway signs, fuel services, region codes, GPS Approach data, missed approach data etc.) that are embedded into the same APnnnnnnnn.bgl root file.You must fictitiously delete the original root airport that you want to move and then add it back into the scenery database.I will use your airport as an example because it ia a simple airport to relocate. The reason why is because there is no NAVAIDS (TERMINAL_NDB'S VOR's, VORDME's, Approach Data, missed approach procedures, TERMINAL_WAYPOINTS) that need moving or any default autogen buildings. <?xml version="1.0" encoding="ISO-8859-1"?> NOTE Change lat/lon and altitude for runway 04/22Change the 2 start location altitudes and give them a new approximate lat/lon value so you can find them later with the AFCAD program.Once the lat/lon and altitudes for your new location have been changed, use the BGLComp compiler and compile. If you use my example which will compile then make sure the file extension is .xml (0ny7.xml). This will produce a 0ny7 bgl file.All of the

[drskyking 0]

Thanks Jim! I will try that tonight, looks like something I can handle. The spot I wont to more it to even shows the actual Strip, FS Genesis US Landclass! Will try to post a pic!

[meshman 109]

>>For others reading this, if you try and move a airport that>has Approach data, NAVAIDS, TERMINAL_WAYPOINTS and default>autogen buildings associated with it the process in more>complex but it can be done.>>hope this helps Oh, did someone mention my problem?I'm working on moving Hawaiian airports to better fit with UT:USA. It's been going well, up until PHJR-John Rodgers, just a short hop from Honolulu Intl.I was looking through the default AP905240.bgl file and find all that you mention above. So in the course of the airfield being 400+ meters off it's more appropriate location, I have the above to address and I wonder/worry about the field VOR impacting PHNL and your revised ILS appraoch for it.Can you steer me in the right direction to begin to comprehend what all this entails? I'm just hoping it won't require a degree in aeronautical engineering or take me so long that FSX is released before I finish my project.Thanks for any assistance Jim,Lance

[jvile 1]

LancePHJR is one of those airports that is a little harder to move due to the approach data for the VORDME (ARC Transistions)4R and the NDB Transistion Approaches. A new airport header LAT/LON/Altitude must be compiled to block out what is in the APnnnnnn.bgl.Moving PHJR will have no effect on my PHNL ILS curved approaches or on any part of the default FS9 Approach database except 08L ILS (see below).Once the new LAT/LON for PHJR is calculated then all the waypoints, exampleMA04RFF04RSUTLYTARLEetcwill also have to be relocated using xml. The approach data does not need to be rewritten once the TERMINAL_WAYPOINTS are moved. Everything will realign properly.The EWABE NDB's will also have to be moved to the proper LAT/LON value(xml). This will not effect the 08L ILS beacon at PHNL if the NDB is moved accuratly. The problem here is there are 2 NDB's stacked on top of each other. MSN did this so PHNL can use one as a normal NAVAID NDB and PHJR uses the other one which is a TERMINAL_NDB (duplicated).Of course none of this address's all the default airport buidings and taxiway signs that will also have to be moved. That is acually easier to do then it sounds because all the taxiway signs are written in xml (same as the buildings). If you move the airport only and add a new airport ground poly all the approach data seen with the GPS receiver will be out of place.If your work is a future upload I will rewrite/move the xml data for you if needed.

[meshman 109]

Thank you Jim, both for your reply and offer.I've adopted the "JV" approach to major moving of airports, by utilizing new code in the sceneryGenericscenery file, so the default buildings are no longer a problem and the taxiway signs were an easy relocation.But I do look forward to your input regarding the approach data and will contact you off board.Lance