Talk:Stand Alone ATC Control Development: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(responses)
No edit summary
Line 7: Line 7:
"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)
"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 --[[User:Hooray|Hooray]] 15:15, 22 September 2010 (UTC)
: 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 --[[User:Hooray|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)??

Revision as of 06:33, 23 September 2010

"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)

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)

"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)??