I am one of those who wants the single player FS experience with better ATC.But having written some approaches in XML for FS2004, I fully understand the statements of P-12C about the increasing complexity and testing level to add STAR and to a certain extent DP/SID procedures.The area in which FS2002 controlled AI was approximately 42 miles from the user aircraft. That was barely sufficient to allow aircraft to descend from cruise altitude and make the runway.In FS2004 that area is up to 108 miles in some airports / airspaces. It is large enough that international boundaries limit some airspaces.I don't have European STAR/SID charts handy right now - but let's just look at KORD as a representative.The STARS and their origination points are:BRADFORD FOUR - Kirksville MO VOR - 238.5 nmJANESVILLE FOUR - Mason City IA VOR - 250.0 nmKNOXVILLE THREE - Briggs, Ohio VOR (Akron) - 297.5 nmKOKOMO ONE - Kokomo, IN VOR - 120.4 nmPULLMAN FIVE - Flint, MI VOR - 193.4 nm / Traverse City, MI VOR - 194.3 nm / Salem, MI VOR (Detroit) - 195.3 nmSo that tells us we cannot do STARs at KORD unless the ATC is controlling and vectoring all aircraft at least 250 nm away from KORD.Someone good at math tell me the difference in area of a circle 108 miles in radius and one 250 miles in radius. That's how much bigger the area of ATC control has to be.KORD has one departure - with end point VORS at a little less range.But here are some of the additional airports which will have to be active when you are at KORD:KSTLKMSPKSDFKDTWKCLEKCVGNow that's O'Hare.For KDFW the STARS start at Little Rock, AR - 263.9 nm / San Antonio, TX - 214.7 nm / Wink, TX - 319.5 nm / Jackson, MS - 353.6 nmOne DP/SID - COYOTE FIVE goes all the way to Tucumcari, NM - 354 nm another to Meridian MS - 420 nm.An example on the other side of the pond:If you are at London Heathrow - the AI traffic up to 350 nm away which will impact your performance will include:EHAMLFPGEIDWEDDFEGCC and almost every other airport on Great Britian and Ireland as far away as Shannon and Edinburgh.I have a mixed group of AI based on the Ultimate Traffic with PAI, World of AI and various individual flight plans and AI aircraft loaded. At KORD that is about 400 aircraft at 10:30 local tonight.The active airports are:KARRKCGXKDPAKENWKGYYKJVLKLOTKMDWKPPOKPWKKSBNKUGNAt EGLL that runs about 800 AI aircraft active on my system.Airports with traffic include:EGBBEGBEEGGWEGHHEGHIEGHPEGKAEGKBEGKKEGLCEGLFEGLKEGMCEGSCEGSSEGTCEGTKEGUNEGVNWhen you are at KLAX - Las Vegas and San Francisco will be active airports.While active AI aircraft in the air outside the visual range have a minimal impact on performance - increasing the ATC control zone to include SID/STARs would be potentially an 8 fold increase - which must have a noticable impact.Not to mention parking. A major cause of stutters can be AI aircraft without sufficient parking at their airports. Just reverting the EGSS back to the default airport cost me about 20-30% of my FPS at EGLL due to the cycles of FS trying to park those aircraft.You will have to have good AFCAD files / additional parking for all those airports to avoid a slide show.Now this is just the impact of adding STAR/ SID to FS caused by AI aircraft.I haven't even considered the routing issues and requirements.Turboprop and piston aircraft are generated closer to the destination airport and user aircraft than jets.If turboprops are generated 200 nm from the airport - will the ATC tell them to reverse course for 150 nm to pickup the STAR.I cannot see how they could handle the many entrance points for a STAR, or exit points for a SID without basically custom programming for each SID and each STAR - worldwide.It's not just adding a few voice files.Now I would like to have the voice files and that we could file SID/ STAR and have the FS ATC pronounce them in the clearance.I'd prefer that rather than telling me to change heading 50 degrees and change back a couple minutes later - the ATC would tell me "Cleared direct to Bonham VOR"I can live with the AI aircraft being directed in on vectors,

Nice post, Reggie...I think that makes the difficulties pretty plain. Adding that much more range, even for small amounts of traffic (much less the mass numbers we know some users will want!) will just add too much complexity to work out.What if we set up entry points along (or beside) airways for the aircraft to be generated closer in? We can still say that they're "following" a STAR approach, even though they popped into being halfway along it. Add to that the ability to limit the amount of time between generations at each point, and segregate approaches between jet, turboprop, and GA traffic. If we could do that, it would go a long way towards spacing out approaches...although departures would still foul up the arrival spacing...perhaps cut off arrival generations when a go-around limit is reached?-Ivan

Spacing out aircraft on aproach is a separate issue.There must be some mechanism to maintain separation - either with speed commands or turns. FS2004 can start separation quite well on approach.Currently you can watch the system as separate entry points for an approach for five aircraft for each approach - about 7 nm apart are used.When you add a sixth aircraft - it gets assigned to the first point. Now you have two aircraft assigned to a single entry point. At some airports this can get to four or five aircraft with "realistic" traffic files.I certainly not the smartest guy studying this for the past two and a half years - but at some point the system is either going to have to double up aircraft, or delete the extra aircraft.Those five entry points can stretch out almost all the way across the island of Puerto Rico.FS does make some differentiation on departure based on engine type and aircraft empty weight. Unfortunately the weight deal works only for jets - having the DC-7 treated like a Skyhawk in takeoff runway selection can be distruptive at times.The thing we have to remember about changes like these - they have to be applied to all 24,000+ airports world wide. The logic and fallbacks have to be there for every airport.Now today in FS2004, we can easily tell the program to ignore all the default approaches. That's how we add new ones, change the approaches to match changed runway designators, etc.But we don't want to write addon approaches for every airport in FS before it will work.

Exactly, there's simply no way we ould be able to put together a list of approches that large in a reasonable amount of time, but I would think that many of those airports are small strips without complex approach procedures. At this point we kinda need to better define the problem and investigate just what we're up against, and how to shrink it down to a reasonable level.One of the biggest problems with airport traffic is the seemingly unavoidable desire by every FS addict out there to "turn the amps up to 11", and set traffic at 100% immediately. The ATC system doesn't do too terrible if there's a reasonable amount of traffic, but if 25 aircraft are generated at the same time, there simply isn't any way to handle it all. We need some sort of safety valve to handle overload conditions, whether it's a holding pattern ATC can send excess aircraft into (although I've heard the complaints about FSsmooth) or speeding up the AI landings, or simply halting generation at a saturation point based on the number of runways. We're not going to get people to turn down the sliders, so there simply has to be a limit made, even if it is an unrealistic one.As for differentation based on weight, maybe a second setting would allow for more of the exceptional cases...first category of jet, turboprop, or prop; second category of airline, commercial, or private. That way your DC-7 example might be a "prop, airline", which would seperate it from a "prop, private". You almost need to do that now anyway because helicopters and seaplanes will have a bit more prevalance in FSX...we may need to add a category like "prop, helicopter", or "turboprop, seaplane" to change the way ATC deals with those items.Sorry, Reggie...I'm really a newbie to playing around with the ATC settings, and I'm just trying to brainstorm. So far about all I'm seeing is a lot of brick walls to bumping up the realism. There are some very large challenges to overcome, but the first person to build that better mousetrap...

FDE unification for AI can solve the problem a bit - I mean identical FDE for regional jets, small, large, huge jets. I know it's quite unrealistic to have landing speed of 140kts for 747 and CRJ200, but as far separation concerned it works GREAT. That's what I did with ALL my jet AI. FDE for default B734 works just great (with modified contact points and light sections). AI Turboprops is completely different song. Brodly speaking about FSX perspective, my one and only hope is SDK. ACES people stated very clear that ATC and AI behavior both weren't touched at all.

The first and largest brick wall is the concept of "realism".The FAA and countries around the world and a lot of very talented people cannot design a computer controlled ATC system - and have spent tens of millions of dollars on it. More than has been spend on all the version of FS.Also, even the huge commercial simulators do not have the entire world in them, nor to most of them have automated ATC - rather a real person.That's a key and I understand where P-12C's blog is going. The only way to have real world flexibility is to have real world type ATC control - by real people.Anything 100% computer controlled is going to be an if/then/next logic tree - and at some point a situation which was not for seen will come up. In FS we have stupid looking approaches, in the real world people die.The "realism" aspect of traffic volume is one which most FS AI fanatics do not want to accept. MS can write a program to handle an anticipated volume of traffic. Personally I think it's too small at this time...However, the question is how to handle the over capability volume which someone will add to their sim.Today FS works on the - "Okay you did it, live with the pain you created" attitude - and tries to fly every aircraft.I am absolutely certain I would be strung up by my thumbs and beaten with a horsewhip on every AI forum across the web is MS adopted my other consideration and deleted the extra AI traffic.No matter how much it improved AI traffic flow.To many people "realism" is every single aircraft of every single airline landing and taking off on time - and the computer program darned well better be able to handle it - or 10 times that if they wish.To others it is a reasonable representative sample of the real world.FS isn't to the second point yet, and due to the screams of the first group - the ACES team might have considered the entire concept not worth the trouble.

Common flight dynamics is a GREAT help and how most of the AI on my system runs.

And everyone knows that things always go smoothly in the real world, right? :-rollhttp://www.mirror.co.uk/news/tm_objectid=1...-name_page.html

>>To many people "realism" is every single aircraft of every>single airline landing and taking off on time - and the>computer program darned well better be able to handle it - or>10 times that if they wish.>>To others it is a reasonable representative sample of the real>world.>>FS isn't to the second point yet, and due to the screams of>the first group - the ACES team might have considered the>entire concept not worth the trouble.I don't think the "screams" (if that's right) are due to FS not providing "DC to light" ATC coverage, but rather that ATC might be left to whither, rather than seeing incremental improvement/features.I see your point that if AI becomes more "channelized" onto STAR routes that separation becomes more difficult, but it seems like it can be considered a variation on the "entry point" scheme of directing AI to an approach. I'm more concerned about the user aircraft being able to run the STAR, though. It will be interesting to see what the ATC tower mode will actually provide. Hopefully it is more than a plan view of the traffic explorer.scott s..

I'd be very happy if the FSX SDK lets Radar Contact control the AI planes so that RC can completely manage the ATC. With dual core RC could run on a seperate core and so I dont think there could be much of a performance hit for FSX. If anything, FSX might even get better FPS because RC would be doing on the ATC "thinking" on a seperate core.Also, I release the communication between RC and FSX might not be instantaneous as it would be if FSX is doing the ATC, but isnt this the case in real life anyway. I mean ATC issues a command to an aircraft, eg "QANTAS 123 change course to 180, descend and maintain 10,000", it probably takes the pilot a few seconds initiate this request (ie setup the MCP). FSX is already managing the FSX ATC requests for the AI, ie you will see the AI change course, altitude based on FSX ATC, im just saying let some external program (eg RC) think about the all ATC (ie Airways,SIDs,STARs etc).Maybe FSX can already do this, we just dont know yet, surely if RC are beta testers they would have asked ACES to make the ATC/AI SDK much more powerful so that they can implement better ATC outside of FSX.

You know, you're completely right. No improvements should be made towards this end. Except maybe when the 10Ghz processor comes out. Maybe microsoft will consider trying to add this with Flight Sim 17. By then the voices will have been recorded (no need to fiddle with EditVoicepack), and the entire world ATC system can be modeled correctly.