Clément, > The easier solution is the last one, it can be really easy to implement this > in FGCom standalone/integrated and totally transparent for our users. As > example, we can decide that > fgcom01.flightgear.org handles frequencies 118.0 to 124.9 > fgcom02.flightgear.org handles frequencies 125.0 to 131.9 > fgcom03.flightgear.org handles frequencies 132.0 to 137.0 > > A simple test in FGCom standalone/integrated could be: > if (freq > 118.0 && freq < 125) > server = fgcom01.flightgear.org > if (freq > 124.9 && freq < 132) > server = fgcom02.flightgear.org > if (freq > 131.9) > server = fgcom03.flightgear.org > > We can also check if a server is up or down and skip it if needed, and > redistribute the frequency flow on remaining servers. All of this is doable > and totally transparent for the user. > > @Dirk: I would have your agreement to do that, is it ok for you ? pls no hard-coded server decision. Implement a dial book which reads a file(cvs) like: ID,icao, frequency, lat, lon, type, name, range, server, phonenumber
The entity should be the radio station. We have to manage the bandwidth so selecting server by frequency will not really fit. In future it means exchange stations between servers to balancing the load. The fgcom client can download the dialbook on start up, so we can provide a fast update rate. may bee http/git/terrasync. A main question is which source we use. IMO Where is fgcom relevant. On our most atced airports ! There are atcs who dealing with the matters. So if there are frequency problems they would fix it if they could. I think we have the power to manage our own dialbook Database. We should start with the actual version of the postions.txt get it in our next dialbook DB and then manage it through git merges. So we can get much faster closer to reality(at our atced areas). updates through apt.dat would be a hard thing. I cant see a mistakeless update process. apt.dat => unique dialbook_ID my bee ICAO & Freqency & Type = dialbook_ID > > > We have the "Neglect"-button in the "PilotList" - use > > that also for FGCOM to "blank any user out you do not want to hear"! > > Unfortunately this is not doable... at least, not doable without a > registration system. I agree it is impossible unit flightgear has a unique user id. dirk ------------------------------------------------------------------------------ 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
