Clipper Ocean Spray

FYI, here's the non-default .ini file settings I'm currently using (may not work best with your preferences/setups however). AIFlow.ini AIANTIRUNWAYINCURSION=1 //view readme to understand what this does before enabling AIBADAPPROACHFILTER=1 //AIFlow can deal with AI injected too high and close, but why bother? Get rid of them from the get-go! AITERMINALAREAMINSPEED=170.0 //Get those turbo-props and GA moving INSIMMESSAGELEVEL=1 //prefer minimal feedback as to what program is doing INIPERIODICUPDATE=1 //prefer option to change settings and not restart AIFlow although doing so will not cause any problems AIGround.ini AIEXTENDEDPUSHBACK=1 //at the very least prefer AI pointed toward apron after pushback AILANDINGBRAKINGSCALAR=15.0 //good initial value if using landing target time below AILANDINGTARGETTIME=25 //probably between 20-25, GA and turbos will automatically be less, heavies more INSIMMESSAGELEVEL=1 //like minimal feedback as to what program is doing INIPERIODICUPDATE=1 //prefer option to change settings and not restart AIFlow although doing so will not cause any problems AICull.ini Currently using all defaults.

Hi Kael, I could do it, but (and I realize you've probably been asked this question before 😉), how is that a significant advantage over the option to just limit traffic to the departure and destination specified in your flight plan? For example, you're flight plan is EGLL-EGPH, that removes all the AI at London City, Gatwick and Stansted.

Agreed, v4.5 was so reliable for me in that respect, it is difficult to leave that behind. Currently have both 4.5 and 5 active, but not entirely happy about the extra expenses. Remember that bad old days of FSX, before the virtual address space limitation was fully understood, when FSX would just vanish to the desktop as your were approaching your destination after a long flight that you had meticulously set up? The empty feeling of never wanting to touch FSX again? v4.5 was the opposite of that in every way. As someone else said on the forum recently, when v4.5 stuttered a bit on final approach, you knew it was going to pull through and not let you down.

Some updates: AIFlow v1.1 HF3: https://www.mediafire.com/file/donrrkqljazpnn3/AIFlow_v110HF3.zip/file Added: (1) start minimized; (2) periodic read of .ini file to aid tuning/tweaking (can save changes and keep AIFlow running); (3) auto switch to external airport database (included in package) if simconnect bug reading internal database; (3) option to specify min. AI approach speeds in terminal area (good for slower AI or AI in a long-slow approach from distance). AIGround v1.1 HF3: https://www.mediafire.com/file/6phos9ju3vtte54/AIGround_v110HF3.zip/file Added (1) start minimized; (2) periodic read of .ini file to aid tuning/tweaking (can save changes and keep AIGround running); (3) option to specify target landing rollout time (by automatically changing braking scalar) yielding more consistent results for different AI sets used at same time. New Utility: AICull AICull v1.0 https://www.mediafire.com/file/d60ip7ktp28uxqh/AICull_v100.zip/file In-sim, multi-mode AI traffic limiter. Operates via P3D menu system located under the "Add-ons" menu. Provides options to limit AI traffic to the user's departure and destination airports (if flight plan loaded), the user's current airport or the closest 25, 50 or 75 AI to the user's aircraft. Exceptions can be made for enroute AI (e.g., higher than 10,000 or 18000 ft). AICull requires FSUIPC v5 or later (registered preferred).

My next revision lets the user specify a target landing ground roll time (adjusting the braking scalar dynamically to achieve it) for an average jet. Turbos and GA will automatically take less time and heavies perhaps a bit more. It seems to be working fairly well, with some natural variability in the actual ground roll times. A more-or-less constant ground-roll time mirrors reality IMO. Regardless of runway length (excluding exceptionally short runways), the roll is always going to be about the same, sort of a constant de-accel that is comfortable for the passengers, easy on the aircraft, but getting the aircraft to exit promptly. Davii, the other suggestions are good. My earlier AIController did some of those things, but it had to read the airport .bgl files to do it, which I want to avoid for these utils.

Wow, that sounds great! My current utils follow ATC, so if you can direct ATC to change takeoff/landing runway(s) and parking, that would be huge. Specifically, being able to change the AI landing runway(s) is one of the most frequent requests I get. My earlier AIController did it, but it wasn't compatible with default ATC. It would also be a huge help for the weather programs too.

I think there might be a bare bones way (simple and light) to do the first thing, I'll look into it. Re: the second, I'm adding an option to periodically read the .ini file, so if you're approaching an airport that you want to change spacing for, you can just change the value in the .ini and it will be automatically saved and applied. The other ideas are great and a lot of them I supported in my earlier AIController. The problem with that earlier effort was it broke compatibility with the default P3D ATC comm system plus it was a lot more complicated to setup.

Yes, there will absolutely be an option to start minimized next revision. The users have spoken loud and clear on that one. 🙂 Edit: re: second request, I'm finishing up a traffic limiter that will read the flight plan and limit traffic to those airports.

😉Now that we have a braking scalar, maybe it would be better to think of the adjustable parameter in terms of time, such as a target landing roll time regardless of AI set being used? Enter the target time (and also perhaps an initial scalar braking value) and the program adjusts the scalar on-the-fly to achieve the target time?

Thanks everyone for the comments and videos. Yes, the AILANDINGBRAKESCALAR scalar seems to have a non-linear effect as you increase it. Up until a lower threshold, it doesn't have much effect. Then, increasing it above the lower threshold starts increasing the landing roll significantly. The upper threshold is reached when the AI looks like it is trying to take off again. I would probably find an optimum value, then subtract about 3-5 from it. Each AI set (e.g., default v. FLAi) seems to work best with an individually tuned value, so you could populate the .ini like this to alternate sets: AILANDINGBRAKESCALAR=17 //FLAi //AILANDINGBRAKESCALAR=30 //UTL I'm working on a revision that switches to a backup, external database when the simconnect bug occurs. The switchover, when it does happen, increases the memory footprint of the program substantially and the CPU occupancy some, but it isn't too bad (I had been resisting it for those reasons and others). I'll throw in an option to prevent the switchover for those users who have good success finding the nearest airports using simconnect, so they can keep the program running lightly as possible.

I think about 20.0 is a good starting point. You can tell when the scalar is too high because the AI will give up trying to slow down and take off again. 😉 The best value does seem to vary between AI sets.

Latest revisions: AIGround v1.1 HF2: https://www.mediafire.com/file/d76p0tpovbmn6l5/AIGround_v110HF2.zip/file Added: (1) AI landing brake scalar to adjust AI landing rollout distances (optional). (2) AI extends push back by performing a tight, multi-point turn (to avoid other AI in crowded gate areas) and ends up facing opposite direction for a more orderly taxi roll (optional). (3) Added compatibility for remote execution via xml and add-on installation method. (4) Reduced in-sim message level for non-verbose settings (optional). AIFlow v1.1 HF2: https://www.mediafire.com/file/iaoousbtcvf33ar/AIFlow_v110HF2.zip/file Added: (1) Detects and corrects P3D AI bugs: (1) divebombing AI(s) injected too close to destination airport; (2) AI(s) detected to have controlled descended into terrain; and (3) AI flying impossibly slow. (2) Added compatibility for remote execution via xml and add-on installation method. Fixed and Improved: (1) Fixed AI anti-runway incursion option where sometimes landing AI would stop on runway. (2) Improved AI anti-runway incursion option to better prevent AI incursions into and AI stopping on runways while user's aircraft is taking off or landing. NOTE: this feature has also been changed to default OFF because it can cause unexpected AI movements if the user is unaware the feature is activated. (3) Fixed additional issues with an AI-AI pair sometimes getting locked into a holding pattern.

The AI do a fine job descending into terrain without my program 😉, the most recent hotfix catches the dive-bombers. I could do more to filter out the problem AI(s) out though, thanks for the suggestions. AI approaching the airport on the ground should be easy to detect and deal with as well as impossibly slow airborne AI. Re: user's current airport not being detected, that's a show stopper. The user should either take the steps I mentioned in the message to correct the issue in-sim (build and activate - not load - a direct IFR flight plan then cancel if not needed) or exit AIFlow. I probably need to make that more clear in the text message. I've notified LM about the simconnect bug that causes the issue.

Thanks, if that turns out to be the culprit, I should probably reduce the default AIMONITORRADIUS radius because it seems like this issue could repeat itself at other specific airports. Some airports have the opposite issue, the AI tends to get injected high and close to the destination airport, which sometimes causes P3D to make the AI go into a dive bomb (e.g., EGLL when AI landing west 27L & R). I actually had to add code to "catch" the dive bombing AI and stabilize it before it crashes into terrain. Also added the AIBADAPPROACHFILTER option.

Hi Devon, were the AI in hold (by AIFlow) when they disappeared? With an AI spacing of 10 nm, that might be causing a lot of hold activity. So one thought: This could be particular to YSSY based on the AI tending to get injected at the edge of the reality bubble and then getting put immediately into hold due to the high AIARRIVALSPACING value you're using. They then egress the reality bubble during a portion of their hold circle (made large due to high alt cruise speed) and get deleted by P3D. A possible solution: bump down AIARRIVALSPACING or if you want to keep that where that is, bump down AIMONITORRADIUS so AI are "more inside" the bubble before holding actions occur. The default AIMONITORRADIUS radius of 200000 meters (108 nm) extends to the edge of the bubble, so it can be reduced.

Sure, make sure AIANTIRUNWAYINCURSION=1 is in your .ini file. However, check out the readme for what it does because it can cause surprising actions in non-intended use cases. For example, if you're flying (or slewing) directly over the airport below 1500 ft AGL to observe ground and approach activity, the anti-incursion might be triggered for AI on the ground. Also don't taxi (or slew) on the ground over 40 mph if you have the option enabled.

P3D will still stop AI independently. One way to make sure AIGround isn't the one stopping the AI, flash your landing lights on and off, then AIGround will temporarily allow all AI that were stopped to proceed (if it was the program that stopped them). Re: AI deletion for lack of free parking spots, I think the other posters were referring to taxi out (departure) situations.

Please see my prior response to Rafal. This also seems like something is timing out the AI and deleting them. AIGround doesn't delete AI, but it does hold the AI longer after pushback, which might be counting against a timeout value. Have you used any utility that changed AI timeout values?

AIGround doesn't delete AI. Have you by chance used any other utility that changed the timeout settings (e.g., standing still) for the AI? Also, can you give me the simconnect version you are running (in a scenario, chose Help/About)? Thanks, Roland.

Yes, the default values are more geared to creating AI lined up like a string of lights at busy airports and medium/heavy traffic densities, but at the expense of an occasional go-around.

Hmm..AIGround doesn't affect rollout length. If the AI slowed down quickly and evacuated the runway, that is the default AI program. Was AIANTIRUNWAYINCURSION=0 in the .ini? I'll keep an eye out though for the behavior...an indication that AIGround is causing the issue would be the AI immediately stopping on the runway and getting stuck there, which is something AIGround should NOT be doing. I thought about addressing landing rollout length with AIFlow, but I probably need to read the runway nodes and links, which means reading airport bgls. My prior AIController did that, but it had a replacement AI movement system that included the ability to tune AI landing rollout distances. Thus, it was much more complicated in addition to not being compatible with the default P3D AI engine especially re: ATC communications.

It is in there in the latest beta I linked to on this thread: http://www.mediafire.com/file/n5gc9pwpug70fk2/AIFlow_v110HF1.zip/file To disable in-sim messages, make sure this is in the .ini file: InSimMessageLevel=0 If the messages keep popping out during a session, that might be the warning about a simconnect bug, where simconnect sometimes doesn't return airport info. in the user's current reality bubble. Those messages can't be turned off because that is a show stopper for AIFlow (not being able to determine the user's current airport), hence the periodic warning messages. To fix the issue in the sim when you do get those warning messages: BUILD (not load) and activate a P3D flight plan using your current ICAO as the "departure location." The flight plan can be a simple GPS direct IFR to any arbitrary destination. After activating the plan, the messages should stop and you'll get one message stating the correct ICAO was detected. At that point if you don't need the plan, you can clear it. I've notified LM about the simconnect bug, hopefully they'll eventually correct it.

Lol, nice video! It is the anti runway incursion option, which designed to prevent the default P3D AI engine from allowing AI to enter/cross the runway on takeoffs/landings. The intended use case here is final approach. 🙂 There's some more info. in the readme. I wasn't sure whether I should leave that feature on or off by default since the results can be surprising if you're not expecting it. To disable, add this to AIFlow.ini: AIAntiRunwayIncursion=0

It is left to the P3D AI engine decision, but the Airport Design Editor (ADE) will allow you to modify landing preferences at airports.

Here's are the links to a minor revision...adds capability to execute via xml method and the edge-case AI holding issue (AIFlow) that Vincent mentioned: https://www.mediafire.com/file/n5gc9pwpug70fk2/AIFlow_v110HF1.zip/file https://www.mediafire.com/file/63z47i50t4mdsh9/AIGround_v110HF1.zip/file