Question for any AI guru. ..

[Guest C17SimGuy]

I'm trying to create some overlays for LaGuardia that send the correct airlines to their respective terminals. However, I am curious if there is a way seperate the runway usage so that the landing and takeoff runways are not the same. I know this may be too much for FS to handle, but I'm trying to meet this criteria:-ALL departing traffic uses one runway-ALL landing traffic uses the other runway-Correct airlines go to their respective gates-ALL 4 runways can be used by the AI If this seems unclear, let me pose an example: Wind is out of 270. All departing airlines use 4, all landing aircraft use 31. The wind changes and comes from 360. The landing active becomes 22 and takeoff switches to 31. All the while, each arrival is directed to the correct concourse. Is this possible? I'm just starting to create overlays and having a blast doing it! (currently working on a couple for KLGB: Cargo, Military Testing, Commercial, Commercial Testing, and split GA north and GA south!) Thanks for any input!-drew

[tgibson 11]

No, I don't think so. It's best if each overlay uses it's own runway; otherwise they won't taxi to the correct terminal after landing. You can get close if you use aircraft radius instead of overlays to determine the airline terminal/gates each will use, but you still won't be able to have all the overlays use all the runways (potentially) and get them all to taxi to the correct spots. MHO.Hope this helps,-- Tom GibsonCalifornia Classic Propliners: http://www.calclassic.com/Cal Classic Alco Page: http://www.calclassic.com/alco/Freeflight Design Shop: http://www.freeflightdesign.com/ San Diego Model RR Museum: http://www.sdmodelrailroadm.com/Drop by! ___x_x_(")_x_x___

[Guest]

it is possible but it won't be realistic at all as all planes of different overlays will taxi through each-other etc.

[Guest Captain Barfbag]

But to answer your question...You can use AFCAD to close a runway for either takeoff or landing, or both. Separate checkboxes are provided for each end of the runway, i.e., 4/22. This is a relatively recent addition to AFCAD, so if you downloaded it more than a couple of months ago you might not have this feature. The older AFCAD had a single "closed" checkbox.I haven't always seen what I expected from FS when I do this. It seems the run-time program is much more concerned with runway length than anything else. In the case of parallel or near-parallel runways, the program will always use the longest available runway. In some cases it seems to prefer a long crosswind runway to a slightly shorter upwind runway. It will generally obey the "closed for takeoff" and "closed for landing" checkboxes, however. It will also preferentially use an instrumented runway for AI IFR landings if the runway preferred by wind direction is not instrumented.

[Guest H_Kev55]

AFCAD overlays will soon be a thing of the past with ProjectAI:AD.The PAI AFCAD Division is using the radius method to create new files to do just what you explaned you want. KJ

[Guest Captain Barfbag]

I'm curious about how we will get all of our airports set up for radius. Will we have to download and manually import a couple of thousand AFCAD files? PAI has done a great job on aircraft, but many people don't want to do the wholesale PAI install process. Radius should work great if both the departure and arrival airports are properly set up, but what about all the other airports?Obviously, we need a bulk AFCAD installer. I seem to recall something like that out there. Another useful utility would re-radius an AFCAD file with some sort of "default" value for Gate Small, Medium and Heavy to accomodate the largest PAI radius of each class of aircraft. I'm thinking of all the custom AFCAD work that's been done by people like Richard Mohammed to add gates.

[Guest]

if you wnat realsitic runway operation at KLAX or KATL e.g. you'll still need an overlay :)

[Forkboy2 27]

Even if you use the radius method, your AI Traffic will still work almost just as it did before at default airports and airports not designed specifically to use the radius method.These is because the radius of the aircraft are still close enough to the default sizes. For example the default Heavy gate is 172 feet. The default Medium Gate is 125 feet. The radius method assigns Heavy's radii between about 110 and 172 feet and medium sized aircraft radii of between about 63 and 106 feet. So your airports that just use the Default Heavy and Medium gates will still pretty much get the correct aircraft since most of the Heavy's are still sized between the default Medium Gate and the Default Heavy gate.Same thing goes with the GA aircraft since they are assigned very small radii.There may be a few aircraft that cross over, but shouldn't be that big of a deal.Matt

[Forkboy2 27]

You can still use overlays with the radius system. Not sure where everyone seems to get the idea that overlays aren't possible. I have LAX set up with two overlays that allow operations on all 4 runways. I have about 15 different airlines set up that use LAX and all aircraft taxi to the correct gates without getting hung up on each other. All the international flights share gates at the International terminal. Also, all airlines share all the runways so I can have a UAL aircraft taking off on 24L or 25R or a SWA aircraft landing on 24R or 25L. Again, all with only two overlays. Try doing this without the radius system.Matt

[Guest]

Matt,that is exacly what I said: without the overlays you would still get realistic gate assignments,but you' only have two active runways

[Guest Captain Barfbag]

I looked at radius definitions last night, because this seems like such a great idea if it can be made to work. From some quick looks with AITM and AFCAD, it appears that parking space radius is defined in feet (floating point, like 127.3 or 72.8) while aircraft radius is defined in meters (integer, like 23 or 18.) This integer-meters is a significant limit, because it allows only a small number of different aircraft radii to be accomodated within a "band" of parking radii. The PAI thread on the radius project is pretty, well, threadbare. Is there another discussion of this going on somewhere else?Another question with some conflicting information floating around: Does radius affect anything other than parking? In particular, will it affect taxing near obstacles and crash detection. I've heard both yes and no points of view expressed, but no definitive answers.

[Forkboy2 27]

The reason for the difference between feet and meters is because AFCAD originally only worked in feet and the actual aircraft radius is in meters. Also, the radius of the gate can accept fractions but the aircraft radius has to be a whole number in meters. Also, adjusting the radius does affect a couple other things. For example if the radius is too small when aircraft line up behind each other they will overlap. If the radius is too large, then there are problems like aircraft not being able to pass each other on parallel taxi ways. We got around this by not using the very small radii and limiting it to I think 55 or 60 meters. Also, GA aircraft and smaller regional aircraft have the smaller radii slots and the larger aircraft have larger radii slots. This is why even after you change all your aircraft radii they will still work just fine as AI at default airports. So what we ended up with is a total of about 50 radius "slots" that can be used.In order to overcome this limitation we had to share slots which is why we came up with the different regions figuring a 737 in one region can have the same radius in another region based on the assumption that 737s don't usually fly between regions. We reserved a certain number of slots for the common international aircraft like 747, A340, and 777 so that they have their own radius no matter what region they are in.Keep in mind that this system is not going to be 100% accurate. But pretty close. In order to really improve on it we would need a way to assign each gate to be able to accept aircraft from 10 or 20 different airlines to account for gates that may handle a large number of different airlines.Matt Fox

[Guest Captain Barfbag]

That sounds like the best solution, given the limitations of the integer-type for aircraft radius.Now, where is the all-important web site with the values we should start retrofitting our aircraft with?Oh, that's another question: Is the radius stored with the aircraft model, or with the paint job? Seems to me that's part of the binary MDL file shared by all planes of the same type. Is there a way to override the MDL file in aircraft.cfg, or do we need to restructure our aircraft directories to include separate MDL files for each livery?

[scott967 62]

The radius tutorial explains how to do it, but theconcept is to use a separate .MDL for each paint.The latest AFCAD allows using meters for parkingand also changing default size for parking types viathe .ini file.I note that the parking size is in tenths of meters,but I guess the aircraft radius in the .MDL filesis only set to integer meters.scott s..

[Forkboy2 27]

Aircraft Radius.zip and Radius Update.zip from Project AI Utilities file area. Sorry about all the confusion, we are in the process of putting together a better tutorial, etc.I just uploaded the update so may not be there right away.And yes, the radius is stored in MDL file. It is possible to share same MDL file between different livery's of same airline, but otherwise need new MDL files for every aircraft.Matt