Stand Alone ATC Control Development: Difference between revisions

Jump to navigation Jump to search
(VATSIM's ATC clients)
Line 21: Line 21:


=Customizing [[Atlas]] for use as an ATC client =
=Customizing [[Atlas]] for use as an ATC client =
In the scope of the ongoing ATC discussion, we have also talked about extending [[Atlas]] to use it as the foundation for a standalone ATC client, concentrating on a maximum degree of code reuse. This is a fairly old idea, which has already been suggested 5 years ago: [].
In the scope of the ongoing ATC discussion, we have also talked about extending [[Atlas]] (a moving map utility) to use it as the foundation for a standalone ATC client, concentrating on a maximum degree of code reuse, where we would only need to customize atlas for ATC use. This is a fairly old idea, which has already been suggested 5 years ago: [].


It seems, that most of the existing atlas features could be used for ATC purposes, too. While only very few new features would be needed that would require changes to the C++ source code. This would make it possible to generalize the atlas code some more, so that using Atlas for ATC purposes would merely be a different "mode".
It seems, that most of the existing atlas features could be used for ATC purposes, too. While only very few new features would be needed that would require changes to the C++ source code. This would make it possible to generalize the atlas code some more, so that using Atlas for ATC purposes would merely be a different "mode" of running atlas.


For the time being, the most important new feature for atlas would be multiplayer support.  
For the time being, the most important new feature for atlas would be multiplayer support, which would require support for decoding FlightGear's Multiplayer messages, which are XDR encoded packets. The corresponding C++ code is readily available in the [[fgms]] source code and could be reused.
Most of the other changes would be about making atlas features either more configurable (i.e. moving hard coded defaults out of the C++ source code into configuration files, plain text or XML based), or about provididing an option to completely disable other features.
 
Dealing with XDR encoded packets is something that has proved difficult for a number of similar efforts, so the possibility to directly reuse the fgms code seems promising.
 
Most of the other changes required in atlas would be about making certain atlas features either more configurable (i.e. moving hard coded defaults out of the C++ source code into configuration files, plain text or XML based), or about providing an option to completely disable other features.


== Required enhancements ==
== Required enhancements ==
* multiplayer support
 
* multiplayer support (i.e. processing XDR encoded FG MP messages)
* possibility to customize appearance for typical ATC use  
* possibility to customize appearance for typical ATC use  
== GUI related changes ==
Priorities:
* '''P1''' - essential feature
* '''P2''' - highly useful feature
* '''P3''' - option feature
* '''P4''' - experimental feature


== Open questions ==
== Open questions ==

Navigation menu