Guys I need some short explanation about how you make overlay AFD to an existing airport for helicopter use only.
Questions i have are :
Can both have same coordinates and heights and is this mandatory in order for traffic to act well.
Do I need to make separate aprons for area where helicopters are based or I can use apron made in existing airport AFD?
How do you usually name them? Let's say for LYNI I made another AFF named LYN1 that has same coordinates and height as original LYNI.
Does this heli AFDs have to be above original airports in scenery hierarchy or they can be put in same folder?
I am asking for all versions FS9, FSX/P3D.
Thanks in advance

OK I think the general consensus is that they need to be at the same height, however the AFD location should be different and as different as practical. This is because the game engine can get confused if they are too close, at least in FS9.

The naming standard you propose is good enough. You want it's name to be close enough so that your brain links them. I know that in the early days a lot of MAIW helo afcads were named with the second letter being a number so EGOV had E1OV. This works fine if you only ever do one country but once you go worldwide the pitfall there is obvious.

A lot of problems have been experienced in the past when movement areas are included in overlayed afcads IF you mix movements and parking across both bgls. If you can try to keep these separate. So for example you could have the same area of concrete in both if you have links and parking spots only on one.
If you can't do that then keep them as separate as possible and be prepared for problems and deal with them if they occur.

I can give you one example. I added a helo afcad to the MAIW airfield and it worked fine but I found that aircraft landing on the original airfield did not leave the runway fully and contact ground. So it would be best to test the entire cycle of ops from both afcads.

Finally, as the ICAOs will be different they can be in the same folder with no issues.

I usually do it like this:

Work the main airport with all aprons etc.
Add the new heliport. Your ICAO example is perfect.
I try to keep the airport reference points as far from each other as possible. So same altitude yes, but not same position.
Heli airport has its own runway, taxi links, parking spots, communication.

All can go in the same scenery folder.

From mobile hence short

We have a discussion over there at FSDeveloper.
I have also a small heliport which is based on the edge of the parent airbase. Maybe this is helpful for you?

https://www.fsdeveloper.com/forum/threa ... ost-871315

I find out that the ARP is not the most important - the most important is enough distance to the hold short node of the parent airbases RWY end. Otherwise, the heliport will use the ground freqs of the main airbase. I did many, many trials to find this out...

On top of our discussion over at FSDev, there is quite a bit about the topic in this thread: https://militaryaiworks.com/forums/topi ... 52#p200952 John and I also discussed it a great deal off-forum.

Overlay AFCADs are tricky, and the results often aren't predictable. In my experience, it takes a great deal of trial and error to get them working reliably, and sometimes you just don't find the trick.

Thanks for amount of info you provided guys . I will go through it. Basically I didnt use taxi links at all , only path link and directly connected to runway in order to avoid any visible misalignment. Another thing is that paths are positioned the way they don't cross active taxiways. I just have to go through ac behaviour and appearance on the ground.

Cheers

While using FS9 I added a lot of classic heli traffic. And ground traffic too. Runways shouldn't be longer than 300 ft. As AFX doesn't allow to get a very small and therefore unvisible width, I modify them to 0.4 ft with the older Afcad tool.

Bernard

I read this with interest since I just created an overlay for Aberdeen (in the library but only for FS9 since it's the only sim I use and test things in). I'd concur with everything here, runways 300ft etc, which I confirmed independently via trial and error, but would add some observations from my own testing of the overlay.

Aberdeen has the helicopter runways centrally on the airfield and, with the fixed-wing runway's exit points all being in the same place, it was a nightmare trying to figure any way of separating the traffic flows, which meant some fairly big compromises needed to be made.

The worst aspect was "radio interference". If a fixed-wing a/c landed at EGPD and exited along one of the helicopter runways, if the hold-short node was too close to the overlay runways the a/c would taxy out of EGPDs radio area and into 2GPDs instead. Since it hadn't landed at 2GPD it'd not be able to call ground for a gate assignment and would just sit there. So, hold-short nodes for the main airport need to be moved as far as practicable from the overlay. Aircraft with a large radius are more affected than smaller ones, because their footprint on the airport is larger and they can still move into the overlay's radio coverage due to their size. So it's important to test the main airport with the largest AI plane you can find (or at least the largest that uses that airport).

There was also a single occasion in my testing (many hours over about a week, much of it at 4x speed) where an aircraft arriving into EGPD, a Fruit Stand Saab 340, exited the runway and "jumped tracks" onto the 2GPD overlay and parked on a helipad. I've long known about the problem of AI planes "sniffing around" for a taxiway in FS9 (for example some arrivals into St Barths might sense the apron routes before they find their exit node and just taxy directly over the grass to the same parking bay as used by the previous arrival). It seems that the same thing is in play with overlays, where AI can jump tracks if you aren't careful.

Aberdeen was probably the wrong place to try my first overlay. It's also extremely difficult to separate ground traffic flows, so there's a constant risk of AI ghosting through each other.

I'm beginning to make a few civilian heli overlays to get John Young's lovely helicopters flying around in approximately civilian forms (alpha channels to hide external equipment etc where possible) and add a dimension to the sim. Since this is UK-only to begin with, I've chosen to name the heliport overlays starting with "X" in the ICAO code. No country uses "X" and it resembles rotor blades!

It could cause problems with odd pairings, for example XGEG in the UK would be EGEG and in the USA KGEG (Spokane). Although by freak coincidence, EGEG is actually a heliport anyway (Glasgow) and we avoid the problem because Glasgow heliport has a legit ICAO! Given the size of the sim world and the way we fly to limited sets of destinations as a rule, the need to use a more ambitious coding scheme is probably overkill.

For naming additional and overlaying ADE I use following system (more or less ...):

AI aircraft remaining static:

• replacing first letter with 1 (LSZH will be 1SZH)

heliports:

• replacing first letter with 5 (EGLL will be 5GLL)

ground traffic:

• replacing first letter with 8 (EGLL will be 8GLL)

seaplane bases near airports:

• replacing first letter with 6 (LFML will be 6FML)

If there will be more than one specific traffic, i replace the ICAO codes with other numbers.

At Zurich, one of my busiest airport, it looks like that (base LSZH not included):


Bernard

mage wrote: ↑25 Jan 2021, 10:42 The worst aspect was "radio interference". If a fixed-wing a/c landed at EGPD and exited along one of the helicopter runways, if the hold-short node was too close to the overlay runways the a/c would taxy out of EGPDs radio area and into 2GPDs instead. Since it hadn't landed at 2GPD it'd not be able to call ground for a gate assignment and would just sit there. So, hold-short nodes for the main airport need to be moved as far as practicable from the overlay. Aircraft with a large radius are more affected than smaller ones, because their footprint on the airport is larger and they can still move into the overlay's radio coverage due to their size. So it's important to test the main airport with the largest AI plane you can find (or at least the largest that uses that airport).

Sorry for extracting just one paragraph, but I'm fascinated by this. Manschy referred to it in his description of his problems with Bruggen.

I have never come across this problem. Partly because I don't use separate frequencies for a helo AFCAD on a fixed-wing airport - it is unprototypical, and makes it very difficult to follow what's going on if you're acting as an observer - but also because the FS9/FSX/P3D ATC engine works perfectly well with no frequencies at all. Its processes and procedures (ie how it directs traffic, allocates runways, taxi routes and parking) are identical, with or without radio work. So this concept that there is a 'radio area' (other than simply a radius from the ARP) is something I've never come across. And it's something that John Vile, the guru of all things AI on FS Developer, never mentioned as far as I know.

Do you have a reference in the SDK you can point me to that explains it?

I just made new AFD for Sarajevo heliport Rajlovac where Bosnian Gazelles are based but experienced weird way of take off. If someone can give me some tips about why heli doesn't taxi till end of runway and then take off.
I will post AFD I made as well for anyone to take a look. It's been awhile since I made any scenery so I got rusty a bit.

Your AFD isn't involved, as shown below.



So it could be the helicopter itself. Have you tried at an other airport?

Bernard

The Gazelle worked fine for me Miljan using the files in your zip and a simple VFR circuit flight plan:



I also have the Gazelles operating fine at Middle Wallop as well as my test airfield.

I'm not sure that it will make any difference, but could you check the [flaps] section of your aircraft.cfg file. Is the value for lift_scalar = 1.5 ?

I notice that when the Gazelle lands at LQS1, it rotates 180 degrees during the drop to exit the runway the way it entered. That is likely to cause a collision with any helicopters waiting to depart. Better to have an exit at the other end of the runway.

When I tested the VFR flight, the helicopter just about cleared the high ground on the approach. You might want to check that yourself, when you have it working and maybe try IFR to give a better clearance.

John

PS:

After I shut down the computer and went upstairs to brush my teeth, the problem suddenly dawned on me. Because you have a uni-directional runway, when the Gazelle needs to take-off from the right because of the wind direction, it can't because there is no taxi link (I was testing successfully departing from the left in the screen shot). Instead it turns into the wind without entering the runway, as in your video. You need to add an entrance and exit with a red node at the right hand end of the runway. I'll test that in the morning, but I'm sure that's what's needed.

Try this. You may need to muck around with the path to the 34 start point to get the helo turning circle within the runway.

Edit: sorry, John. I was working on it while you replied. As you can see from mine, there's no need for another hold as long as the link to to the 34 start is 'airside' of the hold point. I tested it with three helos doing constant VFR and IFR circuits and it works ok. Yes, there is an issue if an aircraft wants to exit the runways as one wants to enter, but FS9's logic allows them to pass through each other as there's no alternative route. The best option is to organise the flight schedules so that doesn't happen, if keeping the airport layout true-to-life is important.

Yes you can do it that way too Tim by adding a taxi path on the runway and a turn around loop at the 34 end. I was just trying to avoid the conflict with a single entry/exit.

John

@John Young
Yes lift scalar is 1.5

Regarding exit on other end of runway: I was planning of making flightplas for Mi-8/17 that will cover Rajlovac Heli Base and since SBAI Mi-8 model doesn't hoover I didn't wanna make it that way. On the end I might keep Mi-8 away from LQS1.

Following this as I just looked over the vast ADE nothingness that is Turkish Army Aviation in my P3D set up. I need have proper bases for the recent TAAC/Turk Navy repaints by Ray.

Miljan, I'm not sure why the SBAI model is relevant to the AFCAD runway entries at LQS1? As far as the taxi to the start points is concerned, should it not behave just as the Gazelles?

John

TimC340 wrote: ↑26 Jan 2021, 09:20

mage wrote: ↑25 Jan 2021, 10:42 The worst aspect was "radio interference"...

Sorry for extracting just one paragraph, but I'm fascinated by this. Manschy referred to it in his description of his problems with Bruggen.

I have never come across this problem. Partly because I don't use separate frequencies for a helo AFCAD on a fixed-wing airport - it is unprototypical, and makes it very difficult to follow what's going on if you're acting as an observer - but also because the FS9/FSX/P3D ATC engine works perfectly well with no frequencies at all. Its processes and procedures (ie how it directs traffic, allocates runways, taxi routes and parking) are identical, with or without radio work. So this concept that there is a 'radio area' (other than simply a radius from the ARP) is something I've never come across. And it's something that John Vile, the guru of all things AI on FS Developer, never mentioned as far as I know.

Do you have a reference in the SDK you can point me to that explains it?

I wasn't using any SDK data, it was empirical data from experiments.

I first used an overlay made by someone else that had just a single separate frequency for the helicopters, and subsequently decided to make something of my own that used more of the main airport's comms.

I noticed that on the fixed-wing layout, aircraft exiting were staying put until the AI engine zapped them (this is for FS9, by the way). I heard no ATC for the aircraft at all. I was monitoring the fixed-wing airport, not the overlay.

By moving my own aircraft along the taxiway and looking at the r/t box, I saw the "controller" change from "Aberdeen Ground" to "Ground" as I approached the overlay. I figured that what the AI was doing was taxying "out of coverage" when they crossed the hold-short node to be given gate clearance. Never getting that clearance because the frequencies were unavailable, they stayed there until the AI engine removed them. So the frequency shift is something you can actually see if you have the ATC window open. Giving the overlay a shared frequency didn't prevent the problem, it just allowed me to listen in to AI using both AFDs. So it's an easily observable phenomenon if you have the ATC window open.

By jiggling hold short nodes, shrinking helicopter runways in the AFD, and shuffling taxiways to one side to stop AI from jumping from one AFD to the other, I managed to get the AI to co-operate. What seemed to work quite well was minimising nodes, and also trying to get arrivals to get their gate clearance before entering the area also in an overlay, because once they have that clearance they seem to cope better. If a taxiway layout can cross others without any nodes, the AI seems to do a better job of staying on the right track.

Jim Vile and I collaborated on quite a few projects involving angled approaches and such, back in the days of hand-coding the XML! I was designing one for Sion (LSGS), Nice (LFMN) and Reagan (KDCA) and he took an interest, and we started a friendship, and he went on to make one for Innsbruck. We also did the same with AFCADs (as was), and I enlisted Jim's help with the FlyTampa modification that brought AI to their Saba scenery (I did the AFD & elevation kludge - because the AFD was pulling the terrain up through Martin's model and making everything ugly - and Jim made the angled approaches). I only touched on the areas for as long as I absolutely had to in order to get specific things done (and later added right-angle finals for the helicopters at Matthew Ministry's Abu Dhabi scenery so that helos did the real-world thing and approached from the south), but Jim took the ball and ran with it much further than I ever would have! As I got less involved with the sim in the last decade we communicated less, and it was sad to learn of his death a few years ago so indirectly. He was extremely good at working hard to pass all the knowledge along, and very patient with people that had trouble grasping the inner detail. He was a good sort.

In fact I thought of him just yesterday when I was making angled approaches for Battersea Heliport (getting the arrivals to follow the Thames as far as possible, given that AI only follows the initial vector of an ILS from the IF - initial fix).

Another thought on this. As you said, the AI engine works just fine with no radio at all. So the phenomenon is possibly just being highlighted by the radio aspect. What is more likely at work (and which is what I mean by "coverage") is that an AI aircraft is taxying off a runway at one airport and is left sitting at an airport where it hasn't technically arrived, and somehow doesn't realize that there are two AFDs co-located. The sim lands the AI at EGPD (Aberdeen Ground), and the act of crossing over onto 2GPD (Ground) just leaves the sim in limbo.

I learned from conversations with Martin Bruncken (FlyTampa) that file naming will determine the order in which scenery files are loaded (alphabetic), so it might be that something as simple as changing the load order might work, but I think that only really applies with visual scenery. With AFDs it seems to come down to making overlays have as small a footprint as possible since reversing the order might just reverse the problem.

Aberdeen was made to work by doing that and shoving overlay elements off to one side whenever practical.