1 (edited by pwalchester Yesterday 08:30:39)

Topic: CYVR taxi routes .xlf for airport by tdg

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


New version using latest rules for runway hold areas

Post's attachments

Attachment icon CYVR.xlf 29.89 kb, 5 downloads since 2018-01-15 

2

Re: 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?

3

Re: CYVR taxi routes .xlf for airport by tdg

rcbursey wrote:
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?

Just checked, can't see one.

4

Re: CYVR taxi routes .xlf for airport by tdg

pwalchester wrote:
rcbursey wrote:
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?

Just checked, can't see one.

This was the message:

Hello Phillip. I was wondering if you could help with a little confusion I have on the rules/instructions to create taxi routes for X-Life. Your manual dated 7/26/17 is a very good manual and I have been following its instruction to create taxi routes using the .xlf file format. My confusion comes from seeing some recent posts by Jar using the rule to follow a hold line with another hold line even if on part of the runway. There would be no confusion if there is only one line required from the hold point to the runway. Its when you have two lines required from the hold point to the RWY. Your instructions and the way I have been following shows to use a hold line followed by a line marked RWY if two lines are required. I recently created taxi routes for CYYC Calgary using the rwy after hold line rule. Airport worked fine but then I changed it to hold line after hold line which JAR says is the proper way to do it now. When I tested the airport, the AI aircraft were all holding unnecessarily at the hold points. There were NO aircraft approaching for them to be holding. When I changed it back to the way the manual says to do it, it worked fine again. NOW, I looked at your recently posted CYVR with tdg airport which I have installed. It appeared to work fine and then I noticed AI aircraft holding at points they didn't need to be holding for. So I changed the second hold line that were marked RWY to Hold lines and it seems to work that way. So wow, I am confused because  the airports that I created taxi routed for KBDL, KEWR, KLGA, and others seem to work fine using the rule followed by your manual. Has something recently changed where even your CYVR needs to be addressed? Any advise would be great appreciated. Maybe you could have a look at the airports I created and see test them?

Thanks Phillip. I will look forward to any of your thoughts

5

Re: CYVR taxi routes .xlf for airport by tdg

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

6

Re: CYVR taxi routes .xlf for airport by tdg

Hi Phillip. Thanks for this nice explanation and the sharing of your experience. Hope you having a fun retirement!!! I'm getting close. Now what about the rule of marking taxi as hold after initial hold vs mark rwy after initial hold. Are you in the us? Do you Skype?

7

Re: CYVR taxi routes .xlf for airport by tdg

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.

8 (edited by rcbursey 2018-01-14 00:30:39)

Re: CYVR taxi routes .xlf for airport by tdg

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.

9 (edited by cmckjodi 2018-01-14 00:56:49)

Re: CYVR taxi routes .xlf for airport by tdg

rcbursey wrote:
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.

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

10

Re: CYVR taxi routes .xlf for airport by tdg

cmckjodi wrote:
rcbursey wrote:
cmckjodi wrote:

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.

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.

11

Re: CYVR taxi routes .xlf for airport by tdg

rcbursey wrote:
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.

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

12

Re: CYVR taxi routes .xlf for airport by tdg

cmckjodi wrote:
rcbursey wrote:
cmckjodi wrote:

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.

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.

Post's attachments

Attachment icon _hold.jpg 219.04 kb, 1 downloads since 2018-01-14 

13

Re: CYVR taxi routes .xlf for airport by tdg

pwalchester wrote:
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.

Glad I raised the points about Hold Areas. Thanks for bringing this to JAR's attention!