Talk:Stand Alone ATC Control Development

Clean-up proposal

Would it now not make sense simply to remove this page? Generally speaking, I do not think we should keep pages like this one, that group everything under an "old junk" title at some point and start over writing at the top—isn't page history the right way to browse back in time if desired? I know it can make sense for development wikis, but in my opinion none of this information is still relevant to the current situation.

depends on your priorities I guess - there's a ton of feedback preserved here, some things may have been addressed by OpenRadar/ATC-Pie recently - but others not so much. So I would suggest to mark this as "outdated" with pointers to OpenRadar/ATC-Pie, and maybe review individual sections to see if/how those are addressed by those two ATC clients. But otherwise, I am still aware of related efforts where people want to provide certain functionality directly inside FG, e.g.:

* ATC-FS

* ATC-aircraft

* Canvas Radar

Equally, someone once mentioned that creating a TRACON/tower-based ATC client would inevitably benefit from being based on/built into FlightGear itself - these days, this is very feasible, thanks to Canvas and specifically Gijs' MapStructure/ND which could be considered the foundation for anything built right into FG. For instance, Category:AWACS aircraft could actually have a Canvas-based Radar showing AI/MP traffic. --Hooray (talk) 07:58, 21 April 2015 (EDT)

New ATC software proposal

Just in case anyone is watching this page: I have started working in Oct. 2014 on a new ATC program for FGMS, and it is now stable enough for beta-test and so forth. Contact me whichever way you like if you are interested in trying it out. --Mickybadia (talk) 22:40, 14 January 2015 (UTC)

fgms requirements

"FG multiplayer protocol needs to add support for 1. broadcasting on VHF frequencies, 2. private messages between clients." (reeed)

I guess, that for the time being, we'll have to work with the restrictions of the existing protocol, getting the current protocol to work with atlas will be enough work, as is. But it might be a good idea to add those feature requests to the fgms tracker or the Distributed Interactive Simulation page for the future. --Hooray 15:15, 22 September 2010 (UTC)

XDR processing

The UDP protocol / XDR stuff is relatively easy -- I have working python code I'm happy to share. (I wrote a little bot that connects to FGMS and responds to pilot requests "!metar ICAO" by fetching and returning the METAR for that ICAO code.)

The neat thing about basing everything on atlas will be that we can directly reuse the fgms source code for dealing with those details, that should make things much easier than doing this in scripting space.--Hooray 15:15, 22 September 2010 (UTC)

handling flight plans

"A core requirement for a serious ATC system is the ability to handle pilot flightplans. Visually, the ATC client can display a 'flightstrip' (like the paper strips of olden days) or an electronic equivalent. The stack of flightstrips represents the controller's workload. Upon handoff of traffic to another controller, the flightstrip follows." (reeed)

I think, we could use one of the flight planning tools to create flight plans. Internally, Atlas is based on PUI (PLIB GUI), so one could create a custom dialog that resembles a flight strip, that should be easy to do. And creating a stack of flight strips would then show a stack of these dialogs --Hooray 15:15, 22 September 2010 (UTC)

I was thinking more about the data structure representing an ATC flightplan (of which the flight routing is but a mere ASCII string eg "DCT VTK - A464 - VPG - WMKP"), not the GUI. This data structure requires 1. ownership (eg this acft is currently 'owned' by KSFO_TWR), 2. transferability (this acft is now handed off to KSFO_GND). Where should all this state info reside: on fgms? on the standalone ATC client? inside every individual UDP packet (10 Hz)??

Okay, I see. I was just talking of reusing and importing FG flight plans, e.g. from kelpie. But this is now really heading into the realms of virtual ATC *networks* (i.e. vatsim/ivao), and not just a virtual ATC client anymore. Personally, I think we should concentrate on the virtual ATC client aspects for the time being (i.e. GUI enhancements required). FlightGear is not going see hundreds of users doing ATC anytime soon. So the "problem" is currently sort of academic. Surprisingly, this would seem relevant in the context of the mentioned "AutoATC" project, which supports autonomous ATC handling. So one could possibly hand over control to a "virtual controller" (AI). But I agree, that would probably require a distributed architecture with clients supporting p2p communications to hand over control between different clients (controllers and sectors), no matter if human or AI based. If you want to look further into this, I'd really like to know how this is handled by vatsim and ivao, do they have their own distributed "atc networks" with support for inter-client communications? I guess there must be some sort of central server handling communications and flight plans? But really, let's try to walk before we start running, okay? :) Just having a virtual ATC GUI client would be an important step in itself. Modeling the real life work flow between different controllers and sectors would probably be over-engineering right now. Still, it's definitely worthwhile to keep these things in mind. I suppose, one would need to come up with a fgms-like server program for ATC? --Hooray 06:52, 23 September 2010 (UTC)