Well, what is causing the bunching up issue then? If I set width to 1, there's bunching up, if set to 100, none...
I see no bunching here with width set to 0. The airplanes just pause for a couple of seconds on the holding zone, then go to takeoff normally. However, there was just ONE hold short node in our AFCAD (on taxi A7) which was too far from the runway, and that's might be the one creating the issue.
Why is it, that Afcad and other Afcad editors complain when you set the width of a parking connector to 0 or <15ft? Because if set to that and if the link does not line up with the heading of the parking spot, departing AI may not depart at all. So link width matters in certain cases.
The parking connector doesn't anything to do with the hold short zones. If it might be an issue there, it doesn't means it's an issue on the hold short zones as well. Which Afcad editor complains about taxiway widths, not in relationship to parkings ? AFCAD and ADE certainly do not.
What purpose does the transparency serve in FS9?
It's obviously serves to create a layer of details, like custom hold short zone, lines, ground patterns, etc.
Why is the issue of Afcad elements becoming visible not witnessed in other sceneries I have?
There are no other AFCAD elements visible, if you use the AFCAD we supply.
No other scenery I have, needs to suppress hold short markers by playing with link widths.
Should I need to start a list of "other sceneries you might have" that plays with SOMETHING ELSE, which might not be very common, to overcome any SDK shortcoming and fit with THEIR designing style and methods ?
Does it have to do with certain effects in FSX that require default ground in order to work? Rain and whatnot? And isn't it so, that in FSX there just happens to be a different kind of hold short node. One that doesn't draw markers... You don't have those in FS9, so your solution was to reduce link widths.
Yes, that's a reason.
And I have a strong suspicion that it has to do with FSX and your desire not to redo the entire scenery for FS9, especially the textures.
"Strong suspicion" ? We said this MANY TIMES in the open. The FS9 version is exactly the same as the FSX one. It's not a native version, is not made with FS9 in mind, and it will not use FS9 to its fullest because of this.
And, as we said (countless of times), this is EXACTLY (just in reverse) the same situation of 99% of developers out there which instead port FROM FS9 to FSX, and the result is usually an FSX scenery with many issues and glitches, like bad performances, AI disappearing, etc. This is not any different: when something is PORTED from a platform to the other one, you should expect the version begin ported not being as if it were made from scratch with that platform in mind.
It's just that, this time, the port is not made starting with your preferred platform in mind, that's why you see differences compared to other sceneries. The same sceneries that will usually have lots of issue in their FSX versions (if there is one), and it's usually the FSX users that need to live with the inferior version. Here's the opposite. We never hidden this fact.
[quote[That may have sounded like a good idea at the time, but I'd say it's generating more issues for you know. [/quote]
Is still a good idea, of course, and It's either this, or it's not FS9 version anymore. There's a Trial for both versions: FS9 users have all the means of getting to know about the results of this method by themselves, and can always choose not to buy the scenery.
Now, we can have a another lengthy discussion, but why not just say, the transparency does not serve a purpose in FS9
It does: it gives the scenery the look we wanted, without having to rewrite in from scratch for FS9.
And for our next scenery, we may have to rethink how we do the FS9 version...
No, it's much more simple: if FS9 users will stop buying the FS9 version because these porting issues are too annoying for them, we'll simply drop the FS9 version...