Heads up on new AI separation utilities for P3Dv4

[Ray Proudfoot 8,955]

@Clipper Ocean Spray, I wonder if you could help with an Ai problem in P3Dv4 although v5 users would also be able to benefit from it.

I have used Radar Contact v4.3 for many years and consider it a fine ATC program. But occasionally it doesn’t prevent an Ai aircraft from taxiing onto your landing runway and consequently you’re instructed to go around.

I have tried zapping the offender using FSUIPC but the problem is he’s generally too far away before the call comes.

As you know each Ai has a status so I was wondering if you could read the status of any Ai assigned to depart on my runway and delete them if the status is TakeOff1. Ai are assigned that status when they begin taxiing onto the runway and it changes to TakeOff2 when they begin their takeoff run.

Would AiGround be a suitable vehicle for this?

[Clipper Ocean Spray 189]

23 hours ago, Ray Proudfoot said:

@Clipper Ocean Spray, I wonder if you could help with an Ai problem in P3Dv4 although v5 users would also be able to benefit from it.

I have used Radar Contact v4.3 for many years and consider it a fine ATC program. But occasionally it doesn’t prevent an Ai aircraft from taxiing onto your landing runway and consequently you’re instructed to go around.

I have tried zapping the offender using FSUIPC but the problem is he’s generally too far away before the call comes.

As you know each Ai has a status so I was wondering if you could read the status of any Ai assigned to depart on my runway and delete them if the status is TakeOff1. Ai are assigned that status when they begin taxiing onto the runway and it changes to TakeOff2 when they begin their takeoff run.

Would AiGround be a suitable vehicle for this?

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

Edited November 26, 2020 by Clipper Ocean Spray

[Ray Proudfoot 8,955]

Hi Roland,

I haven't included that parameter in the ini file but I will and test how efficiently it works. You said...

"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."

In Radar Contact take-off clearance is only given when the status of that aircraft changes to TakeOff2. Before that it changes from Taxi to TakeOff1 when the aircraft starts taxiing and moves onto the runway where that status can remain for some time depending on the quality of the AFD. Some Ai creep forward for a while before they spool up the engines and status changes to TakeOff2.

I'm not sure how far out I'd be at 1500ft. Given a descent rate of around 900fpm I'm guessing 1m 40s. That seems a reasonable time for an Ai with a status of TakeOff2 to get airborne.

Let me add that line and then see how things go. I'm sure you've tested this yourself and it works fine. Anything that reduces the chance of RC issuing a go-around would be welcome as it ruins an otherwise good critique.

Thanks!

[Clipper Ocean Spray 189]

3 hours ago, Ray Proudfoot said:

Hi Roland,

I haven't included that parameter in the ini file but I will and test how efficiently it works. You said...

"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."

In Radar Contact take-off clearance is only given when the status of that aircraft changes to TakeOff2. Before that it changes from Taxi to TakeOff1 when the aircraft starts taxiing and moves onto the runway where that status can remain for some time depending on the quality of the AFD. Some Ai creep forward for a while before they spool up the engines and status changes to TakeOff2.

I'm not sure how far out I'd be at 1500ft. Given a descent rate of around 900fpm I'm guessing 1m 40s. That seems a reasonable time for an Ai with a status of TakeOff2 to get airborne.

Let me add that line and then see how things go. I'm sure you've tested this yourself and it works fine. Anything that reduces the chance of RC issuing a go-around would be welcome as it ruins an otherwise good critique.

 

 

Thanks!

 

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.

 

 

 

 

 

 

 

 

Edited November 27, 2020 by Clipper Ocean Spray

[Ray Proudfoot 8,955]

Hi Roland,

I tried a flight between two busy airports - Atlanta and Miami. Unfortunately there were no Ai waiting to depart on my landing runway so I couldn’t test AiFlow.

I’m going to try again tomorrow and will arrive at a busy single runway airport - London Gatwick. Decent chance there’ll be waiting traffic there. I’ll search for ATCAPI too, thanks but I want to try without it first.

[fs1 295]

On 11/27/2020 at 5:11 PM, Ray Proudfoot said:

Hi Roland,

I tried a flight between two busy airports - Atlanta and Miami. Unfortunately there were no Ai waiting to depart on my landing runway so I couldn’t test AiFlow.

I’m going to try again tomorrow and will arrive at a busy single runway airport - London Gatwick. Decent chance there’ll be waiting traffic there. I’ll search for ATCAPI too, thanks but I want to try without it first.

Does this happen with the user aircraft?
AI that are landing prevent any other AI to enter the runway.

Thanks

Edited November 28, 2020 by fs1

[Ray Proudfoot 8,955]

2 hours ago, fs1 said:

Does this happen with the user aircraft?
AI that are landing prevent any other AI to enter the runway.

Thanks

I’ve never noticed an Ai taxi onto the runway with another inbound. Radar Contact handles that well.

I’ve only been using AiFlow for a couple of days. No problems landing at Gatwick today simply because there were no Ai waiting to depart.

[fs1 295]

I could add a flag in my addon to tell the AI to hold until you land.

If you are willing to test it, I can do that for you.

Edited November 29, 2020 by fs1

[Ray Proudfoot 8,955]

36 minutes ago, fs1 said:

I could add a flag in my addon to tell the AI to hold until you land.

If you are willing to test it, I can do that for you.

Hi Federico,

Sorry but which is your addon? I'm running AiGround and AiFlow. Do I need another? Somewhat frustratingly I've just landed at LIRF 34L with other landing aircraft using 34R and there were no aircraft waiting to depart from 34L.

[fs1 295]

I coded ATCAPI

I am trying to help with you solve what you commented here

 

Edited November 29, 2020 by fs1

[Ray Proudfoot 8,955]

Federico, ah, I see it’s an entirety different utility. I would prefer to continue with AiFlow for now until I can judge whether it is working as I wish.

Thanks.

[colinosullivan 1]

Hello all,

The first issue I would like to address is the amount of holding being created. It seems that there may be in error in the spacing between aircraft at times? Not entirely sure. Reference " Holds ". I do have a pretty massive amount of aircraft in my sim, so issuance of holds and updating them could be a problem, however it looks like they keep being put into them.

Secondly, reference " Holds 2" . In this image we can see an aircraft inbound to LAX going into a hold for no apparent reason. With this being said, my separation factor is 2 nm. 

Holds - Link to image https://photos.app.goo.gl/ze8thLB2CXVTptHRA

Holds 2 - Link to image https://photos.app.goo.gl/zG61LH4387TfGFt96

[chapstick 2,757]

I'm finding that at Orbx KBUR AI landing on RWY 08 will overrun the runway, blow through the perimeter fence, then taxi back to the terminal. I suspect it might be my AIGround settings. Has anyone seen this issue and have suggestions?

//AIPUSHBACKHOLDTIME=40
AIEXTENDEDPUSHBACK=1
//AINOCONTROLCHECK=0
AITAXISEPARATIONDISTANCE=150
//AIADVANCEDINCURSIONDETECTION=0
//AITAXILOCALDISTANCE=5.0
//AIMONITORRADIUS=55556
AILANDINGBRAKINGSCALAR=30.0 
AILANDINGTARGETTIME=20
//AILANDINGBRAKINGGAIN=3.0
AITAKEOFFTHRUSTDERATESCALAR=37
AITAKEOFFTARGETTIME=25
//AITAKEOFFTHRUSTDERATEGAIN=3.0
//AIPLANESPOTTINGONLY=0
INSIMMESSAGELEVEL=0
//STARTMINIMIZED=1
//INIPERIODICUPDATE=0

[Ray Proudfoot 8,955]

A week ago I took off from Rwy25 at Rome LIRF. As I was on the take-off roll I noticed an Ai suspended in mid air having taken off on 16R. As soon as my wheels left the ground he continued flying. Is there any advantage to this? We were never in any danger of a collision.

On another flight I was a couple of miles out from Rwy 04 at EHAM when an Ai taxied onto the runway and Radar Contact issued a GA. The visibility was poor so I had no chance of seeing him so I could zap him with FSUIPC.

Sadly there is no log created with AiFlow so it’s difficult to analyse what it’s doing. Any chance a log could be generated?

[colinosullivan 1]

On 12/10/2020 at 10:38 PM, Chapstick said:

I'm finding that at Orbx KBUR AI landing on RWY 08 will overrun the runway, blow through the perimeter fence, then taxi back to the terminal. I suspect it might be my AIGround settings. Has anyone seen this issue and have suggestions?

//AIPUSHBACKHOLDTIME=40
AIEXTENDEDPUSHBACK=1
//AINOCONTROLCHECK=0
AITAXISEPARATIONDISTANCE=150
//AIADVANCEDINCURSIONDETECTION=0
//AITAXILOCALDISTANCE=5.0
//AIMONITORRADIUS=55556
AILANDINGBRAKINGSCALAR=30.0 
AILANDINGTARGETTIME=20
//AILANDINGBRAKINGGAIN=3.0
AITAKEOFFTHRUSTDERATESCALAR=37
AITAKEOFFTARGETTIME=25
//AITAKEOFFTHRUSTDERATEGAIN=3.0
//AIPLANESPOTTINGONLY=0
INSIMMESSAGELEVEL=0
//STARTMINIMIZED=1
//INIPERIODICUPDATE=0

Hey Chapstick,

In hopes to diagnose my issues with the program, I spent a decent amount of time reading the manual.

Your "AILANDINGBRAKINGSCALAR" should be set to around 7 for optimal realism for braking on landing.

Additionally, "AITAKEOFFTHRUSTDERATESCALAR" should be the same value, 7, for realism. 

With that being said, I don't think "targettime" is quite needed as it just adds more for CPU to do.

This should help!