You have to contact Wolfram, the OpenRadar maintainer, I think what you are reporting is not an FGCom problem but an OpenRadar problem.Also I'm not an OpenRadar user I have no clue how it works / what he does. I previously suggested Worlfram to integrate a copy of FGCom in his OpenRadar release I don't know if it's on his todolist or not. I'm sure it will simplify the life of our OpenRadar users.

Good evening,Time for me to jump in, sorry, I did not know, that I might be needed.

We are facing several problems because of incompatibilities between the tools. Clement, please correct me, if I am wrong!

At first: The new server fgcom.flightgear.org is downward compatible, supports the old and the new version of FGCOM.

The FGCOM 3.0 client is sending sometimes slightly different frequencies as before. These new values are not supported by the old FGCOM server. So the old servers will not accept it.The new server accepts old and new fgcom frequencies.

OpenRadar is prepared to support FGCOM 3.0. But, currently this support is not active, because there are many ATC contacts comming in with older versions. As I said above, only the new server suppports old and new fgcom clients. We tried it but had many troubles because of the small incompatibilies.Changing this compatibility from old to new, means too, to use a different source for the frequencies of the airports. This is the reason that you Ross still have only one frequency available. FGCOM 3 will really bring some more for EHAM.

So for you, it should work to tune OR to fgcom.flightgear.org and set the frequency manually. So you will work on the new server. You will have to ask all incomming traffic to set their FGCOM clients to the new server too. Then you will be able to talk. It is not required to use the new FGCOM client , but you can use it (as much as I know it).

A final solution to these problems is to ask everybody to forget the old servers and use the new one. Until now, fgcom3 was in a beta/RC stage for me. Is it really ready for being used? Is the server stable (ok it is up for 80 days now) and has enough bandwidth to be used by everybody, Clement?If so, people should be invited to change at a specific day on all possible ways, latest when FGFS 3.0 comes out.

F-JJTH wrote in Wed Dec 11, 2013 6:11 pm:You have to contact Wolfram, the OpenRadar maintainer, I think what you are reporting is not an FGCom problem but an OpenRadar problem.

I really wonder about that answere from the responsible engineer! That problem is known and reported to engineering already several times! e.g. from me already on 11.Oct.2013 "Download and install the "fgcom-2.99.0_Linux.zip" - the download works - but when starting it I still get:.."/ - and followed up several times - even with the solution on 28.Oct2013 by me. The problem is a different start-command for the new FGCom-version. That is:

for the current, functional FGCom: "../fgcom/bin/fgcom"that in the FGCom(3) must be: "../fgcom/bin/&& ./fgcom"

As it is now no existing application (e.g. FGCOMGUI, OpenRadar, etc.) can start that new FGCom-version without changing it's code - and thus preventing the operation of the since years used FGCOM! To my knowledge it is not a big deal to enable the Start of the new version the same way as the old one was! I have no idea why enginieering insinsts to have no compatibility between the old an new version.

For your actual problem, there are the following solutions:

you can use the new FGCom version you downloaded in OpenRadar with the "Setting: External...." instead of "Internal" (i.e. you start your FGCom as usual and then start OpenRadar)you can use the old version as well with the OpenRadar Internal as External option

You are correct almost for all Just one point: FGCom 3.0 is also compatible with the old server but _only_ for frequencies ending by the wrong 120.170 (instead of 120.175) and 120.120 (instead of 120.125)The hack is really not elegant but necessary:

Of course there still some incompatibility because FGCom 3.0 is using a recent apt.dat file from x-plane, FlightGear 3.0 will be delivered with this same recent apt.dat file so it become clear that the old server will be outdated if he still use the apt.dat file from august 2008.

For information I sent all the necessary informations and files to Dirk (the maintainer of the delta server), that way he can update his server. However I don't know what is his plan.

You are correct almost for all Just one point: FGCom 3.0 is also compatible with the old server but _only_ for frequencies ending by the wrong 120.170 (instead of 120.175) and 120.120 (instead of 120.125)

This is what I meant.

I see only one way out of this situation: Update all FGCOM servers in use to the new server, that can handle old clients and (propably almost) all old frequencies.Second I can change OR to the most recent frequency file too and the clients are free to follow in their pace...

I am glad that the necessary bandwith has been reduced to handle a lot more clients. But a question from a guy outside VoiP: We should came to a situation, where there are several servers for fgcom which can work with each other, so that one can call an ATC at the other server. Is this currently not possible because of an incompatible implementation or is this simply not set up?

Quick answer: it is not currently setup because I don't know how to do it.You know, I'm not ingeneer, I not working in computer science, I never studied computer science at school, I haven't 20 years of experience in computer science. So yeah I have a lot of missing skills, but I try to be better day after day