• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

AI Aircraft multiple parking codes "appear to work" in FSX

I've used GATE, RAMP as well as GATE,RAMP and the planes may choose indistinctly RAMP, even if there are GATES empty. It seems rfields is right with the fact that two choices means "any spot in the airport" that has the right parking dimensions for the particular aircraft.

As of the multiple parking codes, they work fine. At my airport (SVMI) I am using a code IMQ to drive all international flights to the international terminal (to the west), and also use CMQ to guide cargo planes to cargo areas. Then I need to enter the particular general zone code to all involved airplanes (it's right done for that airport). The local airliners traffic goes to the "national" terminal and there I use airliners particular codes to park in their right gates.

The only problem I see is that it seems four parking codes seems to be the limit, so if you need to do the same I did with SVMI for different airports you may deplete the maximum four codes. In this case the solution is using the same aircraft with another title and usingdifferent parking codes.

Jorge
 
Here is an oldie but a goodie, brought back to life...

I am gathering every bit of info I can get before making my flight plans for my NKL project. Thus, a google search brought me home...to this old post. Guess I should have looked here first.. LOL

Anyways, first: Is there an updated thread or wiki with all the info on parking I could ever want? If so, please, let me know where.

Then, for those that create flight plans...I ask this: For me, coding the parking spaces is a no brainer.. I like the idea of a special code for forcing cargo planes to the cargo area, etc... But since, as I am sure many of you do, I want to release my project for the public, do I have to write instructions telling people how to code all their planes to use the airport as intended?

I am asking this because I know I probably wouldn't do this for an airport add-on. It's hard enough wondering what planes people may have for AI use, but then telling them they need to edit the codes.. Seems a bit much. So do you all do this? Do you release the airport AND include all the ai planes that should be used? What if, like me, you have a VA operating out of the airport...do you include all those aircraft at least?

I, personally, use MyTrafficX for most of my AI. Of course, I have some other stuff, and I actually also have Ultimate Traffic X but currently use MTX. I also have a few PAI aircraft installed for testing purposes. As well as using NON AI aircraft as AI.

So I am asking what you all do.. what advice do you have for me before I start this fun adventure of a full schedule of AI traffic for my airport.

Thanks!

- Greg
 
I prefer to use parking spot radius to control my parking whenever possible.

I do not like having multiple parking codes, for a lot of the reasons you mentioned.

I have made airports where I have only a single parking code for each spot, or, at most, maybe two codes. I see many designers who over-rely on parking codes to solve parking issues, when in fact they could have avoided having 4 codes in one spot by simply tweaking the radii of their spots.

Regarding including the AI aircraft...of course we know we cannot include the aircraft unless we authored them...so in light of this, I always provide links in the documentation about where to download the models and paints needed.

I've got a project I'm close to releasing (kind of waiting for AVSIM to start going again), which has AI bgl's that I made, and in the documentation I tell people how to install it all, and I even go so far as to tell them the wing_span entries they will need.

The drawback is that many users do not bother reading all of that, and to top it off, some users will not have technical know-how to pull it off. They simply run the installers for their AI package(s) and go. They cannot be bothered with the ins-and-outs of wing_span and parking codes.

That is why, even if you make extensive docs, be prepared for emails saying "There is a bug in your scenery. I installed your scenery and my xxxx won't park there"...when in fact, there is no bug. The user's AI is set up incorrectly, most commonly using FS9 wing_span values that mean nothing in FSX. So be prepared for this type of email if you make a complex parking scheme.

That is why you want to keep it as simple as possible with your codes, in my opinion.

P.S. I assume you've heard of:

NWA <--- standard airline
NWAX <--- regional carrier
NWAC <--- cargo carrier

This can be done, but I don't really think it is a universal standard, based on the AI packages I've seen. And of course Fedex is FDX, not FDXC.
 
Rhett,

I agree totally with you, however, where you run into problems, is that unless you modify every aircraft cfg, the sizes may or may not work. Ok, so you modify them. Now you release your package. Well, not everyone has the same AI aircraft..so their system may use another plane. That be the case or not, that user now must make sure and/or modify all their aircraft files to make sure the sizes are correct.

If you have a flight plan with maybe 30 types of planes, and say 200 variations, that will turn people off real quick. It has me.

When I get a nice package, and I read that I have to start modifying files for it to work right, I usually just delete or archive the package. I am pretty sure I am NOT alone in that regard.

My point being...and as I stated, I agree with your thoughts totally... but when I release my package, I don't want the end user to have to modify anything or very very little IF anything. Cause I don't want to do it. hehe

- Greg
 
Yes I know what you mean exactly.

Really the whole AI setup in FS8/9/X is not really setup for ease-of-use. I mean, you have to have models. Then you have to have repaints. Then you have to have schedules. Then you have to make sure the models are in the right place. Then you have to modify the aircraft.cfg's to make sure the textures are there, make sure the right models are referenced, and make sure the parking codes are correct, and make sure the wing_spans are correct....

WHEW! I'm tired just typing it all.

The scenery setup, where we just need the .bgl's and textures (if any), and a /scenery and /texture subdir setup...is pretty good...relatively simple and compact.

But the AI system? Not so.

All I can say is, all we as designers can do is make sure our parking radii are right (18.1m for 737,A32x, 33.1m for 747, etc.) and hope the users AI are using the correct spans.

Reggie Jim George et al really everyone here, has talked a lot about what a standard size should be. Even ACES kept 50 meters as a standard CARGO parking radius in FSX, which is not useful in FSX...so there was not much attn paid this I think.

Here is what I use

18.1m <--- GATE_SMALL
23.1m <--- GATE_MEDIUM
33.1m <--- GATE_HEAVY**
33.1m CARGO

8.1m <-- GA_SMALL
10.1m <-- Ga_MEDIUM
12.1m <-- Ga_LARGE

** DC10/MD-11 gets 26.1m gATE_HEAVY

But even these are not ironclad. I mean, I often have 15.1m GATE_SMALL for regional jets like the CRJ's and ERJ's. And some of the big Gulfstream corporate jets get larger than 12.1m for their LARGE ga type spots.

All we can do is hope that the users have good wing_spans in their aircraft.cfgs

I know if they don't want to fix them, they might get frustrated and chuck it all, but there's nothing we can do about that. The FS enthusiast will want to get it right, I think. They are the ones downloading our warez anyway, right? :)
 
I wish as designers, we would just come up with a set rule of thumb. I am recreating the great list of actual sizes. When it is done, I will post it here. I would love for there to then be a debate if needed, or a vote, or whatever, to say ok, here are the real numbers, here is what we are setting as standards for developers.

While we can't speak for all developers, I think with almost 6000 registered members here, (granted, maybe 100 are actively active) this would qualify as THE FS designers and developers web site. I am all in favor of having a FSDEV seal of approval for projects. maybe a panel that looks at projects, or a set of 'rules' or 'guidelines' that if followed will get you the seal.

Just a thought.

- Greg
 
Hey Greg,

why do you wish to create a new system?
Take a look to Martin Gossmanns The Owls Nest. There are all corrected wingspans. He has written a tool to modify the aircraft.cfg.

The airlines are coded since AFCAD with the ICAO-Code. This is integrated in ADE too.
Aircraft (civil and military) are coded with there ICAO-Codes. Even Microsoft is doing this:
You find in the aircraft.cfg the entrys like this:
atc_model=A321 A321 is the ICAO Code to the Airbus A 321

atc_model=B773 defines the Boeing 777-300 (ICAO-code)

Look the the ICAO-page

There is a file in the net: Parking specs file for AFCAD 2:

; Parking Specs File for AFCAD 2
;
; December 2008
; Created by Curt Jardey [curtjardey at netscape dot net (no spam)]
; Original AFCAD2 file by Lee Swordy
; Update Assistance from:
; Graham K Jackson
; John Hinson
; Mark "Dark Moment" Beaumont
; Francois Massin

with all entrys of airlines, military aircraft (and countrys i.e. GAF for German Air Force, GNY for German Navy and so on).

This system exists for many years, MAIW and WOAI are using this, many designer of AFCADs are using this.

Why do you want another system?

Regards

Horst
 
Last edited:
Hey Greg,

why do you wish to create a new system?
Take a look to Martin Gossmanns The Owls Nest. There are all corrected wingspans. He has written a tool to modify the aircraft.cfg.
Horst

Horst,

That is NOT new.. I love that. As I have posted in several other posts. However, it is quite old and is lacking many aircraft. Mine will NOT be a new system. It will be using that as a base and putting in many new aircraft. Also, as mentioned in other posts, some of his numbers are wrong. Instead of relying on USER added data that Airliners.net has (which is where he gets his numbers) I go directly to the manufacturers sites and get the info from there.

So, you don't have to use the new information that I include in my updated list.. I won't be upset. :) I am doing it for me. I will make it public for those that also want the correct information and new planes I include.

Have a great day.

- Greg

Ps...if you had read all the various posts regarding parking (I have read them all) you would see that I am not alone in this. What I mean is many people are finding the current system to be a joke. There IS NO STANDARD for this information and thus, we have all the problems with parking spots that we have. If there were a standard and all was correct, then you would not see 100's of posts regarding parking problems. MOST of them boil down to having to change the information in the aircraft.cfg file AND/OR changing the parking spot size. The list on the owls next even contradicts itself. Look at the recommendations for parking sizes and then look at the data in the list as recommended sizes. So again, that list is outdated and in many cases wrong. And there NEEDS to be a modern standard for designers. Both aircraft and airport. The current method does NOT work. If it did, this debate would never happen.
 
Last edited:
Greg, i agree with you. The basics are the ICAO-code for airlines, aircrafts and the correct wingspan. I think every new aircraft will get an ICAO code.

But there is a problem. You've wrote "Do you release the airport AND include all the ai planes that should be used?".

You will release an airport with all the traffic (and traffic file(s)).
You can release the airport with a lot information how to rename the aircrafts, set the wingspan, set the parking specs and code the airlines.
Or you release a complete package with all the aircraft you put in the traffic files.

An other problem is the traffic. If you are designing a traffic for one airport what should be with the traffic files for airlines (like e.c. WOAI)? Would you have double traffic for them at your airport? What take place to the destination airports?

Regards

Horst
 
As far as the traffic for my airport goes, there wouldn't be double because there is currently NO traffic that goes there. So that problem would be avoided.

I guess we will probably release a full multi-part package when we do it. 1 part will be the airport. 1 part will be the AI aircraft files that go with our traffic files. (yes, with permission) 1 part will be all the needed textures and objects for the airport scenery

The Do Not Read-Me files will just be huge and full of information that no one will ever read about what we have done, and what the end user can/should do if they feel like it to get the most out of our package(s).

- Greg
 
Back
Top