The website and forum will be intermittently unavailable while we're making some security updates.
File uploads to the download hangar are also disabled until further notice.

Making heli AFD overlay

Let's hear all about the eye candy at those military bases.
mage
Second Lieutenant
Second Lieutenant
Posts: 50
Joined: 28 Dec 2013, 13:30
Version: FS9

Re: Making heli AFD overlay

Post by mage »

Firebird wrote: 21 Jan 2021, 11:58 OK I think the general consensus is that they need to be at the same height...
Sorry for thread-bombing here (3 replies in succession) but the same height thing is vital, at least in FS9 (my only sim).

In a post just made I was talking about adding AI to FlyTampa's Saba airport, which was perched atop scenery built by FlyTampa and which would be ruined visually by adding an AFD, which pulls default terrain up/down to its own level with the age old problem of airports in pits or on mesas.

Frustrated by this I made two AFDs, one for the AI, and another one set at sea level using a mesh of taxiway links to define the area, with the idea that the second AFD would drag the default terrain back down to sea level. I talked with Martin Bruncken about this and he pointed out that the load order might be a factor, so by renaming the sea-level AFD to a filename starting with "Z", it was forced to load second, behind the actual AFD. Lo and behold, it worked and became part of the FlyTampa bugfixes released later. I think Martin probably did something a lot more fancy to do the job without creating a second airport (which an AFD does), but the proof of concept just used 2 AFCAD files.

So if you make two AFDs at different elevations, the terrain will be determined by whichever loads second. Consequently you'll end up with some AI floating or sunken, according to whether the second AFD is higher or lower than the first.
User avatar
TimC340
Lieutenant Colonel
Lieutenant Colonel
Posts: 1306
Joined: 07 Mar 2015, 13:18
Version: P3D
Location: Hadleigh, Suffolk
Contact:

Re: Making heli AFD overlay

Post by TimC340 »

That's great info, and interesting stuff. Of course, 'Jim', not 'John' - I beg his pardon. I remember him talking about Innsbruck when explaing how to make approaches to avoid terrain - fortunately, that expertise is still all available in the archives at FDev.

When I get a chance, I'll go back through some of the overlays I've done and see if this radio effect is at play, and how I've managed to inadvertently avoid it causing problems. My efforts have always focussed on avoiding AI jumping networks. I'd never really worked in FS9, having made the move to FSX on Day 1 and subsequently to P3D, until very recently when helping (or trying, at least) JY out with some of his stuff. There are some small differences, I believe, in how AI is handled in FS9 from the later sims, but I wonder if this is one of them?
User avatar
miljan
MAIW Developer
MAIW Developer
Posts: 2144
Joined: 31 Jul 2009, 21:34
Version: P3D
Location: Between continents

Re: Making heli AFD overlay

Post by miljan »

After sorting out issues with AFDs in FS2004 I have a question about how you convert files made with sBuilder from FS9 to FSX/P3D? Is conversion needed at all?
VIVA LA VIDA
Image
User avatar
John Young
MAIW Developer
MAIW Developer
Posts: 4207
Joined: 12 Jul 2008, 15:15

Re: Making heli AFD overlay

Post by John Young »

I usually copy the FS9 files to the equivalent local FSX and P3D scenery are folders Miljan and delete the VTP files. Try that and see how it looks. You will usually need an FSX flatten and exclude. It's very simple to do.

With the FSX version of ADE, open the AFCAD you copied over and draw a terrain polygon and any exclude rectangles. The polygon will also draw the airfield grass if labelled correctly - "Flatten Mask Class Map ExcldeAutogen".

John
User avatar
miljan
MAIW Developer
MAIW Developer
Posts: 2144
Joined: 31 Jul 2009, 21:34
Version: P3D
Location: Between continents

Re: Making heli AFD overlay

Post by miljan »

Yes I figured that out. Too bad you can't make overlap Landclass in ADE. I wanted to add some forest and stuff in Airport areas, but as overlapping of two landclass is not supported I kept it clean.
VIVA LA VIDA
Image
mage
Second Lieutenant
Second Lieutenant
Posts: 50
Joined: 28 Dec 2013, 13:30
Version: FS9

Re: Making heli AFD overlay

Post by mage »

TimC340 wrote: 27 Jan 2021, 12:23 I remember him talking about Innsbruck when explaing how to make approaches to avoid terrain - fortunately, that expertise is still all available in the archives at FDev.
For AI (at least in FS9) to make an angled approach it boils down to creating just one approach leg, by setting an Initial Fix where you need it to be, and picking a point along the runway's extended centerline where you want the AI to intercept the final approach path. AI on approach is always "sniffing" for that extended centerline and, when closing in on it will execute a turn onto final that doesn't need to be programmed since it's just what AI does, a bit like a "homing instinct". For my Battersea AFD I have the AI helos descending along the Thames from either direction and all that's needed are tracks from an Initial Fix to cross the extended centerline, where I placed a FF (Final Fix) to make reading off headings simpler (just move the fix and read a revised heading, and enter that into the leg's heading field). For slow aircraft such as helicopters this intercept point can be very close to the threshold, while for airliners it's a whole other problem with the higher speeds, especially if the closing angle is quite sharp, at it is for the offshore arrivals into Nice/LFMN - or the right-angle turns to final at Abu Dhabi's helicopter runway. ADE's graphic interface makes this phenomenally simple, a world away from having to write the XML and compile it separately.

And obviously this fake ILS is only used if the AI is flying IFR in the first place.

But an angled leg from an IF waypoint that crosses the extended centerline is all you really need for AI purposes if they're avoiding terrain or even on noise abatement procedures etc.
TimC340 wrote: 27 Jan 2021, 12:23 When I get a chance, I'll go back through some of the overlays I've done and see if this radio effect is at play, and how I've managed to inadvertently avoid it causing problems. My efforts have always focussed on avoiding AI jumping networks. I'd never really worked in FS9, having made the move to FSX on Day 1 and subsequently to P3D, until very recently when helping (or trying, at least) JY out with some of his stuff. There are some small differences, I believe, in how AI is handled in FS9 from the later sims, but I wonder if this is one of them?
If an AI arrival gets its parking allocation at a hold-short node after arrival my guess is that it should work its way through the network without any problem, at least, so far as I can tell. The problem at Aberdeen was that most arrivals vacated along a helicopter runway (in either landing direction, a different helo runway for each direction), so my trying that particular layout was asking for trouble, since it could catch an arrival on the other AFD quite easily. Especially since it was my first go at an overlay even though I've been working with AFCADs for a long time. You think you've got all the rules down, and then along comes an overlay to change all the rules.

They're basically just equal priority scenery areas that interfere with each other invisibly, and you end up reduced to reading signs (like the ATC window) to attempt to figure out what the AI is doing, or why it isn't!

None of this is documented in SDKs etc, of course.

Differences in AI between sims is unknown to me. I have FSX but never used it. It's such a rudimentary implementation that I'd be surprised at any significant differences. The most seismic one in the range of FS environments for me (FS5.1 thru FS9, so several pre-AI versions as well) was the loss of 1-way runways between FS2002 and FS2004/9, so for me it's not always been a path of improvements! AI has always been the poor relation in terms of implementation and support, which makes it all the more amazing that so many users manage to wring what they do from it.

Back on topic after that epic attempted thread hijack - I think from what I've seen so far that it is proximity to a runway in an overlay that causes the radio frequency masking, and that it doesn't seem to matter whether the overlay shares r/t frequencies with the co-located airport, or where the reference point is (I moved that around and it made no difference). Whether it's the actual defined runway, the black runway links, hold-short nodes, or even the start points is an open question. I personally think it's the defined runway(s) in the different AFDs, but I could easily be mistaken, not having any other overlays to my name as yet.
User avatar
John Young
MAIW Developer
MAIW Developer
Posts: 4207
Joined: 12 Jul 2008, 15:15

Re: Making heli AFD overlay

Post by John Young »

I'm stuck at the moment trying to place an overlaid Helicopter apron (EGA1) on top of the FS9 default scenery of Belfast Aldergrove (EGAA). This is for the 8 Gazelles based there. The problem is that the apron keeps flashing on and off as the viewpoint moves:

Image

I have a large flatten area over the polygon and an exclude for good luck. I have also compiled a ALT stub file that's in FS9/scenery/world/scenery.

The same apron works fine in the FSX version of Aldergrove with no flashing.

Can anyone suggest a solution please?

John
User avatar
gsnde
MAIW Admin
MAIW Admin
Posts: 4380
Joined: 05 Apr 2007, 08:13
Version: P3D
Location: South-West Germany
Contact:

Re: Making heli AFD overlay

Post by gsnde »

Use an ADE ground poly maybe?

From mobile hence short

Cheers,
Martin
________________________________________
The Owl's Nest * Military Aircraft Reference * ICAO Reference * Distance Calculator * MAIW, Military AI & UKMil Reference
JohnTenn
Major
Major
Posts: 754
Joined: 12 Dec 2011, 17:16
Version: FS9

Re: Making heli AFD overlay

Post by JohnTenn »

John

Do you have the same altitude set for the overlay as the altitude of the default scenery?

FSX and FS9 are not always 100% the same.

The flatten must then be the same as default. The AP946120 has altitude as 81.69m.

John
User avatar
John Young
MAIW Developer
MAIW Developer
Posts: 4207
Joined: 12 Jul 2008, 15:15

Re: Making heli AFD overlay

Post by John Young »

Yes the elevations are all the same - which might be the problem that leads to the flickering. However, Martin's suggestion of a custom ground polygon is working fine, so I will use that method.

Thanks.

John
mage
Second Lieutenant
Second Lieutenant
Posts: 50
Joined: 28 Dec 2013, 13:30
Version: FS9

Finally some light on a dark subject.

Post by mage »

I've what I think is definitive info about the interaction between overlays in FS airports. It might not apply to all sims, since I have only FS9 to test with, but it's worth experimenting if you want to make overlays for FSX or later sims to see whether these factors also feature in those sims.

Working on an overlay for Newcastle I had a bunch of problems getting GA planes to park on the ramp area to the south of the main runway after setting up a helicopter overlay. The symptoms were similar to those I'd seen when making an overlay for Aberdeen, and the underlying reason was the same, the immediate area around an overlay's runway.

It seems that an overlay's runway "reserves" an area around it that is controlled by the overlay's ATC frequencies, and which excludes the frequencies for the "parent" airport. This shows up in different ways. You can also see the area when using the sim in top-down view from about 1000ft or more. How?

If you have an airport and an overlay for it that doesn't have identical ATC services (for example it does not provide ATIS in the overlay) you can see which airport is in control by the ATC options that show up. If the main airport is in control the ATIS would show up, and when under the influence of the overlay, the ATIS would be unavailable and vanish from the ATC options. if the overlay has a different name altogether (or none) then this might also provide a clue since the actual controller's name would change, e.g. from "Newcastle Ground" to just "Ground".

Go into top-down view and slew mode. Open the ATC window to see your comms options. Now slew your aircraft around and you should be able to see the comms options change in the ATC window as you move from one controller to the other.

So, what effects does this actually have?

If an aircraft lands and clears the active, it looks for a hold-short node. If it doesn't find one it'll generally go and park in some parking spot, typically the one last allocated to an arrival. If it finds a hold-short node the fun starts.

If the AI lands at the parent airport and exits the runway at a point where the overlay sits, it'll be running along the ground tracks for the parent airport. It finds a hold-short node for the parent airport and tries to contact the ground controller for a gate/parking allocation. If it talks to the parent airport then it gets a proper parking spot, but if it is in the area where the overlay's runway has control of the ATC frequencies, it talks to the overlay's controller instead providing that they have a common ground frequency.

This is where it gets weird.

The arriving AI plane is sitting on a parent airport's hold-short node and asking for a parking spot from the overlay's controller. The overlay's controller picks a spot from its *own* list and allocates it to the arriving AI plane - and the AI plane then "jumps tracks" from the parent airport to the overlay's taxiway system. I don't know whether this happens regardless, or when overlay and parent have hold-short nodes that are close together - maybe within the AI's radius - it seems to me that the AI just finds the nearest taxiway that will take it to the spot it has been given in the other AFD.

If the overlay and the main airport don't have a common ground frequency the aircraft do what I'd seen happen with my Aberdeen overlay - they say nothing, don't get allocated a spot, sit there with engines running, and get zapped after the timeout period elapses.

So, if you don't want your AI to jump between AFDs and you always want them to get a spot from the correct ground controller you have to get (only slightly) creative.

The simplest option is to put the hold-short nodes for the main airport outside of the area of influence that surrounds the overlay's runway. This may mean that you have to put them further from the main runway than the "fault checker" in ADE (or AFCAD) would like, but if the node is only found by arrivals, this doesn't matter. Only hold-shorts that would be used by departures are potentially problematic.

In the case of Aberdeen I'd had to move the hold-short nodes for arrivals either toward the arrival runway or further away - because the Aberdeen overlay sits somewhere away from the main airport's runway. With Newcastle, I'd placed the overlay runway along the edge of the main runway (the AIP says that helicopters should use the main runway, and I wanted to simulate this). I'd also narrowed the main runway in the AFD (it is for a UK2000 scenery for Newcastle, so this width doesn't show in the sim) so that the two runways sit adjacent to each other. A helicopter on the overlay about to depart doesn't affect traffic approaching the main runway because it isn't sitting on the narrowed main runway in the AFD, but on its own small runway - so aircraft using the main runway will land or depart regardless, which you may or may not like! Aircraft arriving on the main AFD will exit on a track created for them and cross entirely through the overlay's influence before they find their hold-short node. Then they contact the correct controller and get allocated the right parking spot. It's as simple as that.

Note that the same problem can apply in reverse and that an overlay's arrival might just about cross over into the parent airport's jurisdiction.
mage
Second Lieutenant
Second Lieutenant
Posts: 50
Joined: 28 Dec 2013, 13:30
Version: FS9

Seeing a runway's "zone of influence" at work.

Post by mage »

So what's special about runways? We ask for clearance to use them and only make this request when we are about to depart. In FS we see this "reserved area" at work as we creep forward to the hold-short and listen to each AI plane in sequence ask for departure and, when we finally get close to the hold ourselves, we suddenly see the "Request takeoff clearance..." option also appear in our ATC option. It'll also be why hold-short nodes for departures are more touchy than those found by arrivals. If the aircraft is outside the runway's zone of influence it doesn't have the departure clearance available to it and can't call for it. Hence the warning in AFD-making programs about departure nodes.

All parts of an airport inherit all the comms frequencies of that airport. When you create overlays you are co-locating two airports and have to be mindful of how they will interact. Any place where a decision is made (usually when you hear AI making an ATC call) has to be in the correct zone of influence for it to work properly. If you have a hold-short node for one airport too enmeshed in the other airport's infrastructure you run the real risk of the ATC getting misdirected and the AI system not working properly (parking allocation, takeoff clearances, possibly also taxy routes). It may be possible to work around it by moving nodes but you can't avoid that zone of influence around a runway even by sharing ATC frequencies between parent and overlay. An AI can be sitting on a hold-short after arrival at a major airport and make a call for a gate, but if it is talking to the overlay then it'll be allocated parking on the overlay and will invent a way of getting there that might involve skipping off the main airport's taxy path to the nearest node on the overlay. So, a Saab 340 arriving into Aberdeen might end up parking in a helicopter spot, and to fix it will involve moving the hold-short nodes for arrivals (because at least you have the option to, unlike for departures).

Aircraft can taxy through an overlay runway's "zone of influence" just fine provided it doesn't have to make any decision/call while in that area, so long straight taxy routes are perfect, and if an AI has been directed along a path with lots of nodes that is still okay, because by then it is "only following orders" and doesn't need to make a call until it is outside the overlay runway's zone of influence.
mage
Second Lieutenant
Second Lieutenant
Posts: 50
Joined: 28 Dec 2013, 13:30
Version: FS9

Re: Making heli AFD overlay

Post by mage »

While adding helicopters to Manchester (UK) I thought I'd map out the area of influence of a runway in an overlay to give some visual clue as to what to expect if anyone decides to give it a try. So, EGCC ends up with an overlay XGCC that accepts the helicopters, but which will take control over part of EGCC's ground layout.

At EGCC I've decided to park the helicopters (only 3 spots) at the two remote areas (ROMPA and TATON on the airport charts, both nearby pub names(!)) after they have landed on the northern runway. I've also placed the XGCC runway along the northern edge of that runway in the UK2000 scenery, and the runway in the EGCC AFD is narrower than the visual scenery so the main airport and overlay runways don't interact in any way. They've both been named 05L/23R, so ATC will clear them to what sounds like the same runway, but one is in the overlay.

If you want a helicopter on the runway to stop operations at the main airport then you can simply place the XGCC runway somewhere on the EGCC runway. When a helicopter lands on the overlay it's likely to obstruct the main runway in the other overlay and ATC will deal with it eventually. Since I don't "spot" AI this is less important to me, since the chance of seeing a close call is minimal, but YMMV.

It's usually necessary to make angled ILS approaches for the overlay as well, since this avoids a situation where helicopters are ambling along final at 40 knots being passed by a stream of jets close by. This way, helicopters arriving IFR are directed away to one side and approach from there, making a late turn onto final for landing. It solves a lot of visual awkwardness and is often the airport's set procedure in any case.

For Manchester/EGCC the standard procedure is to use the main runway and await a marshaller/follow-me at the touchdown point. For my overlay this touchdown point is as close as I can put it to the parking I've created, and fortunately this is very close to a decomissioned taxiway, so I can avoid adverse effects on any hold-short nodes in the main airport's AFD. Decomissioning this taxiway at the real airport means that I have a fairly large space to plant the overlay's runway and avoid such interference between the two AFDs.

To demonstrate the area that the overlay's runway will affect, I slewed around that part of the airport looking for changes in the ATC options. My overlay only has "parking" spaces, and the main AFD also has "gates". Slewing around, you can map the edges of the overlay's influence by looking to see whether there are options to taxy to gates and parking (the EGCC AFD has control), or only to parking spots (the XGCC AFD has control).

I found the corners of this area and drew the sides in using apron links and put a runway into the EGCC AFD to provide a reference to where it would be in the overlay, just for illustration.

The overlay runway is at the position center-left, highlighted in yellow, and has been superimposed onto the main AFD for illustration purposes only. The rectangle of apron links marks the edge of the affected area, inside which the overlay's runway controls communications. The main airport's AFD cannot have any "decision making" done in this area, meaning that there can't be any hold-short nodes for the main AFD within that box I marked out. This is because if an AI plane has landed at EGCC, it cannot request a gate because it taxies into the area of influence (and ATC) for XGCC. The strange thing here is that it is allocated a gate while in the EGCC AFD, and gets its routing to that gate only when it contacts ground at the hold-short node after it has exited the runway. So it doesn't get zapped after landing because it has a suitable gate, but if its hold-short node is blanked off by an overlay runway it can't request routing. After the timeout period elapses it gets zapped on the taxiway.

Note that aircraft using the EGCC overlay can still pass through this area without any problems - they just can't make any decisions while they are in this area, such as requesting taxi to the gate. They will follow EGCC taxi paths just fine.

You'll see in the picture that the decommissioned taxiway is perfectly placed to create a space for the overlay runway to have its influence without affecting the main airport's ATC. The runway for the helicopters is 400ft long and 20ft wide, and any AI helicopter can use this without problem provided that its FDE allows it to take off and land in a short ground roll.

Making the runway longer to be more forgiving of variations in performance of AI planes will increase that zone of influence, so there's a balance to be struck on an airfield-by-airfield basis.

Just a bit more blogging of my little side-project! Hopefully it might help someone someday.
Attachments
300x20ft Runway influence.png
User avatar
TimC340
Lieutenant Colonel
Lieutenant Colonel
Posts: 1306
Joined: 07 Mar 2015, 13:18
Version: P3D
Location: Hadleigh, Suffolk
Contact:

Re: Making heli AFD overlay

Post by TimC340 »

That's really interesting info, Mage. As I think I alluded some time back, I've been doing overlays for some time without knowing about the runway 'influence'. I've always got it sorted (eventually) with trial and error, and as I always use prototypical radio frequency assignations rather than separate ones for the overlay, it's never been obvious exactly what's going on. Your info will help me get it more predictably right, I hope!
mage
Second Lieutenant
Second Lieutenant
Posts: 50
Joined: 28 Dec 2013, 13:30
Version: FS9

Re: Making heli AFD overlay

Post by mage »

Back on this topic briefly, I have finished making overlays for the various UK2000 sceneries for FS9 and am going though checking the angled ILS approaches that are used to guide AI to the runways in some cases (used just to stop helicopter and fixed wing traffic sharing airspace for too long, by bringing in helicopters differently (typically a final approach between 1/4 and 1/3 of a mile via a sharpish turn). While doing this I made a few notes.

These might seem simple enough to stick to and get good results, but it's not that simple. Moving the ARP (reference point) of the overlay away from the ARP of the main airport helps to reduce contention for ATC control over the area (the further away the two are, the more FS sees them merely as nearby airports, but I still don't know what the boundary between a primary AFD and an overlay looks like - is it a line halfway between the two ARPs or something a bit different? Moving one ARP away from the original just seems to simplify the rules for comms. If there is parking or taxiways for one overlay AFD in territory controlled by a different main AFD, then the parking spots and taxy links are little islands of territory controlled by the overlay. This works fine providing your AI parks neatly in spots. By moving around the ARPs we seem to be able to change the default controller for any particular patch of territory, and this is more forgiving of parking inaccuracies, but might also raise problems elsewhere in the other AFD!

Hints for making overlays

1/
Put the overlay airport's reference point on the far side of the main airport's ARP from where the overlay runway and parking is positioned. This gives the main airport priority over anything unrelated to the overlay, by default. It might seem counterintuitive to do this rather than moving the ARP off to the same side as an overlay, but it seems to simplify the situation because a "complicating factor" is taken out of the mix. The old tactic of "move the ARP some way off from the original airport" is based on this tactic to stop the two overlays from "competing".

2/
Don't put an overlay's runway closer than 225ft from any "decision point" in the main AFD. As has been known for ages, a runway has a zone of influence within which aircraft can only talk to the controlling authority for that runway (hold short limits for nodes used by departing aircraft). If an aircraft arrives on the main airport and taxies to a hold-short node to ask for gate clearance, it will fail to contact the ground controller because at the moment it needs to communicate, it has now taxied into a zone of influence for an overlay's runway - it has only the overlay's ATC to talk to and they can't issue a gate clearance to an airport they don't control (even if they share frequencies with the main airport). For a helicopter runway that is 330ft x 20ft, that runway's zone of influence will extend out by 225ft in every direction, so its zone of influence will be

225ft x 2 + 330ft = 780ft
225ft x 2 + 20ft = 470ft

You can draw a "helper shape" in ADE of those dimensions and move it around the airport to find a suitable place for the overlay runway to be. If the overlay runway has to be in a particular place, it allows you to see any elements in the main AFD that will be affected by an overlay's runway (basically, any red nodes).

3/ An overlay's taxiways are also controlled by overlay ATC. Try to route them away from the main airport's infrastructure as far as possible, and make them as narrow as your AI setup will allow (20ft works fine, and perhaps even narrower would be okay). If you don't see this problem occurring, it mght be that the overlay's ARP is the closest one and you'll only see it when you move that ARP further away. It's seldom very obvious.

4/ An overlay's parking spots are controlled by the overlay's ATC, but only within the radius of the spot (unless the overlay ARP is closest in which case the area around will also be in the overlay's jurisdiction). This enables AI in an overlay to request clearance etc. while on another airport's "territory". A problem that can arise from this is when an arriving AI aircraft cannot turn sharply enough into the spot (perhaps there is turn-around parking there using a hook-shaped taxi path with a very sharp turn). If the arriving AI cannot park directly on that spot, with precision, it won't subsequently be able to request departure clearance and will sit there forever. Because it isn't blocking anything on the airport I assume the AI engine just lets it stay. You can cure this by enlarging the parking spot to make it more forgiving, but it is always a balance between the needs of the overlay and its encroachment into the main airport.

Problems 3 and 4 are only noticeable when the nearest ARP (airfield reference point) is for the "other" airport, because it gives the "other" airport control over eveything that isn't in the AFD (whether it's the overlay or the main airport). When we say "overlay" we give the two AFD's a sense of priority, one over the other. Flight Sim doesn't see it that way. The sim "sees" two airports very close with intertwined infrastructure and applies simple rules to sort it out.

Take this example for problem 4, AI parking.

If the main airport controls the area because its ARP is closest, anything parking badly in an overlay will risk getting stuck there, slightly off its parking spot and unable to talk to ATC in the overlay. If the overlay's ARP is closest then parking imprecisely is less of a problem, because an AI that strays off the ideal parking position will still be able to talk to the correct controller, because the ARP gives them blanket control anyway.

The only certain way to assess who has control is by slewing your aircraft around the airport with the comms set to the ground control frequency, although the two AFDs will need different parking or some other feature that distinguishes them apart. For example if the main airport has gates and parking and the overlay has no gates and only parking, you will be able to see where the overlay has control by looking for points where the option of requesting taxy to gates is no longer there, only parking is available, and when the gates option reappears, the main airport's AFD is back in control. You could also temporarily change the frequency of the overlay's ground controller and see the shifts in control through the frequency changing instead.

Because the Flight Sim AI system gives control of an area to the nearest ARP, moving an overlay's ARP anywhere around the main airport can be problematic if it is too close, whether on the side that the overlay occupies or over on the other side. A lot of thought needs to be used to decide which direction and distance is best for the overlay's ARP. If you want the main airport AFD to be the reference and the overlay to be subordinate to it everywhere on the airport, it is probably wise to move the overlay's ARP to a distance at least twice that of the furthest part of the main airport's layout. Example, if there is a gate positioned 1 mile from the main airport's ARP and the overlay's ARP is going to be put off in that direction, the overlay's ARP will need to be 1.1 miles away from that gate to give the main airport blanket control of the gate and the area around it. This assumes that Flight Sim creates a control boundary between two close airports, and that we are moving that line of control off the airport boundary.

We're effectively saying that the airport called "Overlay" is a mile or so away from the other airport called "Main" but just happens to have all its infrastructure over on the main airport - that's probably how to visualize it.

These note aren't especially cohesive - they were drafted whenever I spotted something and did a brief investigstion, and because they all interact it's harder to come up with definitive rules. But they are all things I have seen over the past two or three weeks. Moving the ARP of an overlay around can have a huge influence, as can enlarging a parking spot or changing a taxiway width to make them more forgiving of wandering AI. I'm not going to claim that these are authoritative or definitive either. But they're a start!
Post Reply