CYVR taxi routes .xlf for airport by tdg

pwalchester wrote:

Taxi routes for CYVR Vancouver International by tdg

Place in X-Plane 11/Resources/plugins/X-Life/Airports folder

This is for no static version of airport, nostatic file from http://jardesign.org/forum/viewtopic.php?id=1992

Phillip did you get my private message?

Hello rcbursey,

Not sure why the PM failed, I checked my Email address which is set to hide but allow Email, maybe a problem with JAR's server.
You seem to be describing a common limitation with larger multi-runway airports, that being X-Life AI locks unconnected runways into busy mode when in real life they would remain free for taxiing traffic. You can monitor this with the Tower View window active. There are some methods we can use in the editor to help smooth traffic flow but at the moment this is a limitation we have to live with. At this particular airport traffic using 8L/26R also switches 13/31 to busy. Arriving aircraft on 8R/26L correctly switches 13/31 to busy. Departing aircraft from 31 locks all runways to busy, etc.
Your query has made me revisit this airport and has thrown up one or two problems which I missed originally, I didn't spend much time debugging CYVR for various reasons, I was more involved with X-Life 2.1 beta testing, the .xlf was produced with 2.1b5 which has the effect of slowing down my system, not in any way a high end PC. Another current problem with 2.1 is now real schedules are used it is difficult to select and view the taxi routes of individual aircraft in the Settings Panel window which hampers debugging.
Anyway, I have reverted to the stock win.xpl for flying, editing and debugging and I have made changes to CYVR.xlf.
1- Although there is a GA 8/26 runway I have reverted this to taxiway A, because it is not activated in the airport file, aircraft landing on 8R/26L and 13/31 were taxing over grass to junctions A,A4 and A,A6
2- I don't normally tend to use short runway spurs down the length of runways, if a landing plane happens to be routed to one it will head towards the end of the spur before it should. I have deleted these, the crossing spurs on high speed runoffs have been left because the are within the bounds of the runway. Spurs at the ends of runways are less of a problem because arriving aircraft often don't use the full runway length.
3- Some arriving aircraft were taxiing through the GA area via taxiways A,F so a short segment of A has been made one way to prevent this, although this may impact aircraft needing to get to the GA area.

A few of the little tricks we can use to try and improve the experience.

You didn't mention the settings you are using, I tend to keep mine on the low side. Air Traffic Density 50%, Gates busy 30%. We are plagued with functionality v realism, swings and roundabouts.

Hope this helps, any further questions just ask, I'm retired and have plenty of time when my wife and dog allow.

Regards, Phil

cmckjodi wrote:

pwalchester wrote:

Hello rcbursey,

Not sure why the PM failed, I checked my Email address which is set to hide but allow Email, maybe a problem with JAR's server.
You seem to be describing a common limitation with larger multi-runway airports, that being X-Life AI locks unconnected runways into busy mode when in real life they would remain free for taxiing traffic. You can monitor this with the Tower View window active. There are some methods we can use in the editor to help smooth traffic flow but at the moment this is a limitation we have to live with. At this particular airport traffic using 8L/26R also switches 13/31 to busy. Arriving aircraft on 8R/26L correctly switches 13/31 to busy. Departing aircraft from 31 locks all runways to busy, etc.
Your query has made me revisit this airport and has thrown up one or two problems which I missed originally, I didn't spend much time debugging CYVR for various reasons, I was more involved with X-Life 2.1 beta testing, the .xlf was produced with 2.1b5 which has the effect of slowing down my system, not in any way a high end PC. Another current problem with 2.1 is now real schedules are used it is difficult to select and view the taxi routes of individual aircraft in the Settings Panel window which hampers debugging.
Anyway, I have reverted to the stock win.xpl for flying, editing and debugging and I have made changes to CYVR.xlf.
1- Although there is a GA 8/26 runway I have reverted this to taxiway A, because it is not activated in the airport file, aircraft landing on 8R/26L and 13/31 were taxing over grass to junctions A,A4 and A,A6
2- I don't normally tend to use short runway spurs down the length of runways, if a landing plane happens to be routed to one it will head towards the end of the spur before it should. I have deleted these, the crossing spurs on high speed runoffs have been left because the are within the bounds of the runway. Spurs at the ends of runways are less of a problem because arriving aircraft often don't use the full runway length.
3- Some arriving aircraft were taxiing through the GA area via taxiways A,F so a short segment of A has been made one way to prevent this, although this may impact aircraft needing to get to the GA area.

A few of the little tricks we can use to try and improve the experience.

You didn't mention the settings you are using, I tend to keep mine on the low side. Air Traffic Density 50%, Gates busy 30%. We are plagued with functionality v realism, swings and roundabouts.

Hope this helps, any further questions just ask, I'm retired and have plenty of time when my wife and dog allow.

Regards, Phil

What find very interesting is your non use of "Hold Areas" before Runways in your recent CYVR xlf that I downloaded. I seem to have been using the Hold Area function incorrectly placing Hold Areas (Orange lines) before Runways and Runway (Red lines) on off ramps. This has caused AI jam ups in my xlf layouts with planes not moving although runways are clear of traffic. By not marking any Taxiways as Hold Areas and just marking as Taxiways (Purple) and as Runways (Red) I have no AI traffic jam ups with planes still holding for a busy runways when needed. The Editor manual describes the use of Hold Areas, but that method described has not worked in my layouts. Not using Hold Areas seems to make a big difference keeping traffic moving. I have watched activity at CYVR for an hour now with no traffic jams up with my density and gates sliders maxed.

This is what I mean. When I communicated with JAR on this and he said the new proper method of hold areas is to mark taxiway from hold marker to runway as hold line even if require two lines from hold marker. So the only lines to be marked as rwy would appear to be when they are completely on the rwy.

cmckjodi wrote:

rcbursey wrote:

This is what I mean. When I communicated with JAR on this and he said the new proper method of hold areas is to mark taxiway from hold marker to runway as hold line even if require two lines from hold marker. So the only lines to be marked as rwy would appear to be when they are completely on the rwy.

Whatever the case may be what I find is that if I mark a Purple taxiway to a Red Runway or Runway on/off ramp from a Hold line on the pavement, the AI will hold properly and not freeze up when busy Runways are clear of traffic. No Orange Hold area lines are used. So the Editor manual now itself needs to be edited if this new marking protocol indeed works for everybody using the newest beta 2.7 and forward

Interesting. Would be interesting to hear what JAR says.

cmckjodi wrote:

rcbursey wrote:

Interesting. Would be interesting to hear what JAR says.

I have to keep testing this with different airports, but so far so good! No AI freezing

Hi guys,

This morning (UK time) I fired the question off to Eugeny, his answer is:-
If we use WED - use old rules.
If we use instant visual Airport Editor - we should mark lines as Hold area from Hold point to Runway point (please look at attached screenshot)

He's also asked me to update the manual to reflect this.