hjwalter

Hi there guys, Yes, I remain a diehard Afcad program user because it's (for me) simpler than ADE and still does everything I need it to do. However, my "dirt" runway textures have quite suddenly become a green/yellow-ish color instead of the original light brown. A clear incorrect texture, which has somehow been replaced/overwritten/corrupted when I wasn't looking. Taxiways and ground polygons are all still the original "dirt" colors and it's only the runways which give me this problem. When I dis-assemble any "dirt" runway AF2_XXXX.bgl file into XML, I see that "DIRT" is specified for the runway but I cannot find any direct link to the related texture (.bmp) file. I've searched my whole FS9 folder for "Dirt.bmp" textures, have found a few but temporarily disabling them had no effect. Does any of you experts know where the Afcad program looks for it's runway "dirt" texture or otherwise know of a solution ? Thanks in advance and stay healthy. Regards Hans

Thanks again Tom for your clear explanation. Hans

Hi Guys, Is it worth all the trouble to systematically convert, e.g. DXT3 or higher quality airport textures to DXT1, while at the same time checking if their alpha channels have remained intact ? Will these then load faster because they have become smaller in size ? Where are such textures de-compressed ? Via the graphics card's GPU and it's own directly related memory ? Yes, I know that a detail and/or color price must then be paid but my question is only about the principle of possible faster loading speeds. Regards and stay healthy. Hans

If your problem concernes more than one of your Mach 1 airports then one of the possibilities is that your very specific original flood lighting apron textures are no longer present in the airport's texture folder(s). This causes FS9 to search for and to possibly find a texture with the same name in it's main overall texture folder. However, this general texture could have an ALPHA channel issue, as Steve0616 correctly points out, hence the black squares remaining visible in one or more of your Match 1 airports. It's also possible that that the existing flood lighting textures in your airport texture folders are somehow suddenly missing their very specific ALPHA channels, e.g. because they have been converted from one compression format to another. Bulk conversion programs can often mess up such very specific ALPHA channels. If you do not have much experience or knowledge with/about such texture issues, then you safest option would be to re-download/re-install these airports, unless of cause you have a good backup somewhere. Good luck. Hans

Please quote your downloaded file name so that at least I can try it, to see what the problem is and/or how to fix it. Hans

I've had the same problem myself when flying ATC but not (yet) at Perth. After much searching and sweating I found that there were errors in the Afcad file of the destination airport. The start positions turned out to be the cause, which was consequently also confirmed by the Afcad "fault finder" process. I deleted the start positions and replaced them with my own = end of problem. Another possibility is that your Perth airport is a duplicate, whereby "duplicate" means that the addon Afcad header data does not EXACTLY match the default header data. You will normally be able to see this in the FSNavigator map, where two of the same YPPH ICAO codes can then be seen very close to each other, in other words, on top of each other = a duplicate. Hope this helps. Hans

Peter, I hope you are still following this thread because I have sent you a PM. Greetings Hans

Hey Guys, I think I have found the reason why certain AI planes do not want to, or cannot land at e.g. UGAM and/or at VQPR. It's not that I would really want Boeings, Airbusses, etc. to land there but in my mind it's purely a technical "issue". My theory: AI planes can in practice approach the initial auto-approach beam from any direction but the angle at which they do this can be such that especially the faster ones, then cannot make the necessary tight turn(s) in order to "capture" the beam but instead, fly through it without the necessary "capture". The result is that for these AI planes the default approach is then performed and which consequently results in them not being able to land, etc. Because of this, any visually correct approach/landing through mountain valleys by any type of AI plane, remains unpredictable. It's in fact the same for Peter's well written tutorial in which he bases his AI approachs to LYTV on the possibilities within the ADE program. Comments. Anyone ? Greetings Hans

Yes, Guenther's AI approaches to UGAM do work correctly for lighter/smaller AI planes but can anyone come up with a good technical reason why those same AI approach routes do not work for e.g. an AI Airbus-319 or an AI B-737 ? After all these AI planes (should) at least theoretically, follow the same approach routes, the only differences possibly being their weights and/or approach speeds. But, if these weights and/or speeds would somehow make the difference, then one would expect them to at least crash somewhere near UGAM instead of making one or more "Go arounds" at relatively high altitudes, followed by flying off into the blue yonder and finally disappearing. As if they just do not want to land at UGAM at all, Looking forward to any answers. Hans

Steve, I downloaded and test-installed both found versions of Match-1 Design Group's KBNA on this site but apart from them both looking very barren and dead, I found no blurries anywhere. I'm therefore sorry for not being able to help you any further. Good luck. Hans

Alan, Can you please supply download file names and from where you downloaded them, so that I can try your problem myself and report back in this thread. Regards Hans

If you would tell us what "BNA" is and/or, if you would give us a download file name, maybe someone could help you. Hans

Guenther, I have not tested UGAM any further because my AI approaches there are now all being performed correctly and even by different AI types. Very spectacular indeed and many thanks for all your work. Normal piloted ATC vectored approaces also work correctly but during the last few miles the pilot really needs to know the way through the winding valleys. No problem though because this is what flying is all about. However, my only remaining and very spectacular airport, where this AI auto-approach system does not seem to be able to work is VQPR, Paro in Bhutan, where the mesh mountains all around are so high and at such close proximities, that even flyable aircraft need very steep final approaches for landing. AI take offs also remain a problem because, even after their related aircraft FDEs and CFG parameters have been edited, they cannot realistically climb steeply enough to avoid some mountain tops during their climb-outs. In the meantime I've seen some YouTube movies about real Airbus 319 approaches/routes through the mountain valleys to both runway ends at Paro and to my great surprise, these can also be more or less followed correctly when approaching the FS9 depiction of this airport, but then again, once the aircraft has entered the initial valley, it's pilot really needs to know the way to the airport. Thanks again for the lessons. Regards Hans

Guenther, I have reacted to your private message but also have some initial technical questions for you, which I hope you can answer. What are the basics for creating such a (mesh-)mountain dodging AI approach path all the way down a winding valley to a final landing at the valley's bottom ? E.g. What is the first point to which the AI plane is steered and what path(s) does it then follow to the airfield ? Is XML the only way of programming this ? Do you know of any tutorial I can make use of ? Fond regards Hans

Yes Collin, you are right but without any mountains or other high ground in the direct vicinity of the destination fields, it doesn't make much difference, other than that approaching VFR AIs make quite some turns and twists before entering final, while IFR AIs make more straight in and ILS-like approaches. For testing/checking purposes I quite often position my Grumman Tomcat somewhere on my airports/airfields and therefore also on UGAM, predominantly to check approaching and departing AIs. Why a Grumman Tomcat ? Because it has a radar gauge in it's panel and on which I can follow airborne IFR and VFR AIs to/from maximum 40 Nms away. Not only that but I can also check their flight dynamics at different speeds. As the result of your earlier IFR remark I checked all my AI flight plans involving the six airports/airfields in my list and changed all VFRs to IFRs. So, it's a big thanks to you as well. Regards and happy landings. Hans

Hans-Gunther, I substituted my original AI LET-410 AIR file with one included in an AI LET-410 base files download and saw that it was basically a DH-6 Twin Otter AIR file. Did not notice much difference in the flight characteristics though but this (AI) Twin Otter at least externally looked a little more like an (AI) LET-410 than my originally used Beechcraft King Air's AIR file. However, I have the feeling that this in itself was not the definite "cure-all" for my original problems/questions. I also increased the pattern altitude at UGAM to 2760 feet (ASL) because the original was even (far) below the actual airfield altitude of 1760 feet (ASL). However, I have not tested the effect this could have had any further. I took off in one of my flyable LET-410s behind an AI LET-410 from Tblisi airport (UGGG) and followed it to UGAM while it was flying a VFR flight plan but it again disappeared into a mountain during the last stages of it's approach, seemingly to RWY 11. I then changed it's flight plan into IFR and again followed it. Low and behold ....... this time I was able to follow the AI LET all the way through the valleys to a final touch down on UGAM's RWY 29 and to me this confirms that any AI flight plan involving UGAM as it's destination, MUST be IFR and not VFR, especially when a custom Jim Vile type AI approach is active. This then automatically also holds true for any other airports/airfields where Jim Vile type approaches are active. The only problem now left over is that AI take offs, cannot follow the same mountain dodging routes ...... yet. My only criticism on this UGAM airport is that the README file is not very clear on this whole subject. Anyway Hans-Gunther, thanks for the lesson and your part in the UGAM approach project, I have learnt a lot from it. I also thank all you other guys for your reactions. Regards Hans.

Hans-Gunther, Yes, my AI aircraft, which flies IFR between UGGG and UGAM, is a LET-410 but to my great surprise, the FDE (= Air file) specifies the Beechcraft KingAir 350 in it's description field and is therefore not the original AI LET-410 FDE. My AI LET-410 itself seems to fly quite normally. However, I have 6 other seemingly very well working and non AI aircraft specific (I think Jim Vile's) AI approach files for the following airports/airfields: (Positioned in my Generic/scenery folder). LOWI Innsbruck in Austria. 7Kb LSGS Sion in Switzerland. 4Kb LSZA Lugano in Switzerland. 3Kb LSZL Locarno in Switzerland. 2Kb LSZS Samedan in Switzerland. 1Kb VHHX Kai Tak, in Hong Kong, which us still active in my FS9. 6Kb I assume that the different file sizes represent their different degrees of difficulty. These all seem to work correctly for AI approaches/landings by non-specific AI aircraft and I have tested the process at each airport/airfield by following different (test) AI aircraft from their take offs, then flying in formation with them and finally down to their correct landings. However, I must also admit that some of my heavier AIs could not exactly follow the sharper turns, e.g. to final at VHHX (Kai Tak) and would then land either next to the runway or in the adjacent bay. However, I was able to fix these problems by decreasing their empty weights and/or fuel loads. Hans-Gunther, are you telling me that the two approach files supplied with the UGAM's download, should have the same function as the six I already mentioned above ? And if so, could the AI Beechcraft KingAir 350 FDE be the culprit ? In the meantime I will search for a LET-410 base file and will do some testing with it's FDE file ...... if found. Thanks for your help and stay healthy. Hans

hgschnell, The downloaded file name is: ugam_ambrolauri_georgia.zip and can be found at AVSIM and possibly elswhere as well. This very light airfield did not exist within the basic FS9 but for that reason the author has included two approach BGL files, one for UGAM's RWY 11 and the other for RWY 29. However, these are good for user aircraft in which the pilot can dodge the mountains during the final part of his approach, but according to Jim's tutorial, these can also work for AI aircraft. Unfortunately though, AI aircraft do not dodge mountains during their approaches but fly straight through them and for that very specific reason Jim has made completely separate AI approach routes for some airports/airfields in mountainous areas, so that approaching AIs now visibly dodge the mountains in their very own AI way. It's this very specific Jim Vile AI approach technology on which I'm now busting my brains. Hans

I assume you mean that they porpoise visibly during their approaches and if so, try increasing their empty weights by, e.g. 5 to 10K pounds. If that does not solve your problem(s), try the AIR file from any default AI of (more or less) the same type. Good luck. Hans

Hi Guys, The late Jim Vile, may his soul rest in peace, has made some excellent approaches to FS9 airfields/airports so that AI aircraft do not visibly fly through mountains in their immediate areas, e.g. Innsbruck (LOWI), where such AIs approach very realisticly through a winding valley. I've been busting my brains in trying to find out what the basics of Jim's methods were but even after disassembling some of his BGL files, I still have no idea how to even begin. My interest in the above is for the small picturesque addon Ambrolauri airfield (UGAM) in a very mountainous area in the state of Georgia and which was not included in the default FS9. In the meantime I've edited the included "normal" approach BGLs for flyable (light) aircraft and ATC now vectors me in such a way that further visible and extremely spectacular approaches through the winding valleys, have become possible. However, AI aircraft sometimes beat me to it because they have "straight in" approaches through the mountains. Advice anyone ? Thanks in advance. Hans

Just a shot in the dark here because to me your problem sounds like a possible scenery layer priority issue in your scenery.cfg file. Have you tried to (temporarily) replacie your now active scenery.cfg by an old backed up one, just to see if your issue changes ? Good luck, Hans

Just an afterthought. When starting up your FS9 for the first time after switching on your rig, do you need to start your FS9 up twice before it actually opens ? If so, you may have a registry problem, which has been handled in this forum about two years ago. Regards Hans

Bob, I downloaded/installed your three Italian carriers and they all presented themselves normally but rather devoid of so called "eye candy". However, after sitting on each of their flight decks in one of my test aircraft and then shutting my FS9 down, there were no automatic re-starts. I took a good look at each carrier Afcad file and found them to be rather strange in their basic designs. E.g. They had no runway(s) which are basically needed for hardening their complete flight decks. They only had very small as "runway" specified rectangular areas, spread out on different parts of them. I found their flight decks not to be hard under all circumstances. The only "problem" I found concerning the "Wind.bmp" texture file, was that it had no alpha channel. However, setting it's alpha channel did not improve anything, at least not visibly, nor did it cause/solve any automatic FS9 re-starts. After trying and testing some more but without being able to replicate your automatic re-starts, I finally give up and deleted everything. For many years I've been using an old but very well made carrier named "Waikato" situated off the East coast of New Zealand's North Island. Why there ? Because it has a land Air Force base named "Whenuapai AFB" (NZWP), situated a short distance away and which makes them both ideal for short flights between them, using military jets, helicopters, etc. Not only that but I've also set up Rob Barendregt's catapult and cable trapping systems on an Air Force Base named "Patuxent River NAS" (KNHK) in the USA. I use this for practicing my carrier flight operations. Regards and happy landings. Hans

I've never heard of this problem before, so just for my own correct understanding, what you're saying is that when you shut your FS9 down (= exit the game) it completely automatically re-starts again. This does not happen when you've temporarily de-activated your carrier scenery and have flown any other non carrier related flights, pre-saved or not ? A further question: If your FS9 keeps re-starting after shutdown, how do you shut it down completely ? Do you pull your machine's plug ? A bad texture as being part of any active scenery, can certainly cause a system crash or hang when being called apon by the related BGL file but certainly not an automatic re-start after a complete FS9 shutdown. In the meantime I will download and (test-)install your carriers to see if I can replicate your problem. However I'm using Win7 64bit but that should not really be any different when Win10 is being used, at least not with your kind of basic problem. Regards Hans

I downloaded and installed the same Lahore airport scenery (I think) and the textures you are missing seem to be AG tree textures being called for by the "shrubs.bgl" file but these textures are not included in the download and should normally be present in your main texture folder. However, I did not test/try any further because there were just too many other problems, e.g. your missing trees and many other scenery objects, were popping up at far too short distances from my taxiing plane, instead of at more realistic distances. Pity but in the end I deleted/discarded everything. Sorry for not being able to be more positive about this airport scenery. Regards Hans