hjwalter

Rubbish! It is entirely dependant on the mast position and angle of attack. You WILL notice transitional changes (nose down for acceleration for example).

 

How much helo time do you have in the real world?

Rubbish ?? There are far more helo types without tilting masts than there are with them, whether you like it or not. Furthermore, my helo time on such helos is not something you have the right to openly question.

Explaining the advantages and effects of tilting masts in addition to my fixed mast post, would have been far more interesting for all readers, than your very undiplomatic and coarse reaction.

Hans

Real helicopters always fly nose down depending on their forward speeds. This is because they have no forward pushing/pulling power like fixed wing aircraft have and therefore need to tilt nose down in order to gain and to maintain their forward speeds.

Flying a real helicopter is in fact a constant balancing act for it's pilot, between his main rotor collective and cyclic pitche controls, combined with his anti torque tail rotor control, all of which constantly effect each other, depending on forward speeds.

It's therefore my opinion that seeing any AI or flyable sim helicopters, flying forwards at any speed without the strongly related nose down attitude, remains vey unrealistic.

Hans

Tom,

Thanks for your reaction but when the EZ program produces the error message, there is no choice or possibility to disregard it and to somehow place/position the object concerned anyway.

Yes, it now seems that the problem must be attributed to the EZ program, which somehow cannot handle ex-GeoLocked models and/or their related Guids. Great pity.

Hans

Hi all,

There are many FS9 scenery objects, which can only be positioned within a confined/specified geographical area because they are so called "Geo-Locked". If one tries to position such an object, e.g. via the Abacus EZ program, anywhere outside that geographical area, an error message is displayed and the objects concerned will/can not be positioned there.

This GeoLock program should be able to remove these Geo Locks or even to create new ones ..... BUT ...... it somehow does not seem to work, so I hope one of you experts out there has some more experience with this program and can point me to something I may be doing wrong.

In the GeoLock manual it states that one of the default FS9 BGL files (e.g. Orlando.bgl) has all it's scenery objects Geo-locked to that specific area and when the GeoLock program is (test-)pointed to this file it displays the geographically locked co-ordinates correctly for each scenery object, either in bulk or selectively. When these are then unlocked by pressing the "unlocked" button, the co-ordinates concerned disappear correctly and a new BGL file is created with the name: "Orlando-unlocked.BGL". The original "Orlando.BGL" file must then, for safety reasons be de-activated and be replaced by the new one in the same position.

However, when trying to re-position any of the objects from the new "Orlando-unlocked.BGL" file elswhere, e.g. via the Abacus EZ object placement program, an error message is displayed saying that the objects concerned are still locked in their original area. Shutting FS9 down and re-starting makes no difference.

HELP !! ------ Please.

Regards and thanks in advance for any ideas.

Hans

Any addon third party airport's visible ground scenery needs to be at exactly the same elevation as that of it's default airport in it's relevant APnnnnnn.bgl file, otherwise AI planes will either be (partially) parked under the visible addon ground level or will seem to be floating above it. This is because AI planes will always park on de default airport's elevation.

Ground elevation in it's related Afcad or ADE file must also be the same.

However, an overriding flatten for the whole airport area is the most simple solution but an elevation edit in the default APnnnnnn.bgl file is the better choice but only after the original has been saved to somewhere safe.

Regards

Hans

Bernard,

Thanks for your reply and explanation. I have now been able to solve my problem, firstly because of the file name you supplied and secondly because I was now able to replace the whole series from one of my very old backups.

Thanks again for your help.

Hans

mrichie

Very strange that a Win10 update can cause what look like alpha channel problems in certain texture files belonging to a non-internal Windows program like FS9.

In my experience such textures (with transparant black areas and alpha channels) can only have their transparancies messed up by programs, which re-define texture files in bulk, e.g. from one compression form to another.

Previous correctly rendered transparant black areas in those textures are in unpredictable cases then changed into other types of black, which can then no longer be rendered as transparant or have had their alpha channels removed. Hence, only some of your textures being rendered with non- or no longer alpha channeled black squares. Particularly notorious are partially alpha channeled textures which should render as, e.g. circular flood lighted apron areas at night.

However, in your case you seem to have resolved your problem anyway by reverting back to an earlier version of Win10 but to me it remains very strange indeed that ONLY this action resolved your texture problem. Anyway, all is well that ends well. and thats the main thing.

Happy landings.

Hans

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