[Flightgear-devel] FlightGear voice communication
As a point from a user: I am getting very worried about this discussion about every body has the possibility to setup his own FGCom server disabling the guest:guest account and only accept registered pilot on their server. To my knowledge this issue has been discussed for FGFS very extensively already several times - and it was decided not to do that. For FGCOM I would be against that even stronger - because with FGCOM we want to attract more and more users to use the multiplayer environment - I guess such restrictions will achieve the opposite: - I myselfe would have problems to open again another (or even many!) world wide accessible account(s) - with my data stored by unknown people on unknown servers with unknown security! I guess you all heard about the current security issues being raised right now worldwide (NAS, Facebook, etc etc pp) - and: what would it really help? As described that bad guy can always get a new account - and bad words are not as bad as bad security. - till now I see FGCOM as the ideal tool for multiplayer because of the limited range with many realistic frequencies - but still being able to talk worldwide to anybody! (there is already now a (little) problem having just two FGCOM servers! - How shall that work in future? Changing the server for each multiplayer event? And prior to that investigate which users are permitted? Or whenever you go to another airport? Or country? How do you explain the pilots how to do that and when and why? Would'nt it be easier then just to use e.g. mumble (at least there you can change the group on the fly - many users ask us (ATC'S) already now to use that easy to handle tool instead of the realistic but complicated frequency changes in FGCOM! - etc. -etc And believe me: Doing ATC at EDDF for 4 days a week with 4h each session I know that problem of babies all the way from nice kids being unable to communicate with grown ups up to using absolutely abusive language! There is only one solution to that: Warn them, then neglect them, ask all others to neglect them too -- and most important: Do not even try to discuss with them! Come to EDDF and you will see: It works!! Also remember: We have the Neglect-button in the PilotList - use that also for FGCOM to blank any user out you do not want to hear! And that decision may be kept for each user himself! And it works within seconds - just compare that to the needed administrative efforts to get somebody removed/locked from a server! Please - please - do not kill the very positive social aspects of the multiplayer environment because of a few misbehaving people! Thanks for working on improving the FGCOM - I like it - see how it gets used more and more on: http://www.emmerich-j.de -- EDDF-Triangel Movies! -- 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=48897511iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear voice communication
Hi Clément,
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.
seams we have different experience in fgcom. And there will be no indication of
the intersection problem? pls be so kind and approach a intersecting frequency
from the the intersecting side.
[intersecting frequency]course[target frequency]-
and try to communicate with the target frequency.
I agree that in real life there are no problems.
But in reality we are sitting in flightgear and want to improve the fgcom tool.
Which has some borders:
- selecting a chatroom by frequencies
- from the source(apt.dat) of the frequency position
The question is how to deal with that to improve the simulation grade of
flighgear.
I don't discus the update process of the apt.dat here, but how log it will
take to update the frequency intersection errors ?
I don't understand the purpose to communicate with a ground frequency over a
distance of 100nm.
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.
connection(trunking) 2 servers will not save any bandwidth it raise the total
use.
client1 -- server1 == server2 -- client2
Let the client dial the server direct. The sum of traffic is not raised and
split to several server.
client2--server2-- client2
Then anyone can setup an fgcom server and handle as much frequencies he can.
Also Your server at home could participate in the production operation.
dialbook.select(position, frequency, host, phonenumber){
...
}
fgcom.dial(user,password,host,phonenumber){
if( lastHost != host ){
iaxc_register(user, password, host);
}
iaxc_call(phonenumber);
}
Regards,
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=48897511iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear voice communication
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=48897511iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scripted installation
On Fri, 23 Aug 2013 21:28:28 -0400 Pat pat.callah...@gmail.com wrote: On Fri, 23 Aug 2013 17:14:34 -0400 Thanks, We can change this in a future version unless you are still having trouble... I get no error now, just a redirect: svn -r 2172 co http://svn.code.sf.net/p/plib/code/trunk Utrunk/src/ssg/ssg.h Checked out revision 2172. -Pat By the way, I noticed there is a 2173 revision, but it changes only ssg which we do not use. We'll include this in thu about to be released script version 1.9.12 -Pat Callahan Wil Neeley bentchic...@gmail.com wrote: I fixed it by editing line 449 to svn $PLIB_STABLE_REVISION_ co https://svn.code.sf.net/p/plib/code/trunkplib Wil Neeley On Fri, Aug 23, 2013 at 5:12 PM, Wil Neeley bentchic...@gmail.com wrote: When running the scripted installation on Crunchbang I get the following error. svn: Repository moved permanently to ' http://svn.code.sf.net/p/plib/code/trunk'; please relocate How can I fix it Wil Neeley -- 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=48897511iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
