Clipper Ocean Spray

The easiest thing would be just don't use AIGround. Just make sure you do not use forced landing mode in AIFlow either. If you really want to use AIGround, you can control AI max taxi speed using AIMaxTaxiSpeed (=0 is disabled, i.e., MSFS default speeds). You can slow down the speed of the AI on the runways (after landing) using AITaxiSpeedOnRunwayAfterLanding. You can turn off fast runway vacate using AITaxiFastVacate (=0 is disabled). Taxi parameters can further be tweaked in the Secondary Landing Rollout Parameters section. I don't think AIGround/AIFlow is compatible with FSHUD simply because they are both modifying the default MSFS AI traffic control program to do what each program needs to do.

Just increase the AILandingTargetTime in the .AIGround.ini file or you can simply disable it (=0). It is set at a low default value to get the AI to vacate the runway more quickly and reduce go-arounds. However, fi you are using AIFlow's forced landing mode (landing runway selection and no go-arounds), you need a non-zero AILandingTargetTime and you need to have AIGround running at the same time as AIFlow. In my next versions I am seriously thinking about having every feature disabled by default. I don't understand how, even if someone didn't read any of the documentation, they used the program, noticed the AI was stopping more quickly, and then didn't notice this default parameter entry in the AIGround.ini file: AILandingTargetTime=5 //sec (disable =0)(ON & LOW val e.g. 8 IF using AIFlow Forced Ldg) If I download a program controlled by a .ini file, I am expecting that I will at least have to open up that .ini file and figure a few things out.

If you really want to bring AIFlow and AIGround into it, did you even try AIFlow's AIForceLandingSupressRecip=1 ? That should stop planes taking off in the opposite direction. AIPlaneSpottingOnly=0 (turning ON user-AI separation) will prevent AI overtaking you on final. You can increase AIArrivalSpacing if there is really an arrival spacing problem at your traffic density. Also, if the live weather and runways selected by the MSFS AI program are not satisfactory, you can specify the landing runways using AIFlow's forced landing feature and the departure runways using AGround's forced taxi-out feature. I can assure you, there will be NO go arounds whatsoever. There are other mitigating steps you can take, but it requires a willingness to open an .ini file and read the documentation, so not for everyone I realize. I agree with other posters that the root cause here is the long running omission by MSFS to provide even basic controls over AI operations (like selecting runway operations, turning go-arounds on or off). It you want to slag off on someone, choose that rather than freeware authors who are trying to mitigate it. Did you try PSXT?

Yes, definitely so. 🙂 Also, AIFlow (and AIGround) is a suite of packaged utilities that can be individually turned on/off. For example, if you only like the user aircraft-AI separation feature in AIFlow, everything else can be turned off including AI-AI separation although it takes some digging through AIFlow.ini, which isn't the most user-friendly.

That's an AIFlow force landing mode, which are default off. I think with FSLTL separation, there should be less go arounds and thus less need for force landing mode unless you want to use a custom approach (KDCA river visual 19) or something. Re: stair-stepping, yes, I need to revisit that as I found a better method working on AIGround that can be rolled into AIFlow. Re: selecting departure runways, that's AIGround and it is in an initial, very rudimentary phase and it doesn't support heavy traffic densities that well. Sort of like a "plan B" ATM if, for example, MSFS is stuck on making poor departure runway choices at at your dep/arrival airports based on live weather.

It is also possible to leave separation on in FSLTL and turn if off in AIFlow. In the AIFlow.ini : AIArrivalSpacing=0 AITerminalAreaMinSpeed=0 //this is also used to enforce a speed range in the pattern even if AIArrivalSpacing=0, so make sure to turn this off too as it will affect FSLTL's spacing. AITerminalAreaMaxSpeed=0 //this is also used to enforce a speed range in the pattern even if AIArrivalSpacing=0, so make sure to turn this off too as it will affect FSLTL's spacing. I would also probably avoid any AIFlow forced landing modes, which shouldn't be that big of an issue because FSLTL separation will minimize go-arounds.

AITakeoffTargetTime=0 to disable AI takeoff target time. AILandingTargetTime=0 to disable AI landing target time. If you do want to use the target times, there is an AIHeavyRollOutExtraTime value to add extra time for AI "heavy" rolls.

Yes, fixed! I checked my Bitdefender logs and Bitdefender had quarantined FenixSim A320\deps\FenixCDU.exe without me noticing. I removed/reinstalled Fenix and added a Bitdefender exception to the FenixSim A20 directory. Thanks for your help.

No, I have it too. I'll submit a ticket sometime this morning after some more troubleshooting.

BTW, here is how to turn everything off except the custom high alt cruise speed profile (I don't care what features of the utility are used, all the options were written to be capable of being individually turned off). I've only indicated the changes from default values below. Be sure that there are no leading // which causes the parameter to be commented out. AIARRIVALSPACING=0 //turns off all AI-AI spacing (holding and speed control for spacing) AITERMINALAREAMINSPEED=0 //turns off AI min speed in terminal area AITERMINALAREAMAXSPEED=0 //turns off AI max speed in terminal area AIBADAPPROACHFILTER=0 //turns off AI bad approach mitigations AIFORCEFINALAPPRALT=0 //turns off force AI to final approach alt AITURBULENCESCALAR=0 //turns off AI final approach landing effects AIGOAROUNDLEAVEAREA=0 //turns off handling of AI going around (allows loitering) Also, be sure keep AIPLANESPOTTINGONLY=1 (default value) so that all user-AI separation and anti-runway incursion features are also turned off.

Should be clear from a cursory review of the readme. AIBadApproachFilter=0 AIForceFinalApprAlt= 0 The user can certainly chose to have the AI approach the airport too high (AIBadApproachFilter = 0) and turn onto final too high (AIForceFinalApprAlt = 0) per the default MSFS AI program of that is what they want. Just have to read just a bit . . . .

Not 100% sure yet (need to test more airports), but I was seeing landings at Iniscene KLAX using FSLTL, AIFlow and AIGround. There is that STAR selection thing that delays landings generally.

Are you plane spotting by flying/slewing your aircraft around an airport in close proximity with departing AI while having user-AI separation ENABLED (AIPlaneSpoƫtingOnly=0)? If so, the AI is evading the user aircraft when the user flies within the UserAISeparationDistance of the AI. Below 5000 ft agl, holds, above emergency ascents/descents.

Reading a couple of reports that DX12 + G2 yields performance improvements (possibly including using DLSS) with none of the artifacts that MSFS warned about Is anyone seeing the same? I'm hesitant to join the beta because it partially breaks the OpenXR Tool Kit, but good VR DX12 results plus the other VR improvements could be worth the price of admission. 😉

Flying on Vatsim with a full compliment of controllers from departure to arrival is Vatsim (and MSFS) at its best IMO, but I want to put in a good word for Vatsim unicom flying. I've been in many situations where the pilots communicate with each other to "pseudo" control the airspace and they can do a decent job of it, even to the point we can get a string of lights set up on final approach. That aspect can be challenging and a lot of fun and is probably similar to flying into/out of busy, uncontrolled airfields IRL. Even at times when pilot activity itself is light in an area you're flying through, well...a live Vatsim pilot is worth 10+ AI pilots IMO (and I have a lot of experience programing AI pilots).