data63

word not allowed... missed that - thanks for pointing me to it

Hi and thanks for that great tool! a great addition would be the possibility to specify the type/weight of aircraft taking off or landing on a specific runway so you could assign the really long ones for heavies (A330 / B777 and above) and having the smaller ones use shorter runways for better distribution. the FS makes a break between heavy an "not so heavy" somewhere between A320/B737 and A321/B757 using 2.500meters and above for the heavies which is rather short ,-) regards jp

first let me thank you for that great addition - it's beautiful to see a triple7 taxi over the highway at EDDF. Nevertheless there seems to be a problem with some airports where the ai.dll "smashes" AI planes in approach to the ground (often spoilers suddenly deployed and aircraft going down like a stone) I could find this at EGLC (UK2000) and KDCA (DD) (with ai.dll active 60% crash on app - with ai.dll inactive 0%) - it seems to affect airports with short (< 2000m?) runways and "light" AI aircraft (A320 and below) - aircraft without spoilers seem not to be affected maybe an approach over water contributes. Would be great if the dev could look into that! happy landings jp

leave away the last "scenery" in the path - every Scenery folder is supposed to have a "scenery" and (mostly) a "texture" folder inside, so that "scenery" is implicit

It's not a seperate program but a funktion in the AIMonitor (menu -> Settings -> 2. Force Update of Runway and Taxi Data) sorry to have been unclear :blink:

did you run the scenery updater program to gather all the AFCAD and AI aircraft data? which ai aircraft do you use? (some older FS9 aircraft models use some "not so perfect" flight dynamics

I've some problems with ground movement: 1.) sometime AI traffic moves to the opposite rwy that is displayed in AI Monitor (e.g. EGLL display 9R (right rwy according to wind) - traffic movement 27L) 2.) Traffic stops in some place on the Apron (mostly short after Pushback) - AI Monitor displaying "Taxi Out Stop Queued for Takeoff Clearance" 3.) Traffic stops some distance before Hold Short and wait forever (until deleted) as "Taxi Out Stop at Hold Short Waitng for Takeoff Clearance" 4.) any change in config resets the UT2Compatibility to "0" AIC 2.0A HF1, FSX-SE, UT2, AIC in remote config, STB with all "Flight Control" options disabled, All setting default except UT, Observing as slewed "default trike", "Starting Positions" NOT on rwy but at Hold Shorts

afaik it is used for calculating parking positions, also some of the performance data are used. which paths do you use for your AI-planes ?

...but you know, that 36 (no R / L present) is not used for takeoff or landing either - only 18 is used and only for takeoff

i think it's about to copy/paste the content of the Sample.cfg (inside the SidStarConverter directory) into the AIController.ini

have a look at page 67 / post #1004

awful silence here.... I hope everything is ok!

looks very promising! if you need someone testing ground movement....

I don't think so as the traffic files (bgl) rely on scenery data such as afcad bgls as a "target" - those txt files for AIC are just a readout from these BGL's to control the movement in the SID / STAR phase. otherwise AIC would be a complete replacement for the engine controlling AI in FSX

did you run point 2 from the ai-monitor "settings" menu - without it AIC is pretty lost with handling aircraft as it hasn't read the data (radius, parkling code, ...) from AFCADs AND aircraft.cfg

just disable the "advanced" features

not 100% shure but I think you go to Settings / Options / Enhanced Mode (Approach and Final) and set the Enhanced Approach Mode to 0

that's the time the AI plane needs to calculate it's way to the gate. You could disable the taxi in feature leaving that to FSX which is slightly faster (and using some "strange" routings as it only takes the shortest way)

it is (for now) as AIC "slews" the landing AC to control them. The dev is working on a new version which should take care of this

take a look into the AIControllerPath.txt - find the "SPath" entry for KJFK and check if it is the FSDT one, then check the TAXI=KJFK entry if it is the right bgl. FSDT has a seperate BGL for the Approaches - maybe AIController confuses it for the "real" AFCAD. If you are going to use AIC you could disable this file as AIC would use it's own Appoach Info

maybe you're not doin' anything wrong :wink: - I'm not 100% sure, but I think ASN creates a weather "bubble" around the user aircraft and not for the whole FSX world. Therefore AI traffic doesn't recognize this weather und acts according to some FSX defaults. As AI traffic reads the weather the moment the flight becomes active AI traffic begins with the default (no) weather as ASN needs some time to "inject" its weather. Reloading the Scenery after the weather is injected (or restarting the AI traffic if you use UT2) may help

with the current version AIC - afaik - controls arriving traffic including STARS and APP, departing traffic is only controlled after takeoff entering a SID - so I suppose for departing traffic a crosswind config would be needed. But it looks as Roland is working on a new version which is also able to hande departing traffic, so let's wait what features he has in store

Hi! 1) 1.4a is obsolete - I don't think it's wise to use it 2) This behaviour is due to the way AIC handles the traffic - for now departing traffic is handled by FSX up to the point where it enter s a SID (I think it's when the state is changing from "takeoff 2" to the next state, arriving traffic is handled by AIC and FSX can't "see" it. This will be - as I understand - one of the major changes in the next version Raland plans.

it's not a complete mess - they use some "dirty tricks" to optimize the AI-flow (e.g. preventing backtracking as a landing AI-plane look for the "next exit") as nearly everything in FSX this has it's downsides. Also the "quick crossings" ar often used to prevent AI-planes stacking up at RWY crossings on an airport high a high traffic load waiting either because auf landing or because of incomming traffic. If Roland really gets his next version to handle incomming AND outgoing traffic on the ground many of those "dirty tricks" will not longer be needed. (.... but you are also right - LatinVFR is sometimes a bit "sloppy" with it's AFCAD :wink: )

'cause of the way AIC controlls the Ai aircraft in the current version there are some problems with departing traffic (controlled by FSX) and arriving traffic (controlled by AIC) not "seeing" each other but the author is thinking about reworking that so that it will be no longer a problem in V1.5. ...and when I look into his efforts and way of solving problems I'm quite shute he succeed