There are really many people interested in this aspect of FlightGear.
Unfortunately, pretty much every single person has a different vision and different ideas on how to improve FlightGear's virtual ATC support.
The wiki page I pointed you to, is an attempt to streamline the whole process.
Besides, some people who kicked this off a couple of weeks ago, now also have to deal with real life obligations.
All people interested in this also have different areas of expertise and different interests. While that is generally a good thing, it also makes the whole thing challenging.
The programmers interested in this have had discussions on different programming languages, GUI toolkits, feature sets and lots of other things.
So there are definitely many ideas, possibly even too many ...
If you are interested in these, I would be glad to forward these to you.
So far, the general consensus has been that it would be easiest to customize the atlas moving map tool, by making it more configurable:
http://wiki.flightgear.org/index.php/Atlashttp://sourceforge.net/projects/atlas/This is because atlas is already implemented in C++, and because it is already a fairly established and mature code base.
Atlas uses internally PLIB's PUI library (as FlightGear does), but there are plans to replace it eventually with FLTK.
The idea is to extend an existing program, rather than creating something completely from scratch.
Brian, the atlas lead developer is also registered here on the forums (bjschack) and Brian has been very supportive of the whole idea.
We have sketched out specific steps on making atlas usable as a virtual ATC client. The initial work will be mostly focused on making some UI elements optional, and adding a handful of others.
So in the beginning, some of the hard-coded defaults, would need to become more configurable - e.g. by using configuration files instead of "magic numbers"
One major milestone would obviously be adding multiplayer support to atlas eventually. Brian mentioned already this would be on the roadmap for atlas.
If you are not yet familiar with atlas, my suggestion would be to download it and see for yourself how it is working, and maybe how it could be changed to become a radar client.
The wiki lists already some things that we discussed, see specifically:
http://wiki.flightgear.org/index.php/St ... ATC_clientAs you will probably see then, all the hard stuff is already taken care of in atlas (e.g. map projections, rendering and such).
So it really depends on whether you share the impression that atlas could be used here as the underlying platform, instead of coming up with something completely new.
Drop me a message if you are interested in further details.
Also, if you should be interested in getting involved, it would obviously be a good idea to download the atlas source code and set up your build environment to be able to build atlas from source.
We have a dedicated atlas sub forum here:
viewforum.php?f=31But there is also the official atlas mailing list:
http://sourceforge.net/mailarchive/foru ... tlas-develYou can browse the source tree on line:
http://atlas.cvs.sourceforge.net/atlas/For windows build instructions, some help is available at:
http://geoffair.net/fg/fgfs-049.htmObviously, it would only make sense to pursue this idea if you manage to build atlas from source...
On the other hand, OpenRADAR would apparently not need many additions to be directly usable "as is", a competent C++ programmer should have no problem dealing with the Java source code and taking up maintainership. There are a number of FG related projects that are Java based, and there is also lots of code that could thus be borrowed from other projects.
So it really boils down to how you would prefer to spend your time