Proposal/Development For Standalone ATC

[Gijs]

I was just being notified by Martin, that there already is a standalone radar for FlightGear. It is worth to take a look, as it might be better to get involved with that one than start another one from scratch. If you do continue with your own client, you might get some ideas from it...

http://mapserver.flightgear.org/git/git ... =openradar http://foxtrot.mgras.net/bitmap/FGFS/EDDI_closeup.png http://foxtrot.mgras.net/bitmap/FGFS/KSFO_closeup.png http://foxtrot.mgras.net/bitmap/FGFS/KSFO_large.png

[Ozgur]

Hey, this looks great...And looks like Java...Thanks for the information...

[Ozgur]

Hi all...Pilot headings added...Now working on the localizer and markers...That's an easy one i guess...See the screenshot below from EDDF this afternoon...

[jomo]

Let me try to add some comments, warnings and wishes from a "user side of view" - I guess for the tech. aspects there are enough people around!

I guess I got some experience in ATCing at EDDF, TGA, etc. I also had a close look into what VATSIM is doing in that Area. Right now I would believe "VATSIM being the non plus ultra in organized flying". I would love it - especially their Radar-Screens, FlightPlanning, etc. --- BUT:
- see their organization world wide and the (ATC-) manpower they have
- see their required training, grading, qualifying, preplanned duty-hours per person
- strict operation based on flight-Planning
- ATC just sticking to Radar without a direct look into the real picture
- notice their basic operation in 4 layers: GND, Twr, Apr, Center -- and see that they use different Radar Images for those different jobs!!! (there is a good reason for that!!)
- etc
All in all: I do not believe that that is the FlightGear environment - but I believe we (in FlightGear) should get our pilots to be able to easily use that VATSIM-Network for real procedural flying - but we should in no way try to compete with them - just use them for the FlightGear Top-Procedural Guys!

So in Flightgear we should concentrate onto our customers:
- lots of beginners (at least based on "procedural flying")
- many young people having fun and a low budget
- very experimental - daily flying different models so nobody can have loaded all the (new) ones used at a given moment at a given place ("blue/yellow" being the most used unique model)
- etc
So our customers really are anybody, from the very beginner up to the high professional - and many many just flying the biggest planes just with "AutoPilot" and no FlightPlanning at all! If we want to grow we have to accept those and try to convince them of: "There is something more - and it is fun too". That is what I am trying!

Technically I am very glad having 3 sys to use at once (one more than 10 years old - but still being good for Internet/MPmap):
- one ATC(ML of course), that can switch and zoom in into actual operation of a unique pilot
- one MPmap to see the traffic in the area plus the NavAids (if needed, usually just the VOR's)
- one MPmap zoomed in to show the total picture of just the ground operations all the time
- and (sometimes) in the background a second ATC(ML) tuned in to MPserver02, to be able to address those using the MPserver02 (I guess you know our problem in MPserver info-exchange. especially with MPserver02)

So that are my secrets! And in all your discussions I see that many of you (designers) also expect that at least two screens are needed for ATC -- by the way also VATSIM does this to some extend: 1 for the Radar (unique per ATC-job GND/TWR/APR/CTRL), 1 for FlightPlans etc (often merged in) , 1 for the big picture (etc. VATspy), 1 for "ChartView" to easily pop up the exact SID,STAR, ILS, etc. ect. etc. procedures. I guess even "real" controllers do use at least 2 scopes.

I could dream of something like Gijs pointed out: http://foxtrot.mgras.net/bitmap/FGFS/KSFO_large.png
also the http://www.freeimagehosting.net/image.p ... 42a1e7.jpg would improve the situation
Probably the biggest problem I have today, is reading the Target-Lables on the radar-screen! In todays ATC-tools they are mostly unreadable (try it when two near similar target-names are close to each other!) -- but those are much more important to read correct and fast by ATC -- so the colors in the above ".jpg" should be reverse - and even then the above ".png" is much better readable for an ATC in stress!!!

I hope that, whatever you guys finally come up with, will meet my "flightGear-ATC" needs in addition to the radar-picture:
- direct look (non radar!) onto planes on ground (see close up what they are doing, where/how they roll/stop etc - and be able to watch landings (especially for education)
- possibility to select MPchat-messages (inclusive user-codes) by mouse-click (i.e. 2 clicks: 1 select target, second for command - see ATC-ML)
- of course different ranges (at least up to 100 nm) and I would like the possibility to hide Nav-Aids and targets! And/or the distinct colors and brightness as etc. in above KSFO_Large would be appreciated a lot - maybe somebody tests those scopes WITH AI-Ground-Traffic at EHAM and EDDF - and see how good he can distinguish between the unique targets - should be a nice test!
- of course I need support for FGCOM as well as MPchat

--- and lots of ATC's (people!) to be available - and who will stay on duty for hours - even if there is no traffic!
Look into reality: How many MP-Users do we have? How many of them want to fly by rules? How many use FGCOM? How big is the fluctuation? i.e. how much education effort!

Please get me right: I will fully support the efforts testing and supporting the new designs -- but please do not try to reinvent the wheel and do not compete with VATSIM (new scopes = yes, totally organized = NO!!
joe

[D-79]

Hi Ozgur,

I just found out about Martin's and your projects. Both look very promising and it would be great to have them. So please keep up the work and finish them. An alpha release for review by others might be helpful. That is: I'd like to try it as it is to be able to give more informed comments.

I like the following features most of all:
- inclusion of VORTACs etc. - very useful
- clear readability of all information, not as blurred as in the present ATCs
- full-screen radar screen - not as small as the ones we've got now
- it is very good to know the aircraft type, since an ATC needs to know if it's a Cessna or an F-14 that wants to land
- automatic extension lines that indicate the runway heading (in Ralf Gerlich's ATC)
- coastlines (in Ralf Gerlich's ATC)
- visualization of the full airport layout, not only the runways at high zoom (in Ralf Gerlich's ATC)

Suggestions:
Of course it would be awesome if you could add a terrain layer with altitude information ...
We need a press-to-talk-button that communicates with FGcom

It would be a shame that we don't see the actual planes anymore, but only the radar screen - but I guess that's the price you have to pay when you want a full-screen radar ...

I think we do need this in Flightgear. This software package is meant to be a simulation of the real aviation world, and part of that is an ATC who knows what he's doing. At present I use the same tricks as jomo, but it would be awesome to have all the information layered onto one screen, with the possibility to switch on what you need depending on the situation.

Cheers
David

[Ozgur]

Wow! Gentlemen, this topic was dead as i am soo much surprised to see this messages! Thanks for your comments..The well know issues of FG based ATC's, no need to repeat over and over. By time as my thoughts became mature, i realized the uselessness of having other airports view around (in my version) and i did adore Martin's version of graphics. What is working up to now is all navigational aids visible, soon they'll be user selectable so ATC can remove the fixes, vors etc. they don't want to see on their screen.
I have problems mostly with MPNetwork structure, even i'm not so familiar with C programming, i did my best to understand mpserver code and i think i did...And linking with FGCom is already done, and it is not a big deal. Additionally i'm working on using multiple frequency monitoring and usage for FGCom. That is really practical (e.g. PTT buttons are 1 and 2, 1 for approach, 2 for tower etc.). And i had an idea to use "squelch" for fgcom, so u don't actually have to push a button to speak, it can be voice activated...Might be handy feature as long as we don't speak to girlfriend/wife/fellow during ATC sessions.

And my biggest problem: mpchat... Well, the XDR data structure that FlightGear uses over network is something that i still couldn't manage to master. It is well documented thing but i'm not an expert programmer but just authorizing the atc to any mpserver (yes, mpservers must "like" your client to receive and send data) was a deal when i started.
Next: Coastlines and more overlays, such as high obstacles which are marked on official maps.(tower, hill, power lines, chimneys etc). Well, coastlines i suppose shouldn't be a big deal, as long as i can wrap the data, it's ok.
The small stuff: Centerlines, easy deal, no worries. An overlay -user specific- also should be compatible with MSFS "sector" files that gives the atc an overview of all standard procedures as an overlay on the screen.
*sigh* way to make FGRadar for the first release... Also now it uses a "distiller" how i call to change the apt.dat.gz file to improve loading time, since parsing the whole thing (as might first idea to load apts in vicinity) was too much, it has to be fixed. But a single apt with twys and detailed ground is easier to deal as opposed to parsing 20-30 apts in crowded areas, i guess...
-About the real world view, it is impossible for me to include such a thing, BUT, there's always (an experimental) opportunity to have transparent windows (woa) so we can overlay the radar screen on FGScreen and tell FG to show us whatever we want.

Technically I am very glad having 3 sys to use at once (one more than 10 years old - but still being good for Internet/MPmap):
- one ATC(ML of course), that can switch and zoom in into actual operation of a unique pilot
- one MPmap to see the traffic in the area plus the NavAids (if needed, usually just the VOR's)
- one MPmap zoomed in to show the total picture of just the ground operations all the time
- and (sometimes) in the background a second ATC(ML) tuned in to MPserver02, to be able to address those using the MPserver02 (I guess you know our problem in MPserver info-exchange. especially with MPserver02)

That's why you always sound "that" cool on FGCom

Thanks for your inputs and interest to FGRadar. I'll try to make things little more decent and release a test development (highly experimental) version...

[Hooray]

And my biggest problem: mpchat... Well, the XDR data structure that FlightGear uses over network is something that i still couldn't manage to master. It is well documented thing but i'm not an expert programmer but just authorizing the atc to any mpserver (yes, mpservers must "like" your client to receive and send data) was a deal when i started.
Also now it uses a "distiller" how i call to change the apt.dat.gz file to improve loading time, since parsing the whole thing (as might first idea to load apts in vicinity) was too much, it has to be fixed. But a single apt with twys and detailed ground is easier to deal as opposed to parsing 20-30 apts in crowded areas, i guess...
-About the real world view, it is impossible for me to include such a thing, BUT, there's always (an experimental) opportunity to have transparent windows (woa) so we can overlay the radar screen on FGScreen and tell FG to show us whatever we want.

Seems like a DEJA VU, look what I told you half a year ago:

Just imagine how complicated this really is: at some point you may need to deal with map projections, parsing and creating XDR encoded multiplayer packets, adding a GUI and possibly even scripting?
You will need to parse the navigational databases, as well as scenery/airport data.
And that's not even all that is needed.

All of this is however already supported by FlightGear or SimGear.

Don't even think about what's happening when FlightGear eventually upgrades its multiplayer system, any separate tools will need to be separately updated.

You are bringing up a "tower look", don't you think that whatever you end up doing in a program created from scratch will be far inferior to what FlightGear is capable of doing? Just keep in mind that FlightGear is already using a fairly mature scenery engine internally, you are very unlikely to create more compelling visuals in your program, I am afraid.

[Ozgur]

Well these are the challenges, but i think they are challenges for me, a small programmer that needs to study XDR packets. But do you agree with the idea of having a separate radar app, since most ATC's find it difficult to use some features...For example no navigational aid appears on screen, which in turn can ease the atc's duty. Since simulation means, making it as close as possible to real life, i think there's need for such a thing. Hard or easy...

[Hooray]

Note to all contributors: For the sake of keeping things organized, we have decided to continue the discussion here: http://wiki.flightgear.org/index.php/St ... evelopment