Talk:FGCom (before 3.0)
FGCOM - feature request
Well thanks to some very hard work by some talented people and a clueless tester FGCOM has moved ahead a great deal in the past few days. Now it is cross distro and possibly even POSIX compliant, we have a possible Openal based system which should simplify things a lot and tie in well with existing work. Work goes ahead on implementing a PTT switch and appropriate muting.
However we still have a little way to go to realistically emulate VHF aviation comms. Because we are mapping frequencies onto conference call numbers (lets leave the range aspect alone for now), two or more stations can talk at once. This isn't how it works in Real Life, only one aircraft or ATC facility can talk at a time and if someone insists on talking or the PTT switch becomes jammed on, then there is not a lot that can be done about it. Nobody else can use that frequency until the pilot stops talking or his radio is switched off. There are good reasons for this, not least the dreadful sound quality of the original radios, the sometimes life-or-death nature of the information being transferred meant that having only one pilot or controller talking while everybody else listened was A Good Thing.
This is a feature request because, much as I'd like to, I can't deliver the necessary code.
I'd like to see this highly able asterisk system crippled so that only one caller can speak at a time - To get round possible abuse of this, any caller is only allowed a max of say 30 secs (more than enough for any realistic aviation comms) before their call is terminated and they have to rejoin the conversation (come back up on channel)
Is any of this feasible?
--Willie 06:51, 25 November 2007 (EST)
Voice Quality --its too good and its not good enough ;-)
At present we are having lots of echo testing. This may be down to extremely cheap, oversensitive mics at my end but in general it just doesn't sound like the real thing. We have distortion but its the wrong sort. Not sure how to sort this but a first attempt would be a tight narrow pass filter and possibly mixed with a white noise source to give that "radio" sound. Could get fancy and add a definite "click" as the PTT is pressed at the beginning of a call and also when it is released.
--Willie 06:51, 25 November 2007 (EST)
New FGCom require a lot of changes in documentation
FGCom was a separate project for many years, but now FGCom is integrated into FlightGear (even if the standalone is still available)
We need to differentiate the built-in FGCom and the standalone FGCom, that I usually call "FGCom-sa" (sa = stand alone)
It is also important to strongly suggest to use the built-in FGCom as many as possible.
FGCom-sa must be used only for those who want to run FGCom on a separate computer than the one who run the FlightGear session (this case is certainly extremly rare ! even enough rare to be ignored I think)
The question is: how to re-organize all the documentation about FGCom ?
My opinion is: FGCom standalone is destinated to be used only by OpenRadar and no longer destinated to be used with FlightGear. OpenRadar will be soon able to provide FGCom standalone into his package, that way FGCom standalone will be no longer a "required dependence" for OpenRadar. So all documentation about FGCom standalone will be no longer interesting for 99% of our users (FlightGear and OpenRadar). Only people who want run FGCom standalone (those who want run it on a separate computer certainly) will be interested by some documentation, I think the fgcom --help would be sufficient for these people who certainly have some computer skills if they want to use FGCom standalone "by-hand" (without FlightGear or OpenRadar).
As of today, the FGCom documentation looks like a big mess, not because the documentation is wrong (most of the documentation is correct) but because there is too many informations (often redundant), too many pages about FGCom, too many unrelated information with FGCom. All of this could discourage our users to read the documentation
Reply to: New FGCom require a lot of changes in documentation
This documentation was quite all-right, and did build up the FGCom usage in the past years.
The problem is, that you obviously believe you have to destroy the whole functional operation by inserting wrong and misleading informations - in order to replace a functional environment with a design that is not yet functional - and even needs a lot of more basic thinking about what really is needed! Wrong is e.g.:
- You add notes telling people that the current design is not valid any more. Actually it is right now the only functional design that exists!
- You state: "FGCom-sa must be used only for those who want to run FGCom on a separate computer!" That is very definitely WRONG!! Why should it not be used together with e.g. OpenRadar on one computer?? I do not understand how you can make such funny statements - did you not investigate what your design is needed for?
- You deleted the section describing how to setup FGFS prior to the functional test of FGCom after a new installation - that indicates to me that you never tried to help users to get FGCom to work! Otherwise you would know that most of the occurring problems are due to the interaction between FGFS and FGCom. Please do not tell me that there is just the port connection! Most of the FGCom operation depends very much on the FGFS settings (e.g. frequency, location/range, airplane, multilayer, concurrencies, finding freq. values available, possible Network-problems in a LAN-environment, etc.)
- You try to convince everybody to only use your new environment for real - not just for testing - although you know it is not yet fully functional.
- You have no consideration at all for multiplayer-events where any number of pilots come together from all parts of the world! You cannot contact them all in advance and tell them "you have to install FS 3.0 (or GIT 2.99) - otherwise you cannot participate"! I hope in the meantime you did understand that all participants of an event need to use the same server! You are killing all our achievements we worked hard for the last years, if you just neglect those user-problems/dependencies!!!
That means: We do not need a whole lot of changed and/or restructured documentation -- we just need to update the current one by a few lines that tell what is different between now and may be in future! Without upsetting/misleading the now user-community!
I hope you reconsider your now actions - which may be OK for a complete new design - but definitely NOT for phasing in a new one! That FGCom "new" just cannot be "broken" in by any command from anyone!
Please consider: The very best engineering design is worse nothing - if it does not find users/customers.
I definitely will continue to undo all your wrong/misleading informations in the FGCOM user-documentation, that was created by me - even if that means doing it every day many times. I love that FGCom - and will not let it be destroyed! If you want to develop a new user-documentation in addition, you are welcome to do so - but make sure it is called "FGCom 3.0" or similar. We very definitely do need the old one for the time being!! I really would hate to find another solution!(e.g. Mumble or similar - and pls do not try to tell me what is better about FGCom - I am the one fighting against other solutions over the last 3 years!) But I do need some Radio-Communication - and if you are unable to support a concurrent operation of old/new - what shall we do?
I hope you are able to consider working together with the user-community and the Maintainers/Operators of the current environment. I personally am very interested in getting those changes operational that you right now work on - but I will not be quiet if you destroy the whole, existing FGCom project!
jomo Oct 31 2013
Upper+Space should read Shift+Space!
Title is pretty much self explanatory, "Upper+Space" should read "Shift+Space", as the upper key could easily imply or be misunderstood for the "Cursor Up" key! (Shifted-space characters has had a more common pressence amongst computer programmers since the 1980's? Or earlier? I do however easily understand the previously mentioned "upper case" numbers, but probably should also read "shifted numbers"?) On a side note, pressing Shift+Space here doesn't appear to do much (with FGCom/Radio), and curious if some other action should occur or something printed to screen. I should also mention I'm using =games-simulation/flightgear-3.0.0, and I don't know if anything is printed to stdout since FGCom's official implimentation into FlightGear. --Rogerx (talk) 22:47, 19 April 2014 (UTC)
Too many FGCom Wiki pages
I think there's too many FGCom Wiki pages. Should have likely stuck to one page, and split later or as FGCom evolved.
For example, here's a listing of most of the pages, and some deal with pre intigration of FGCom into FlightGear and some dealing with post integration of FGCom into FlightGear:
(There could be more FGCom FlightGear Wiki pages.)
It is really easy with Wiki, to confine everything to one page! (The only time separate pages are likely needed, is for people on dial-up or slow ISP connections.) I was considering making a new FGCom_for_LinuxALSA, but I think it's only going to make things much worse versus any better. Probably best to push all information from the other Wiki pages back into the main FGCom page, in order to prevent information from being loss from future organization. There are some very lengthy Wiki pages on the Internet, and they're all extremely easily navigated or edited. Too many separate pages causes problems with Search Engines, or users overall trying to find information, or just overall organizational issues due to duplicated information or possibly lost information. --Rogerx (talk) 19:36, 22 April 2014 (UTC)
Move away this article
A request for our wiki manager:
please, is it technically possible to move (delete?) this article into a new article named "FGCom_old" then redirect "FGCom" (this article) to FGCom_3.0 ?
that way our users can find the last up-to-date article without spending their time to read this old and out-of-date article directly at FGCom
I just marked all the out-of-date article related to FGCom as "obsolete" in any language, those article should be ideally deleted because they are more confusing than helpful for our users, however I don't know the procedure to delete an article.
- As a regular user, you can actually move the page yourself. I would suggest a title something like "FGCom (before 3.0)", which is how I am about to move this page. Unfortunately I know neither French or German, so I think I am only going to move this page. I would also suggest changing the resulting redirect page to point to the new article instead of deleting FGCom and moving FGCom 3.0 there.