Anti-Pushback Node Technique in ADEX?

[ejwells409]

Quite by accident I came across a post by John Young concerning his "anti-pushback" technique for getting aircraft to taxi straight out rather than the unrealistic pushback for Military Jets. I tried it in ADE (his post referenced the old Lee Swordy AFCAD program I believe) and found that a few aspects he spoke about didn't directly show in ADE. I tried it and initially found that it worked on a few AI I used as a test, however when I did the remaining parking spots (about 18 in all) they reverted back to the old pushback and I haven't been able to get it working again since.

Below are a few shots of the entire layout and a closeup of the Jets ramp (F-100's) and how I have the taxiways laid out. I know there will be a lot of questions so ask away and I'll explain how I got to this point.

ADEX images-2022-oct-16-003 by Ed Wells, on Flickr

ADEX images-2022-oct-16-001 by Ed Wells, on Flickr

[John Young]

You need to disconnect the rear (green) parking links. You can still draw them, but make sure they are not connected to the centre spots.

John

[ejwells409]

Thanks John, however if I redraw them they automatically snap to the center spot and if I leave them out how do the AI Jets locate the parking spots?

[TimC340]

Draw your link outside the spot, then drag it to where you want it.

The AI engine will not reliably respect the red 'closed' links. If they make a shorter route than the blue or green paths, then the AI engine will say 'you made it, I'll use it'. So the only way to ensure they aren't used is to make sure they don't make a connection.

To Illustrate:



In this picture, the bottom two parking spots have been connected. AI parked on them will pushback - whichever direction they are parked. However, they will only spawn facing the way the parking spot is oriented. The top spot has been drawn with the link not connected. The node (the blue spot) can now be dragged to where you want it...



Note that in this layout, the AI will never use the link to the rear of the parking spots as it will always mean a longer route to or from any runway, so the links are redundant apart from the purpose of drawing a centreline. They can thus be drawn as 'closed' links if you want to make it clear that they won't be used. In P3D, they can be drawn with no visible surface, just like the green 'paths', if that helps.



The 'anti-pushback' node is a kind of cheat, as the pushback length is determined by the length of the segment to the first node after the parking spot, and so making that segment as short as possible does the same for the pushback - you may still notice a slight movement, however.

[ejwells409]

Thanks for the explanation John, and a "cheat" is fine with me rather than doing "outgoing and incoming plumbing". I found a 9 page tutorial on that subject and read about 3 pages before my head started to hurt. . .so thank you!

[TimC340]

Ah, Don Grovestine’s treatise on plumbing! Yes, it’s a stiff read, but it’s a very good guide. If you’re interested in the theory of the MS AI engine, seek out Jim Vile’s contributions on FSDeveloper. Jim and Don have both left us now, but their legacies are a library of great info (and apps, in Don’s case).

[hgschnell]

Ah, Don Grovestine’s treatise on plumbing! Yes, it’s a stiff read, but it’s a very good guide. If you’re interested in the theory of the MS AI engine, seek out Jim Vile’s contributions on FSDeveloper. Jim and Don have both left us now, but their legacies are a library of great info (and apps, in Don’s case).

How right you are!

Don has realized the plumbing here:

http://stuff4fs.com/newpage.asp?Folder=CYYJ

[mage]

The first plumbing AFCAD I met was from Mike Strasser in 2004, for Milan Linate, and several people including me gave it a good examination to see what made it tick. When I saw what it was doing, I gave it the "plumbing" analogy and the term stuck (I'd had the house heating upgraded the previous year!). This was 2004, back in the heady days of Project AI when I was known as Ministry of Truth and later developed some sceneries etc as "Matthew Ministry" for want of a better name. About 4 people were going over this, including someone that went on to develop for UK2000s AFDs, which is the reason behind the popularity of that system with those sceneries. The effort spawned other ideas such as allowing arrivals to cross another runway that later became known as the diamond crossing technique, which doesn't actually need a diamond since the main principle is to provide a link that bypasses the hold short nodes on each side of an inner runway, which isn't rocket surgery . None of any of this would have happened without Lee Swordy, of course.

Mike Strasser applied a few tricks to try to improve the design, but the underlying principle is actually quite simple once the rules set (by FS2004, when the idea came into being) have been figured out. It turned out that the tricks were not necessary in most cases. So, as far as I can tell, Mike originated the idea.

Don G shot me a couple questions after the dust had settled, after which he went on to use it very nicely in YYJ. We last talked shortly before his death, about my 52-week planner for which I was trying to implement timezone (& rudimentary curfew) awareness for transoceanic flights, and he more than "repaid the account" with his advice - a true devotee.

Plumbing basics +++

AI is either leaving a spot to depart, or arriving at a spot after landing.

With the "plumbing method" the focus is not the parking spot, but the runway. That's the place where the AI first engages with and finally exits the taxiway system. You "capture" the arrival as it rolls out along the runway.

Water comes into the pipes, water goes out. The runway is the boiler! It's a two-pipe solution and each parking spot is a radiator. https://www.buildingservicesindex.co.uk ... ng-system/

On arrival, AI will take the first suitable runway exit. On departure, AI will always use the runway link that gives them the longest possible takeoff run. Knowing this, you have a means to influence AI behavior on the ground.

Therefore all intermediate (runway exit and intersection) links should arrive at the rear side of any drive-thru gates, and the "front" end of all drive-thru parking spots should link only to the very end of the runway's black links. That's the overarching principle. The details vary for every airport.

-----------------------------------------------

On shorter runways, where some AI might run right to the end, it can still be possible to capture the arrival by creating a few off-links before the one at the very end of the runway, hoping to snag the AI into the system that leads to the rear of the parking spots. A lot depends on which hold-short node they first encounter. Hold-short nodes intended for use by arrivals can be placed further away from the runway edges than those for takeoff - even outside the "hold-short limit" of about 220ft. You'll get warnings about this from AFCAD or ADE error checking, but you can ignore the warnings for anything except a hold-short that will be used by departures (it's only within 220-ish feet of the runway that the departure options in the ATC window become visible to UI - and AI - aircraft. Without these there cannot be a call for departure and AI will get stuck while we can simply edge forward until they appear). This means that you can physically separate hold-short nodes in the layout to make certain that arrivals don't switch over to the departure side of the plumbing system because the AI "sees" that node first. It will drive right past a hold-short node for another taxiway (the diamond crossing technique also proves this), but if 2 hold-shorts are close enough to both be within the AI radius, the AI seems to have the use of either of them. Thus it might "jump tracks" to the outbound system or to an overlay if one is present.

AI is "sensing" what is around them at certain moments. They are looking for *any* hold-short nodes after arrival and before departure, so it can be important to ensure that they encounter the correct hold short if there is more than one in the same vicinity, otherwise they will jump tracks and move along the other system - possibly ending up at the wrong side of the gate because it seemed that of the 2 hold-shorts within its radius, one offered a shorter route. So AI radius can also play a part.

AI can even jump to another overlay and park in something like a helicopter spot if there are co-located AFDs (overlays). The skill comes in channelling AI arrivals into the nodes that you want them to use, and whether it works for everybody is down to factors often outside our control, such as AI FDE parameters that govern the length of their landing runs, and their radius (and whether that had been altered by the user).

The layout of an airport is the key factor in whether the plumbing technique works at all. There are some layouts where conflicts are unavoidable. ATC is also devising routes for AI that will suit it, and might mess with your plans. Also, plumbing really only serves pass-thru spots and yet would ideally need to be added to pushback spots as well (so that everything plays by the same set of taxiway usage rules you set up. This might add a lot of extra work for little benefit.

-----------------------------------------------

Somewhat on the anti-pushback topic is "turn-around parking" that is in the Calclassics old sceneries, which I adopted for a London City scenery I made years ago and now use with the UK2000 LCY. Turn-around parking's clever trick is placing the final apron route node to the gate in such a way that as the AI turns through 90-120 degrees to shut down engines, the final node is still within the aircraft's radius. It's a real balancing act to get right, and will work less well with smaller-radius planes that might taxy off that final node. When the aircraft gets taxy clearance to depart, it sees the final turn around node and "thinks" that it is already on that node, so it looks for the next one to taxy toward, finds that it is ahead of the aircraft, and heads for that node. No pushback. The hooked taxiway line has to be that simple or risk not working - a simple check-mark/tick kind of symbol is best.

-----------------------------------------------

A recent trick I discovered when making some overlays managed to fix a long standing gripe of mine, which happens at airfields where the gates are all on a ramp at one end of a runway. Even with a parallel taxiway, AI arrivals would insist on turning around on the runway and backtracking even when a runway exit was just metres ahead of them - this happens for me at Newcastle (UK) EGNT, for example. This tendency can be fixed by putting isolated apron-links either side of the runway centerline, between runway exits, after which the AI arrival will taxy forward to the proper runway exit. Even breaking the black runway links doesn't fix this problem at Newcastle. The AI just seems to know that the nearest node to capture is behnd them and they make the turnabout anyway. I called this the "guard rails" option. I suspect the AI sees these taxy links and discounts them because they don't lead to a gate, but their presence seems to change the logic to make the AI look ahead of them rather than behind.

Apologies for the portmenteau posting, but I hope some bits might stir up some ideas.

[hgschnell]

Is your LYC AFCAD still awailable?

Mine (af2_eglcMAX.bgl) works for turn around parking fine, but ATC has a problem with AI landing Rwy 28.
The taxing AI to the RWY 28 start run through landing AI.

[TimC340]

Mage, that's great info. I've found that we tend to over-complicate the taxi routings, and that close attention to the principles you recommend will often avoid the issues which get reported when AFDs are - let's say - less than carefully created. Of course, the FS9/FSX/P3D AI engine is far from ideal, but it does a remarkably good job from fairly simple principles and can deliver a very reasonable facsimile of reality if it's handled well.

[mage]

Hi Tim! The AI engine tries quite hard to thwart our efforts to assert some control over ground routings, and other AI in the system that has "reserved" a ground routing can make the AI engine get too creative about what to do with other aircraft also taxying around. Unfortunately the only "solution" is to watch the airport from a few thousand feet up in "look down" view at 4x speed and get a feel for what happens in particular situations, and watch for potentially some hours. I've had some AI aircraft taxy out along a simple routing and deviate off into a separate ramp area, then back out on the same taxiway along a pass-thru set of links (taxying through an empty parking spot on the ramp and back out along a different taxying line) due to a conflict with another AI. When that other aircraft isn't there it works fine. I think the best we can hope for is to minimize the situations where something stupid happens and accept that in anything slightly complex there will be the occasional moment when the AI engine wins.

@Guenther : My AFD is still used - probably only by me, I just adapted it for the UK2000 scenery and replaced theirs with mine. I made a "lite" LCY years ago that was released on FSNordic, and after some conversations with Tom Gibson, who I think originated the turn-around parking idea for the old-style airports that Calclassic made, I managed to get a working LCY. There were some changes necessary when BAe146s stopped using the airport in favor of Embraer 190-class aircraft (different sizes - different behavior) but it still basically works, the E190s just don't turn around quite enough, they do about 110 degrees when they should be going more like 140 degrees - it's because they "see" the center of the parking spot and shut down before they complete the turn.

How I organize taxying for LCY: Arrivals on RW 28 often stop fairly short of the first taxiway (old layout, LCY now has a full-length parallel taxiway). They then tend to go along the runway and make the first turnoff, which is where departures are queueing. To prevent this head-to-head conflict, the trick is to make a taxiway link along the runway that a landing aircraft encounters before any others, and which leads to the second runway exit, not the first.

If I'm a landing aircraft on LCY runway 28 I will roll out and enter taxying mode, then wander along the runway looking for the first taxiway link that will take me off the runway. I find one and start following it, it's almost in line with the runway centerline, but it's the first exit link I found - so I follow it. As I reach the first turnoff, there is a link there with a departure queue behind the hold-short node - but I'm already on my taxiway - not following the black links- and will drive right by that exit and on to the next one. Since there is no easy way to stop departures queueing at the first exit, making arrivals pass that exit is the only way. The problem is that arrivals from the west, on 10, should ideally then take the first exit when they backtrack, and that can be achieved by putting a link to that taxiway that starts from the turnaround area on the runway and leads back to the first exit. Getting this to work means watching where the typical AI arrivals roll out and enter taxying mode, and figuring the best places to put these taxiway links to get arrivvals onto them before they get the chance to go anywhere else.

I don't have my LCY AFD to hand, but I will post it here shortly (I hope), but the general principle is that the two most easterly taxiways have their taxiway links displaced to the east along the runway at optimal places to capture arrivals and get them off the runway via the exit you decide.

A bit like with pass-thru and plumbing, its a case of studying typical AI behavior on a runway and choosing where to place your "traps" to snare the arrivvals and force them to follow your evil plans.

If you have vastly different categories of aircraft to deal with, the challenges will be greater because you will have a much greater variety of arrival behaviors to cater for. A Cherokee enters the "taxying in" state in a completely different position than a 747 will after landing.

I will try to get the LCY AFD uploaded in the next day or so. A picture paints 1000 words.

[hgschnell]

Thanks a lot for your detailed and helpful answer

[mage]

Okay, the LCY AFD file. I'd mis-remembered the principle I use. It still involves watching the traffic flows and moving nodes around until the runways work in both directions. The illustration I wrote out longhand was for a previous version, and I simplified it later.

After a long time watching traffic flows, I determined that even a Citation (CJ3/XLS etc) only entered taxying mode after a certain distance along the runway. You will notice from the image that the most easterly runway access has a node that is connected to the black links a little further down the runway - it doesn't go straight to the black links and connect there.

Arrivals from the east (after a long time watching) always roll out and enter taxiing mode past that runway connection, so they miss the first exit and continue to the second, and you don't get the head-to-head problems with deprture traffic that you'd otherwise have. If you get AI that stops shorter, you might need to move that node even further east so that they pass the node, or change the FDE of the AI. A Cherokee from the east would almost certainly stop sooner than the node and try to use the first exit - but Cherokees don't fly into LCY. Or rather, they shouldn't! So the AFD tries to deal with the traffic that would use the real airport and its up to the user to stop small GA from flying into LCY.

The trick is to also place the node so that typical arrivals from the west will go past that node and, after turning a 180 on the runway, then engage with that taxi path and leave the runway at the first exit - because westerly operations mean that the departures are queueing at the most westerly holding point. If an AI stops before that displaced node and does a 180, it will still exit at the middle taxiway and not have a huge problem. Perhaps the "guard rails" I mentioned earlier would force an AI to the official turnaround point and then the AI will follow the right route to exit at the most easterly runway entrance/exit at the eastern end of the ramp. I don't use those as of this moment, but if I saw an untidy 180 sometime, I might add them and compel the AI to turn around in that wider point along the runway.

The other problem is runway occupancy. FS9 handles AI quite ineffectually. There's no intiative, just a strict set of rules. This means that a line of departures can very quickly build up and block the ramp. Getting AI off of the runway ASAP is always a better plan, so an aircraft backtracking RW10 after landing will always save us time by exiting at the first opportunity rather than crawling along to the middle ramp taxiway. You can speed up runway exits by narrowing the AFD runway (paying attention to the need to shift hold-short nodes if you do this) which ATC sees as the aircraft getting off the runway sooner. The problem at LCY is the aircraft making a 180 on the runway. On a narrower runway they will probably stray off the edge and be told to contact ground even as they are backtracking the runway. This might actually be a good thing provided they leave at the first exit. The next departure will line up and depart, hopefully in about the same time as the previous arrival gets to clear the runway - making the controller look very slick! Again, only something you can achieve by watching and making a series of small incremental changes.

It all comes down to looking at the layout in operation and getting creative about how AI is actually using it.

I narrowed my runways at LHR and did a lot to improve throughput.

I've attached the AD2 file for this layout for people to play around with. Remember to keep a safety copy of the existing AFD you use!

[hgschnell]

Thanks for the ADE and the detailed description!

[hgschnell]

Hi Richard,

it looks like we use different sceneries, uk2000 part4:

[TimC340]

Guenther, I guess that's the default FS9 EGLC, which represents the airport as it was in the 1990s. The airfield has come on a long way since then! This is how it looks now:

[hgschnell]

Thanks Tim,
yes, because it was "UK2000_part4"

[TimC340]

Ah yes, of course. There is an Orbx version which is roughly in the 2010-15 configuration (before the full-length parallel taxiway), but it doesn't work in anything before P3Dv4.5.

[mage]

Hi Guenther, sorry I missed this, I was busy in another conversation. Yep, this is the UK2000 Xtreme scenery for FS9 that predates the even more extended ramp area and the full-length parallel taxiway.

From UK2K Part 4 there had been the change to an extra 4 gates at the eastern end of the ramp, and it has now gone even further (and no longer has any need for sneaky runway tricks as a consequence).

[hgschnell]

Thanks,
I found it here:
https://secure.simmarket.com/uk2000-sce ... 834).phtml