Clipper Ocean Spray

Thanks! Yes, generally if there is only a particular function(s) you want to use in AIGround or AIFlow (e.g., in order to let Federico's utility do the heavy lifting), the AIGround and AIFlow .ini file can be modified to turn everything else off.

Thanks! Good suggestion re: 90 deg turns. My prior AIController read the scenery .bgl files and knew the taxi routes out of the terminal area and thus could figure out the correct 90 deg. turn direction. However, AIGround is sort of a bare-bones version of AIController and doesn't read the scenery bgl files, thus the 180 deg turn to ensure the AI doesn't end up accidentally pointing into the corner of a terminal area after pushback. I might be able to figure out a way to reliably do 90 deg. turns without reading .bgl data though, I'll keep looking into it.

Seeing the same here with a different config: 3800x/570/3090/HP G2. The 457.30 is just a lot smoother than 461.33 on my setup.

Yep, especially g2 and AMD X570 motherboards. The problems the OP describe are very similar to the problems I've been experiencing with my X570 board and the g2. I was able to reduce the symptoms significantly by using an unpowered USB hub and finding a port that worked best, which makes me think the problem is some type of timing/impedance issue that the X570 USB drivers can't handle due to the G2's long cord. Hopefully a driver update will come out soon. At least HP is acknowledging it.

I also have a G2 and 3090 and P3D VR "pre-render" is jittery. When I use the "update" option, it is very smooth. How did you get pre-render working smoothly? I'm curious because I always got better results with pre-render on my old Rift headset.

Could someone explain to a WMR newb how to view this particular setting? Specifically, it seems I can only view this setting in "HMD only in a 3D environment," but I don't understand what that means. Thanks!

An AI is put on hold based on an estimate of how close the AI is to another AI arriving for the same runway, not AI immediately ahead/behind. In other words, an AI approaching from the north 20 nm out may be put on hold for an AI approaching from the south 20 nm out because they are both calculated to arrive at the runway within the separation distance and even though they are currently 40 nm apart. Having said that, the distance calculation are estimates only especially since they have to take into account the predicted flight path. Additionally, if an AI on short final has to hold, all AI queued up have to hold in order to prevent an AI go-around bug. Finally, if you're running high AI densities, I would recommend a max no. of holders in the config file because a high number of holders tends to beget more holders. With a max number of holders, excessive holders (tending to happen in the first arrival wave after a situation is loaded) will egress will egress the reality bubble, but you should still get a pretty busy and organized landing flow. No advantage. Thanks for identifying that, I need to tweak the logic so it doesn't impact AI in takeoff2 but airborne. Perhpas 1500 ft agl is too low of a trigger alt. I should probably revisit that value and/or add a parameter to the config file to customize. OK, will keep an eye on this. About to upgrade to 5.1 now that VR seems to be sorted out for my setup. If I do experience this, shouldn't be hard to trouble shoot as AICull is doing very little when not executing a cull.

I wonder how well the half resolution mode of the Reverb G2 will work in MSFS? I know it isn't ideal for instrument clarity, but if G2 half resolution is better than Rift S for example and the frames are much better, I can hold onto my 1070ti until the 3080ti is widely available. That's the card I really want.

Sounds good, I put the parameter in the AIFlow utility because the landing trigger occurs when the user's aircraft is mostly in the air (or for a short time on the landing ground roll). However, because the effect of the parameter is ground operations, it is sort of confusing that the parameter is not found in AIGround and makes it easy to miss. The parameter does key off TakeOff1 and 2 values. The 1500 ft and 750 ft AGL triggers could be tweaked up in a revision, just picked them because they are easy to remember and seemed reasonable during testing. I would give Federico's ATC and Airport Operations (ATCAPI) utility a try too has it does a nice job speeding up takeoff flow on busy runways, which would reduce the overall chances of running into a Takeoff1/2 issue. It has a specific option to reduce the time the AI is loitering in Takeoff1 (EnableFastTakeOff ), which would help regardless of whether the runway has a lot of activity or not.

I was having the same types of crashes, but the latest update seems to have fixed it for me. It really looks good and is an awesome improvement to traffic flow at busy airports. To echo what others have said, it would be great to add multiple airports. I haven't fully looked into it yet, but your utility also seems compatible with AIFlow and AIGround. I did see another post re: the AIGround utility ground roll possibly interfering with ATCAPI, but that ground roll aspect of the AIGround utility can be turned off if necessary by making sure this is in the AIGround.ini file: AILANDINGBRAKINGSCALAR=1.0 AILANDINGTARGETTIME=0 Regards, Roland

Hi Ray, there's a mode in AIFlow that's supposed to prevent ground incursions like you describe occasionally caused by the default P3D AI program. Add AIANTIRUNWAYINCURSION=1 to the AIFlow.ini file. Here is what it is supposed to do: Sometimes the default P3D AI control program will allow AI to enter and cross the runway even though the user has just been given clearance to takeoff or land. During the takeoff roll with landing lights on and at speed > 40 kts, AIFlow will detect in a narrow path extending to about 1 nm ahead of the user’s aircraft (i.e., runway) in order to detect AI that have entered and are crossing the runway. When detected, the AI will be forced to quickly evacuate the runway. During approach, when the user is below 1500 Ō AGL, all AI will be frozen at the destination airport except AI that has already been given takeoff clearance or AI taxiing in. Thus, the user is responsible for avoiding AI already on the takeoff roll or landing. However, no additional AI will be allowed to takeoff. Below 750 ft AGL including the ground roll at speeds > 40 kts, AIFlow will detect any AI crossing the runway and force the AI to evacuate quickly. Would this suit your purposes? Regards, Roland

Looks great, can't wait to test it out this weekend. Thanks!!

Yes, it does depend on the particular AI set you are using. I'm using AIG and these are my non-default settings in AIGround.ini (although best values are subjective and frankly I haven't spent a lot of time tweaking them): AIEXTENDEDPUSHBACK=1 AILANDINGBRAKINGSCALAR=30.0 //start with 15.0 if using AILANDINGTARGETTIME AILANDINGTARGETTIME=20.0 AITAKEOFFTHRUSTDERATESCALAR=37.0 //start with 15.0 is using AITAKEOFFTARGETTIME AITAKEOFFTARGETTIME=25.0 INSIMMESSAGELEVEL=1 The following two values are useful while actively tweaking, but you will probably want to ensure they are removed when finished. INIPERIODICUPDATE=1 (any changes you make to values are immediately applied during the sim session, but causes extra file I/O) AIPLANESPOTTINGONLY=1 (prevents the user aircraft from inadvertently interfering with AI operations, but disables user-AI taxi separation).

I think I know what is causing it (commanding AI to hold at a lower altitude than it is assigned presently), I'll improve it next iteration. No, my earlier AIController did that, but AIFlow is a bare bones version of AIController that maintains compatibility with the default P3D AI program (e.g., doesn't change the landing runways chosen by the AI program). Federico Sucari is working on an exciting utility that will do that though.. Thanks, definitely!

Thanks for trying. It was a disappointment for me in alpha testing, sometimes you don't realize how much you miss something (smoothly panning views on the hat switch) until it is gone. I went so far as to connect an xbox controller just for the smoothly panning views on its hat switch, but it was just too clumsy having a second controller to mess around with constantly (changing views) while flying. I think I'm going to wait for VR support so I can for the most part bypass this panning issue (and the lack of FSX-like optional key binding profile).