Hi all,
Registration can be really usefull if some of our user are considering there is
too many "children" on the frequency. Ebery body has the possibility to setup
its own FGCom server disabling the "guest:guest" account and only accept
registered pilot on their server.
In this case server admin can choose who can use his server or not. He just
need to add an account for each user he is accepting to use his server.
If you need to restart FGCom, just un-check then re-check the "Enable" checkbox
in FGCom dialog, that's done ! :)
I'm not convinced adding a string is relevant, in real life you haven't a
message you tell you if you are correctly connected to X frequency. The only
way to check is to look at your radio, in FG it's the same.
FGCom standalone is not yet ready for the new FGCom server because he use an
old "positions.txt" file. If you upgrade your server now every OpenRadar/FGCom
standalone user won't be able to connect to most of frequencies and here is my
main problem... FGCom has been created with some bugs and now it's time to
solve them but it require to loose the compatibility with old FGCom. That's
something really hard to deal.
As resume:
- If you upgrade your server OpenRadar/FGCom standalone will be unsable until
positions.txt is upgraded
- If we upgrade positions.txt, your server will be unusable for OpenRadar/FGCom
standalone
- Until positions.txt is not upgraded OpenRadar/FGCom cannot use
fgcom.flightgear.org
As example, today if you use FGCom integrated and you are connected to
fgcom.flightgear.org you need to set 118.175MHz (which is correct in
real life) in order to be connected to Carpentras LFNH Twr. If you are
connected to delta384.server4you.de you need to set 118.170MHz (which is
wrong in real life) in order to be connected to Carpentras LFNH Twr.
As you can see it looks like a headache... I think we are forced to break the
old compatibility for a time (once every client are up to date everything will
works as expected). But this new feature has revelated others projects. If we
choose to develop another communication system we will break the system
again...
A solution could be to release a new FGCom standalone (used by OpenRadar)
compatible with fgcom.flightgear.org with FG 3.0.0. Once FG (and so FGCom)
3.0.0 are released you can upgrade your server.
For information I've create a script which do all the work for you, you just
need to setup a debian system, then execute the script, take a long coffee,
then come back and you have a working FGCom server. The script is available at:
http://clemaez.dyndns.org/build_fgcom_server.sh
I see we share the same worries about the bandwidth, I agree we need to have a
solution for sharing FGCom bandwidth. It seems IAX trunk is the solution but I
don't know how to setup this for now.
@Adrian: feel you free to inform me about your works for radio propagation <->
fgcom. We will see what we can do and if the server side can manage it.
Regards,
Clément
------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
