About Aircraft Parking and Gate description:

By using specific gate types we prevent displaying of the default service vehicles independently from the user settings.

There is a big limitation on gate identifier.

All Traffic Add-Ons use different aircraft properties (wing span, Airline Codes,...).

It is impossible to match every users AI.

Our priority in parking distance is the user aircraft, as there is less variety and to ensure you don't start your flight inside the terminal.

 

 

I guess I am anal, I have gone into all my AI aircraft and changed the "Wing Spans and Codes" to correct sizes because of this issue, however there are still AFCADs that aren't correct and I have to go in and physically change the Jetway and "T" distances.

 

As far as correct gate descriptions, I do understand that most simmers are not as anal as I am, so if you could make two AFCADs;   one with simmers who use default ground equipment and me, who turns the default off.  :blink:

 

BTW, love your work thanks.

 

 

Ray,

You may want to look at ADE...

 

Hi MD, I have used it in the past but it still reported a high number of 'faults'. Having heard from an airport designer I'm keen to hear what tool he uses.

 

 

uk2000 have an updated afcad section, do you have their latest?

 

I have the one that came with the airport. I will ask if any later ones have fewer 'faults'.

Ray, as the developer of the Flightbeam and some other payware AFDs I want to comment this briefly:

First of all: Did you experience any real problems with the AFD while simming, or did you just run the fault finder?

 

Those errors you mentioned are relative, when we produce the AFD for an airport with custom ground poly we don't use the links as intended.

 

We add way more nodes to ensure the AI aircraft are taxiing on the centerline, thus there are overlapping nodes at some complex intersections.

 

But those are not errors, as otherwise the AI would taxi via shortcuts or off the centerline.

 

 

Hi Daniel,

 

Firstly, thanks for replying here. It's always appreciated when we hear from developers. No, I hadn't spotted any specific problems. I just went with the option of all faults selected in AFX. I can understand why tricks are employed to make Ai taxi more realistically so I will ignore overlapping nodes. It seems as though AFX treats all anomalies the same but some are clearly more serious than others.

 

 

The maximum holdshort distance has some tolerance. The fault finder will of course use the minimum, but its sometimes necessary to nearly reach the limits.

 

And as others already wrote, this is only important at the runway ends, as the AI won't get the takeoff clearance if they are too far from the runway.

 

At the middle runway intersections, those errors are irrelevant and at a large airport like IAD with four runways you might get a large number but it doesn't say anything.

 

 

So the obvious question is why include hold-short nodes away from runway ends? Are they there for aesthetic reasons only?

 

There are sadly lots of limitations and problems with FSX (i.e. runway usage). Be sure those faults are the smallest concern in AFD design.

 

The one that frustrates most of all must be both ends of a runway must be open or closed and never mixed. Pity Microsoft couldn't sort that one out.

 

When I am in the progress of developing the AFD. I run the fault finder every 30 minutes and fix the real mistakes. I spend hours simply monitoring the AI movement, searching for the important problems and trying to increase the traffic flow.

 

At all Flightbeam airports also the service roads are traced in the AFD so GSX works as intended, this sometimes produces more node related error messages which are irrelevant.

 

 

Can you say what tool you use to check the AFD? AFX? Or the ScruffyDuck one? And what would you consider to be 'real mistakes'? Perhaps I can then only filter for those in AFX.

 

I have to agree with you all, that there are a lot of bad AFDs even from the "big players", but a lot of problems you adressed are because of limitations we sadly can't change. If you have any other specific questions I am glad to answer them.

 

 

Thanks for your openness. Could you explain why there are over 100 'node and link not connected' faults in KDFW? Is it erroneous reporting or not. And if those were created deliberately what is the end results from a visual point of view? Does it affect Ai aircraft, ground service vehicles or what?

 

Without tools like AFX or ADE we would all be blissfully unaware of any problems with AFCADs. What I would like is some guidance on what options I can disable and what are the most important faults we should act on and bring to the attention of the developer.

 

 

Ray, as the developer of the Flightbeam and some other payware AFDs I

 

Why are you not a commercial member then?

 

 

Why are you not a commercial member then?

 

There was a time when anyone who had anything to do with someone in business was tagged as a Commercial Member.  I believe AVSIM tightened up this policy for who was and who wasn't considered to be a commercial member (someone in business) and I believe that was a great move.

 

Another way to look at it is that there are lots of developers, but that doesn't mean that they're in business, so they're not a Commercial Member.

Ray, as the developer of the Flightbeam and some other payware AFDs I want to comment this briefly:

 

First of all: Did you experience any real problems with the AFD while simming, or did you just run the fault finder?

 

Those errors you mentioned are relative, when we produce the AFD for an airport with custom ground poly we don't use the links as intended.

We add way more nodes to ensure the AI aircraft are taxiing on the centerline, thus there are overlapping nodes at some complex intersections.

But those are not errors, as otherwise the AI would taxi via shortcuts or off the centerline.

 

The maximum holdshort distance has some tolerance. The fault finder will of course use the minimum, but its sometimes necessary to nearly reach the limits.

And as others already wrote, this is only important at the runway ends, as the AI won't get the takeoff clearance if they are too far from the runway.

At the middle runway intersections, those errors are irrelevant and at a large airport like IAD with four runways you might get a large number but it doesn't say anything.

There are sadly lots of limitations and problems with FSX (i.e. runway usage).

Be sure those faults are the smallest concern in AFD design.

When I am in the progress of developing the AFD. I run the fault finder every 30 minutes and fix the real mistakes.

I spend hours simply monitoring the AI movement, searching for the important problems and trying to increase the traffic flow.

At all Flightbeam airports also the service roads are traced in the AFD so GSX works as intended, this sometimes produces more node related error messages which are irrelevant.

 

About Aircraft Parking and Gate description:

By using specific gate types we prevent displaying of the default service vehicles independently from the user settings.

There is a big limitation on gate identifier.

All Traffic Add-Ons use different aircraft properties (wing span, Airline Codes,...).

It is impossible to match every users AI.

Our priority in parking distance is the user aircraft, as there is less variety and to ensure you don't start your flight inside the terminal.

 

I have to agree with you all, that there are a lot of bad AFDs even from the "big players", but a lot of problems you adressed are because of limitations we sadly can't change.

If you have any other specific questions I am glad to answer them.

 

 

 

Sorry for my bad English and grammar, it's late...

 

Well, thank you very much for the answer. It's refreshing to see a developer that actually cares about his customers, this just confirms my idea of FlightBeam as the best airport developer around. Most developers treat anything we say about their products as a personal offense, thank you for taking the time to respond Ray's topic.

 

Cheers!

DAVECT2003

 

 

 

Ray, as the developer of the Flightbeam and some other payware AFDs....

 

Did you miss the words where he is a developer of payware?

 

Someone who takes money  in business for payware  must be a Commercial Member, surely.

 

 

Did you miss the words where he is a developer of payware?

 

Actually, I don't know Ray, but I've worked directly with many high end scenery and aircraft developers, including editing AFCADs and the like, but that didn't make me a commercial member as I wasn't the person actually selling the product, I was just a member of the development team. Put another way, developer doesn't mean commercial member, it just means they produced something.

 

Truthfully, I don't know if Ray owns Flightbeam and sells the product himself, I just took his statement at face value, that he developed the AFCADs for the scenery.

 

Not sure why you wrote your response to me as you did, but just to be sure your not upset I'll just say that I meant no disrespect to you in my initial comment to you, just trying to answer your question.

 

Best wishes to you.

Dave. Why the references to me in your message above? I didn't ask the question you quoted and I certainly don't own FlightBeam!

Why are you not a commercial member then?

 

hero93 has been developing AFCADs for us for quite some time. Just because he doesn't have a commercial account doesn't mean he's not a commercial developer. 

 

Also his remarks are correct. Many.. many of the errors are quite irrelevant, they are hand-tuned to work as designed for the airport. 

 

I'm pretty sure this goes for other developers as well. It certainly doesn't reflect a lack of care in the AFD, on the contrary. Many.. many many hours are spent on making it seamless with the custom scenery. 

 

 

hero93 has been developing AFCADs for us for quite some time. Just because he doesn't have a commercial account doesn't mean he's not a commercial developer.

 

So he is a commercial developer.

So he is a commercial developer.

Gerry,

 

If you have any issues or questions with who should be or not be tagged a commercial member here you can take this up with AVSIM Staff or by private message.

 

Thanks!

I don't really see myself as a commercial member of the community.

Developing AFDs is like another hobby for me, that I get occasionally payed for.

I am not part of any company and I don't make money by selling Add-On Products.

1) Hold short node too far from the runway

 

HS nodes only need to intersect the runway at the departure locations. I only recently learned of this from Norman Dean (the UK2000 AFCAD designer), and he is a master at this kind of thing.

 

2) Node possibly unconnected

 

Sometimes links are "cut" to stop backtracking on runways. This does not cause problems for the AI planes. It is in fact meant to improve traffic flow, and reduce conflicts between arriving and departing traffic.

 

3) Node and Link not connected

 

This is sometimes used to include a section of AFD taxiway (since the blue taxipath option in ADE "lays down" the asphalt/concrete etc) which you do not want AI planes to use, but is still required because there is a section of "dead end" taxiway in that location, or because that taxiway is closed in the real world.

 

4) Link Designator mismatch

 

Is this indicating that a section of taxiway has a different designation to the links on either side of it? If so, then it's possible that an error got through beta testing without being detected. However, this in itself will not cause a problem for the AI planes. The only difference you will notice is when ATC asks you to use that section of taxiway, and you will be instructed (for example) to use taxiway "Alpha Charlie Alpha", rather than just "Alpha" (if there is a rogue "C" designation on an "A" taxiway).

 

5) Overlapping nodes

 

Are you referring to "orphan" nodes that should be removed, or "doubled up" taxipaths on the same section of taxiway? If it's the former, they will not do any harm. If it's the latter, then the AFD designer may well be using what is referred to as "the plumbing system". This is used when you want to separate arrival and departure taxi paths for the AI planes, so as to avoid conflicts as much as possible. It is extremely useful, and is one of those clever workarounds that have been discovered when using the MSFS AFD system.

 

6) Isolated node

 

Again, this is unlikely to cause problems if it is not connected to anything. AFD files can be complex beasts, and occasionally stuff like this gets past the beta testing process undetected (probably because the AI system is working fine).

 

7) Apron Self-Intersection

 

Not sure what this means.

Hi Christopher,

 

Thank you very much for that explanation. It certainly helps lift the fog for me on how AFCADs are constructed and the techniques used.

 

The options available in AFX don't always match the faults reported. There is a difference in the wording which makes me unsure which options I can safely deselect. Which of these can I ignore?

 

 

Regarding Link Designator Mismatch I may have missed which airport that was found. I'll need to check. That sounds like one that needs checking.

 

I bought AFX back in August 2007. The manual is quite basic on Fault Finding and states "a fault found by this tool does not necessarily indicate an error in your airport." It sounds like it's a useful tool for an experienced AFCAD designer but for the uninitiated like me it's warning about things that I don't need to be concerned about. Just a pity it's not more specific about which options can be ignored.