NOTED NZ - A minor complaint - Airport AFCADs

[freddy]

The NZ scenery is fantastic. I've been raving about it non-stop since installing it.

However, if there is one minor issue that is annoying me ... the airports (AFCADs).

I can see that a lot of hard work has gone in to the look of the airports. They look brilliant! But I wish to complain about what appears to be a lack of "testing" of things such as parking spots and taxiways.

Today at Queenstown (NZQN) I saw a Dash 8 turn off the runway doing what I'd describe only as a pirouette, taxi on the thin taxiway (GA taxiway not for Dash 8s), across some dirt, go PAST the apron, over some more dirt (the GA ramp), through some parked GA aircraft, continuing straight on now back to the end of the runway (rwy 05), turn on to the runway again, do a full 360 degree unnecessary turn (its second pirouette), taxi down the runway, turn off the runway again, and, finally, park. Ridiculous, and very unrealistic. The airport looks fantastic, but all of the hard work and fantastic realism counts for absolutely nothing when this kind of thing occurs. I've done plenty of airport editing myself and something like taxi testing is one of the first things that I would have thought would be tested. I was disappointed.

At the end of this post is a screenshot of a Dash 8 and an ATR at Invercargill (NZNV). The parking spots overlap each other. Another thing which I would have thought would have (should have?) been tested.

There are other minor gripes about parking code allocations (or lack thereof) or parking spot sizes which see Dash 8s and ATRs parking in GA areas at airports such as Christchurch (NZCH) and Nelson (NZNS). Unrealistic. Fuel trucks which drive right through GA aircraft to get to other aircraft. Etc etc. The realism is completely lost.

I've not yet flown a lot in NZ having only just received my NZSI and NZNI packages two days ago. I still think the products are brilliant, and the scenery is simply amazing ... but the airports are sadly, for me, a bit of a let down and they are detracting from everything else which is great.

Note that I am not using the supplied AI .bgl file. I am instead using my own AI traffic files and AI planes from Traffic X. I know how to add/fix parking codes in AFCADs, I know how to edit aircraft.cfg files, and I can certainly tweak my Traffic X AI traffic files ... but I don't feel that I should have to do any of that considering I've spent ages getting all of these things right and working with the default FSX scenery ... and with the default FSX scenery, everything was working perfectly fine.

Is anyone else noticing these things? Are there plans for fixes? Or am I over-reacting?

[Capnsully]

Ha, don't tell my Xplane buddies! Looks BETTER than some of the crazy things I've seen in xp.

[Tim Harris]

Freddy, can you run a search of your FSX folder for NZQN? and perhaps post up a screenshot of the results, this sounds more like a conflict.

I'll ping our airport guy to drop in here too,

Cheers

Tim

[gandy]

Traffic X contains its own global afcads based on stock airports which it installs as a scenery object, did you remember to disable the New Zealand afcads, you have to manually disable them ( by finding the folder they are located in and changing the file extension to off or something ) or disable all the traffic X afcads through the scenery library.

[capt sl]

i must say , never noticed about queenstown. so thought id have a look and freddy is right. saw an atr do some pretty weird stuff after landing on 05 before reaching its parking.

also saw that parking issue at NZNV but only if one of the other spots is taken, and since that airport isnt that busy , shoudnt happen normally

[gandy]

capt sl are you using traffic X as well ??

I use to use traffic x but it was a long time ago and i dont see parking or taxi issues with UT2 at the moment

If i remember correctly one of the causes of double parking and aircraft using the wrong taxi ways is down to the aircraft.cfg, if there is missing or incorrect data about the aircraft then it will be treated as a light ( small ) aircraft and you will see larger aircraft use taxiways that are meant for smaller aircraft and it will double park instead of moving to the next parking spot.

freddy, please can you find the folder for your ai dash 8 and open the aircraft.cfg and let me know what the number on this line is wing_span=

[capt sl]

capt sl are you using traffic X as well ??

I use to use traffic x but it was a long time ago and i dont see parking or taxi issues with UT2 at the moment

If i remember correctly one of the causes of double parking and aircraft using the wrong taxi ways is down to the aircraft.cfg, if there is missing or incorrect data about the aircraft then it will be treated as a light ( small ) aircraft and you will see larger aircraft use taxiways that are meant for smaller aircraft and it will double park instead of moving to the next parking spot.

freddy, please can you find the folder for your ai dash 8 and open the aircraft.cfg and let me know what the number on this line is wing_span=

no i dont use traffic x. but had a look with ade the layout of nznv and there is a little parking A2 close to gate 2.

but as i said not being a busy airport i wouldnt think there would be more than 3 dash/atr there at the same time that often and if they are and u take up one of the spots then the other 3 spots would get taken meaning to aircrafts will park , one at g2 and one at A2

[Mickel]

If people are going to be tweaking airports, NZHA has PAL (pilot activated lights) for 14/32 IRL, so if that could be lit it would be great. No biggie - just an observation.

Cheers

Mike

[gandy]

no i dont use traffic x. but had a look with ade the layout of nznv and there is a little parking A2 close to gate 2.

Yeah that is quite common at a lot of airports but if the ai aircraft.cfg is set up correctly it should reduce the chance of double parking but fsx ai can be very weird at times.

With Freddy's problem if i remember correctly from when i used Traffic X i had to fix the aircraft.cfg's to stop what he is reporting, If i remember correctly all the aircraft.cfg's for all the aircraft in the package have the wrong wing span data in them and fsx treats something like a dash 8 as a cessna 172 and a 747/A340 as a 737. I believe the aircraft.cfg has the parking type in there which is why you dont see the larger aircraft parking in small GA parking spots.

Its the aircraft wingspan that determines the taxiways and parking spaces that are used and the same reason why i don't see this in my ai traffic addon as the wing spans are correct and i dont get double parking as a result.

I dont want to install traffic X to find out if that is the issue

[freddy]

Freddy, can you run a search of your FSX folder for NZQN? and perhaps post up a screenshot of the results, this sounds more like a conflict. I'll ping our airport guy to drop in here too

Traffic X contains its own global afcads based on stock airports which it installs as a scenery object, did you remember to disable the New Zealand afcads, you have to manually disable them ( by finding the folder they are located in and changing the file extension to off or something ) or disable all the traffic X afcads through the scenery library.

Correct that Traffic X contains its own global AFCADs. Yes, before installing I checked for the existence of and NZ AFCADs which would cause conflicts (screenshot shown as requested by Tim). I was using a handful of NZ AFCADs with FSX default scenery which I had downloaded and subsequently modified myself. However, being aware of the possibility of conflicts and duplicated AFCADs etc, I REMOVED those BEFORE running the installers for both NZSI and NZSI. The search (screenshot) confirms no other AFCADs exist except for the FTX ones.

freddy, please can you find the folder for your ai dash 8 and open the aircraft.cfg and let me know what the number on this line is wing_span=

Having worked with ADE and doing some mods to Traffic X AI planes etc, I have some notes on wingspan and its role in parking allocation. My notes are as follows: "The critical value for determining an AI aircraft parking spot minimum size in FSX is the wing_span value in the aircraft.cfg file, found in the airplane geometry section. For example, to get a heavy aircraft to park in a "heavy" parking spot, the wing_span value for the respective aircraft must be set correctly. The value must be in FEET, but is divided by two (divided in half) and then converted to whole meters to determine the aircraft parking size (always rounding up: 17.0000001M = 18.0M for parking)."

The Traffic X Dash 8 shows "wing_span=85.0 //Feet". Divide by two = 42. 42 feet = 12.8 metres. So parking spots of size 13 (or higher) should be where the Dash 8's park. And that was correct (spots of that size was indeed where they parked) with the default FSX scenery and the AFCADs that I was previously using with the default FSX scenery.

The Traffic X ATR also shows "wing_span=85.0 //Feet". So it too will park in parking spots of size 13 (or higher).

You are correct, gandy, that many of the Traffic X wingspans were not correct in the original package. There was a WINGSPAN FIX file done by Jon Murchison which I had downloaded and used to update many (all?) of the incorrect winspan values.

I am also aware of the role that PARKING CODES and PARKING TYPES play in determining parking spots. My NZ Dash 8's are as follows: "atc_parking_codes=NZL,ANZ" (NZL=New Zealand Link) and "atc_parking_types=GATE". My NZ ATRs are as follows: "atc_parking_codes=NZL,ANZ" and "atc_parking_types=RAMP".

OK, here is a screenshot of the NZNV AFCAD (below). It clearly shows two OVERLAPPING parking spots. One is a RAMP parking spot (purple). The other is a GATE parking spot (BLUE). With my parking_types set as both GATE (Dash 8 ) and RAMP (ATR) and with both the (overlapping) parking spot sizes being large enough for those aircraft, it is easy to see why these planes are both parking here at the same time. The issue is not related to multiple AFCADs being loaded at the same time, nor the order of the SCENERY LIST in FSX, but is instead due to the overlapping parking spots and the values in my aircraft.cfg files suiting both of those spots for both types of aircraft. This explains why the planes are both seen parked on top of each other.

To me, this is a BUG in the design of the AFCAD. Having done my share of AFCAD editing before, I would personally make sure NOT to overlap parking spots. Although, to be fair, I am NO EXPERT in this area. Are there legitimate reasons to overlap parking spots? How does this work (ie, how do you prevent overlapping planes parking there)?

I can modify my Dash 8 parking codes to match those shown here in the AFCAD and I can similarly modify my ATR parking codes and change the parking type from RAMP to GATE. Doing so will go some way to solving my problem. I can correct the issue this way, but I cannot help thinking that this issue may affect other people who, similar to me, are possibly using their own AI traffic programs and consequently may have different (not matching the AFCAD) parking codes etc in their respective AI aircraft.cfg files. Personally, I think the parking spots should not overlap in the AFCAD. But, as I said above, I am not an expert here.

OK ... to NZQN and the strange taxiing.

Here is a screenshot of the NZQN AFCAD (below). The taxi vectors and nodes are such that the aircraft will taxi as I described in my original post. A fix for this would be to JOIN/LINK the taxi nodes at the beginning of the RAMP so that aircraft landing on Runway 05 and then taxiing to the ramp would turn on to the ramp rather than having to go PAST it and back on to the runway before coming back and eventually getting there the long way around. That would solve that issue, but would not solve the issue of large aircraft using the GA taxiway and thus taxiing unrealistically across the grass. A simpler solution would be to BREAK (remove) the taxi vector at the runway turn off half way down the runway. With no valid taxi path on to that GA taxiway, aircraft would land on Runway 05 and have to turn around on the runway back toward the ramp, thus turning off at the RAMP EXIT and all is resolved. This would be realistic for large aircraft. Sadly, the trade off is losing the small GA taxiway. Either solution would work ...

I won't make any changes to anything just yet. I will first wait for comments on this (lengthy) post. Besides, I wouldn't want to make any changes which would cause a subsequent patch or service pack to not work correctly for me. Especially if there are other airports with similar issues and thus LOTS of changes for me to make.

[gandy]

Im not fully clued up on afcads, etc.. my Dash 8's and ATR's wont use the grass taxiways so there must be something in the aircraft.cfg or air file that prevents them from using them but im not sure what, as your wingspans are correct/fixed. I might install Traffic X to have a closer look on the difference between the UT2 Dash 8 and ATR and the Traffic X Dash 8 and ATR.

I can see why you get that almost parking at NZNV.

[Tim Harris]

I spoke to the NZSI airport developer this morning, and he has a bunch of changes slotted in for a couple of the South-Island airports, these will be included in the upcoming SP2 for NZSI

Cheers

Tim

[freddy]

Ahh. Cool. Thanks Tim for that insight.

I don't want to come across as though I am having go at your airport developer's work. Far from it. I appreciate the effort put in and can see the hours of work that would have been spent on this. The airports look fantastic. I merely want to enjoy the work and "feel" the realism. But with these issues I've noticed, that realism is lost and I am not experiencing what I had hoped. I can indeed make changes myself to the installed ORBX AFCAD files using ADE, but feel it is best instead to note the issues here in case they affect other users and can be corrected in a forthcoming fix ... SP2 as you say. I am happy to hear that. So I won't be changing any AFCADs just yet.

Yet again the support from folks such as yourself, and the team at ORBX is prompt and outstanding. That's a single day between my initial post and a very detailed and informed set of posts with tests, ideas, and possible solutions offered. A job well done to you, and to the other post participants! Much appreciated.

I think for now, I will adopt some aircraft.cfg changes ... I think gandy was heading down that line ... thanks gandy for your input and suggestions. An idea might be for me to install the ORBX freeware AI traffic and to check the aircraft.cfg files that it contains for the Dash 8 and the ATR. If I change my Traffic X Dash 8 and ATR to match those contained in the ORBX freeware, that should be a great help. I see from Wikipedia that the following Airline ICAOs apply here ... NZM (Mount Cook Airline ATRs), EAG (Eagle Airways 1900s) and RLK (Air New Zealand Link Dash 8s). Those codes are in the AFCADs, so all good there. And I'm willing to bet those will be what's in the ORBX freeware AI traffic airline.cfg files. I'll do those changes in my airline.cfg files for those three NZ AI plane types and I think that'll be the way to go.

I now look forward to the forthcoming SP2 and the respective AFCAD changes.

[freddy]

UPDATE:

I have changed the parking codes in the relevant airline.cfg files for my Traffic X Dash 8, Beech 1900 and ATR aircraft to their respective Airline ICAO codes.

The ICAO codes are "RLK" (Air New Zealand Link Dash 8s), "EAG" (Eagle Airways Beech 1900s) and "NZM" (Mount Cook Airline ATRs).

Those codes were therefore entered as parking codes in to the respective aircraft.cfg files and correspond with (match) the ones in the NZSI and NZNI AFCADs (as shown when I view the AFCADs in the Airport Design Editor [ADE] program).

As a result of those parking codes being in the NZSI and NZNI AFCADs and now also in my aircraft.cfg files, these aircraft now park in the correct spots at the relevant airports.

This has solved the problem for me of the overlapping Dash 8 and ATR at Invercargill (NZNV). But, has nothing to do with the taxi problem at NZQN which, therefore, still exists.

I still feel that parking spots in AFCADs should NOT overlap each other ... as I think there may be some people out there who, like me, could be using their own AI traffic programs as opposed to the ORBX supplied one or the ORBX freeware AI ... and thus may have parking codes set in their aircraft files which DO NOT match those in the NZSI and NZNI AFCAD files. Therefore, it is plausable that people may encounter aircraft overlapping each other at Invercargill. But as I have already said, I am no AFCAD expert and despite my thinking that overlapping parking spots in AFCADs is not correct, I cannot speak with any authority on that matter as to whether it is actually OK as an accepted practice or not. Interestingly, I also understand that overlapping parking spots may be EXACTLY how it is at the REAL AIRPORT. And, as I am one who really likes realism, does that pose or create a conundrum? I'll leave the answer, and any changes which may (or may not) be necessary, up to the experts at ORBX ...

[freddy]

I have noticed a similar taxi problem as the one at Queenstown (NZQN) also exists at Whangarei (NZWR). Larger aircraft (Dash 8s and Beech 1900s) taxi off the runway at the GA exit (grass taxiway) and then taxi along the grass taxiway all the way back to the beginning of the runway again, where they turn left toward the runway threshold, do a complete circle, before finally taxiing correctly down the runway and turning off at the paved exit. GA aircraft that are allocated parking spot 1 (the spot closest to the main apron and tower) also perform similar strange taxi rituals having to turn back down the runway to go all the way to the threshold, completing a circle, and then eventually coming back and turning off. Opening the NZWR AFCAD in ADE shows that the issue is similar to Queenstown's issue and could be solved by JOINING/LINKING the taxi nodes at relevant locations in the AFCAD.

I would imagine that if these taxi hassles exist at both Queenstown and Whangarei, then there may indeed be other airports which could also have problems.

Considering the apparent forthcoming SP2 and respective AFCAD changes, I won't make any of my own changes but will leave things in the capable hands of the experts at ORBX ...