Well, I started with the AIG-modified FlyTampa ADE file and put together a skeleton version of EHAM with some changes, using Airport Design Editor for P3d5. First I opened all runways for takeoff and landing, removed all the crosswind runways and added starts, to see if that would make a difference in VOXATC. Second, I removed any stock items from P3d4 and replaced them with P3d5 versions. I did not add taxi signs. I added a few big aprons and changed the draw flags on all the paths so that I could see them when taxiing. Then I deleted all the airline codes from all the parking spots and added back only about 15 airlines, based on where they tend to park according to Flightstats. Most of the gates were assigned to KLM. What I noticed was that some gates in the original ADE file had 15+ airline codes. None of my gates had more than 4. That left most of the gates without an airline code. It's usually not a problem in P3d to assign 15+ airline codes to a gate, but I wanted to check to see if that "helped" VOXATC.

The fsaerodata file set was at a lower priority in my scenery library than the modified EHAM, but remember from above that I loaded the stock comms, navaids and approaches from P3d5, so they were more or less up to date.

I did an IFR flight into EHAM from the northwest. VOXATC created a nice collection of AIG traffic and assigned me an NDB-DME approach to RWY 36R (as were all the arriving aircraft). Forgetting about the real EHAM for a second, that seemed consistent with the wind direction. I will try some other of the approaches  into EHAM tomorrow. This made me wonder is it is worth closing runways to landing, as if there is no approach assigned to that runway, VOXATC isn't going to tell either you or the AI aircraft to land on that runway unless you are flying VFR. Taking off is a different matter. If the runway is not closed  to takeoffs and has a start, it will be used by VOXATC, based on the wind.

That's the good news. Now the bad. I reversed the flightplan to leave Schiphol and head to an airport in the UK. Everything working great initially. I was assigned RWY 09 for takeoff and again there were a number of AI aircraft moving about. However, after I received permission to climb to cruising altitude, that's the last I heard from VOXATC and I got a FATAL ERROR. There was never a handoff to a center frequency. What's interesting is that the fsaerodata file that contains the center information bvcf.bgl is always active for every airport and when one looks at the center boundaries with LittleNavMap, they are problematic around EHAM. There are overlaps and gaps and that might cause some issues. I'm going to try the stock P3d5 bvcf.bgl file tomorrow, but it's possible that the boundaries are also messed up in the stock P3d5 version. Those overlaps and gaps have been around since FSX and maybe even earlier, as I recall.

1 hour ago, jabloomf1230 said:

Well, I started with the AIG-modified FlyTampa ADE file and put together a skeleton version of EHAM with some changes, using Airport Design Editor for P3d5. First I opened all runways for takeoff and landing, removed all the crosswind runways and added starts, to see if that would make a difference in VOXATC. Second, I removed any stock items from P3d4 and replaced them with P3d5 versions. I did not add taxi signs. I added a few big aprons and changed the draw flags on all the paths so that I could see them when taxiing. Then I deleted all the airline codes from all the parking spots and added back only about 15 airlines, based on where they tend to park according to Flightstats. Most of the gates were assigned to KLM. What I noticed was that some gates in the original ADE file had 15+ airline codes. None of my gates had more than 4. That left most of the gates without an airline code. It's usually not a problem in P3d to assign 15+ airline codes to a gate, but I wanted to check to see if that "helped" VOXATC.

The fsaerodata file set was at a lower priority in my scenery library than the modified EHAM, but remember from above that I loaded the stock comms, navaids and approaches from P3d5, so they were more or less up to date.

I did an IFR flight into EHAM from the northwest. VOXATC created a nice collection of AIG traffic and assigned me an NDB-DME approach to RWY 36R (as were all the arriving aircraft). Forgetting about the real EHAM for a second, that seemed consistent with the wind direction. I will try some other of the approaches  into EHAM tomorrow. This made me wonder is it is worth closing runways to landing, as if there is no approach assigned to that runway, VOXATC isn't going to tell either you or the AI aircraft to land on that runway unless you are flying VFR. Taking off is a different matter. If the runway is not closed  to takeoffs and has a start, it will be used by VOXATC, based on the wind.

That's the good news. Now the bad. I reversed the flightplan to leave Schiphol and head to an airport in the UK. Everything working great initially. I was assigned RWY 09 for takeoff and again there were a number of AI aircraft moving about. However, after I received permission to climb to cruising altitude, that's the last I heard from VOXATC and I got a FATAL ERROR. There was never a handoff to a center frequency. What's interesting is that the fsaerodata file that contains the center information bvcf.bgl is always active for every airport and when one looks at the center boundaries with LittleNavMap, they are problematic around EHAM. There are overlaps and gaps and that might cause some issues. I'm going to try the stock P3d5 bvcf.bgl file tomorrow, but it's possible that the boundaries are also messed up in the stock P3d5 version. Those overlaps and gaps have been around since FSX and maybe even earlier, as I recall.

Note for those attempting mods in ADE: Remember to re-run the vox indexer after every change to an afd file!

Wow great job, you have replicated the error perfectly, entering FT Eham isn’t to bad and workable but leaving it either has you repeating every command to vox or a fatal error. Such a shame as it’s a beautiful airport. Fingers crossed for a work around

15 hours ago, jabloomf1230 said:

Having played around with the ADE file, there were faults that could be fixed, but my remembrance is that the the runway layout poses a serious challenge. Just take a look at all the posts about EHAM in the AIG forums. I'll take another look at the FlyTampa ADE file that AIG user UniformAlpha did:

https://www.alpha-india.net/forums/index.php?topic=33056.msg329100#msg329100

but I'm not holding out any hope for a solution. In my opinion, P2ATC and VOXATC both expect at a modestly sensible airport configuration. The default P3d ATC and AI traffic control is so basic, that it probably ignores anything that it can't figure out with EHAM and blindly marches on whether it makes any sense or not.

I don't mind AI doing crazy stunts there, for me it's about flying there with VOXATC. Does the indexer read FT Amsterdam?

P2A works ok there in the sense you can fly from/into EHAM with ATC support, so did anybody try to fly there with VOX? I used to like VOX so much in MSFS times.

Thanks.

PS: I've just seen Jay's post.

Edited July 13, 20205 yr by Dirk98

I tried flights both in and out of the stock P3d5 EHAM and I had no problems with VOXATC, for what that's worth. There are so many procedure for EHAM that it would probably take weeks to test them all.

 

10 hours ago, jabloomf1230 said:

I tried flights both in and out of the stock P3d5 EHAM and I had no problems with VOXATC, for what that's worth. There are so many procedure for EHAM that it would probably take weeks to test them all.

 

Jay, I will try to disable FT AMSTERDAM and run the indexer? I'm not really expecting ARAIG from VOXATC, just something working and workable there

Just make that there are no other 3rd party versions of EHAM "hiding" somewhere in your scenery library. AI traffic add-ons and ORBX products often add airports.

I re-checked mine today and noticed that my Eham was the Uk2000 version and not stock, possibly the reason I got no Atc after landing at Eham.

will uninstall this and go back to stock, hopefully we can get a fix for something to work with vox

If you do, try a few different departure, approach and arrival procedures and see what happens. No matter what VOXATC assigns you for an approach procedure, you can request an alternate via the menu in the VOXATC window (press 0 for all the options). I've been trying various approaches, but the more people that test this EHAM, the more likely it is that we will figure out what's wrong. BTW, I did check with the developer about overlaps and gaps between adjacent Center/FIR airspaces. VOXATC ignores them, so that's not the issue with EHAM.

41 minutes ago, jabloomf1230 said:

I did check with the developer about overlaps and gaps between adjacent Center/FIR airspaces

jay

not wishing to go too far off topic, but did those "discussions" with TW cover what i still have a problem with at several repeating locations.

https://www.avsim.com/forums/topic/575011-center-approach-clash-fe/?tab=comments#comment-4233374 refers.

 

No, unless Kevin did. Send an email to the VOXATC official support with the above information. The emails are being read and will be acted on for the next version of VOXATC.

51 minutes ago, jabloomf1230 said:

the VOXATC official support

do i assume that is the "contact" form ...... https://voxatc.com/Contact.

or is there an email address i've missed.

55 minutes ago, vadriver said:

do i assume that is the "contact" form ...... https://voxatc.com/Contact.

Yes.