Board index FlightGear Support Tools FGCom

FGCOM Conversion Problems

FGCom is a realtime voice communication system specially designed for FlightGear.

FGCOM Conversion Problems

Postby jomo » Mon Oct 21, 2013 7:09 am

There seem to be some misunderstandings between
  • the "Designer-World" thinking already in terms of the FGFS-Release FG 3.0 (planned for feb 2014)
  • and the "User-World" that has to deal with the FGFS as is (that may be FG 2.12 or older or even much older! I know some still on 1.9!)
As somebody that eagerly awaits the integration of FGCOM into the FGFS, I was asked to test the new server and the new FGCOM standalone feature.
In summary I conclude: It looks great for the future - but needs some more testing, improvements, and a lot of documentation changes (e.g. wiki, server installation, etc.) - as is normal with a new design.

As major handicaps, that must be solved prior general usage, I see:
  • The long expected new LINUX-Standalone-Versions (FGCom-sa) are not yet functional/installable (in a standard fashion)
  • Conflicts between the old and new FGCOM in regards to frequencies used: e.g. the current FGCOM uses 127.32 as TWR-freq for EDDF, and also the FGFS (only till vers. 2.12 ?) suggests 127.32 (see F12 -> "ATC Services in range" -> EDDF) - while the new FGCOM enforces 127.325. That 127.325 is the correct frequency in the "Real-World" - BUT:
    • as of today a pilot with the "old" FGCOM on 127.32 cannot talk to one with the new FGCOM - so we do need to find a solution for that (not only EDDF is affected by that!)
    • Pilots that are used to set the frequency manually cannot set the new frequency (6 digets) e.g. in the c172p Radio-Stack (Most probably that radio is also used in other models.
  • The often used Debug-Echo-Procedure "use freq. 910 -> talk -> you must hear the last word twice" does seem to become confusing - because people report they hear music on 910 - and do not know what that means!
  • Also now again nobody is sure if they still can/should use the new server - or the old new - or even the original (old) "UK"-server, etc.
  • The designer plans to disable the possibility to set up several FGCOM Servers. In my view that is a absolute "NoNo":
    • We do have some bad experiences when a "only 1 server" becomes unreliable
    • It cannot harm to have multiple servers - not only as standby but also to be used for different events or different world-locations.
    • I also do not believe in the designer prediction
      "we won't have more than 15~20 users (when FGCom will be really popular) simultaneously connected"
      --> the last two weeks I have seen more than 10 concurrent FGCOM-users during the EDDF-ATC events - together with the other ATC-locations being active at the same time alone inside Europe we have been already far above those 20 users -- and one reason of that change is: Have FGCOM availabel/active all the time whenever MPservices are activated! Thus there will (hopefully!) be much much more concurrent users worldwide!!
  • I do like the "online listing" of the FGCOM users - but am not sure that everybody wants to be listed over a longer time frame in that History-Listing! I do have concerns regarding publicizing those "privat data" to all Internet users. Yes - MPservers are doing similar things - but mostly only the "actual data" - the history can only be seen by logged in people! I personal would not have a problem with that -- how does the community think about it?
Please let me stress:
- I will support with all I can to get the integrated FGCOM version to come true
- I do urge all users to TEST the new FGCOM - but be careful when testing it in an environment with other users - not being on the same level

Sorry - but the now WIKs had been updated already to a version as it hopefully will be in the upcoming FG 3.0 - and that changes have already confused several people. As the guy who has initiated those WIKIs I have tried to "undo" all those changes (for now). We should start a combined effort to keep the WIKIs in a form to support old and new! Sorry enough we will not be able to to change the whole FGFS-world at one point in time!
jomo / ATCjomo
ATC at EDDF Fr,Sa,Su,We from 20:00 to 24:00 CET/MEZ., see http://www.emmerich-j.de
User avatar
jomo
 
Posts: 831
Joined: Thu Feb 12, 2009 6:46 pm
Location: Mainz, Germany
Callsign: jomo jomoATC
OS: UBUNTU 17.10

Re: FGCOM Conversion Problems

Postby F-JJTH » Mon Oct 21, 2013 10:12 am

Hi Jörg,

jomo wrote in Mon Oct 21, 2013 7:09 am:In summary I conclude: It looks great for the future - but needs some more testing, improvements, and a lot of documentation changes (e.g. wiki, server installation, etc.) - as is normal with a new design.
I agree that documentation change is a big part of the work now and I'm aware it's not an easy task because we need to keep the wiki documentation simple, clear and effective for the users.
I would suggest to have 3 wiki pages:
- 1 page for FGCom built-in ( a good start is certainly http://wiki.flightgear.org/Integrating_FGCom )
- 1 page for FGCom-sa
- 1 page for "old" FGCom ( mostly all the current wiki page about FGCom as of today )

What is your opinion ? Do you have a suggest ?


jomo wrote in Mon Oct 21, 2013 7:09 am:The long expected new LINUX-Standalone-Versions (FGCom-sa) are not yet functional/installable (in a standard fashion)
They are functional and doesn't require any installation step (which is simpler for our users). Visit http://fgcom.flightgear.org/download, download your FGCom version depending on your operating system, then unzip it, now you are able to run FGCom-sa from a command line as we have done it for many years.
No compilation is required (which is certainly a huge good things), no GIT software is required (only a web browser for downloading a zip file).

I even plan to provide a little "run_fgcom.sh" (run_fgcom.bat for Windows) in order to avoid the user to run FGCom from the command line. The .sh (.bat) file will be a simple "double-clic me" and that's all. I can see an easier way to run FGCom for our users (go on a website + download your FGCom + unzip it + double clic on the launcher that's all)

In a terminal it could be as simple as: copy/past this command in a terminal in order to run FGCom-sa:
For Linux 64:
Code: Select all
wget http://fgcom.flightgear.org/download/fgcom-2.99.0_linux64.zip && unzip fgcom-2.99.0_linux64.zip && cd fgcom/bin && ./fgcom

For Linux 32:
Code: Select all
wget http://fgcom.flightgear.org/download/fgcom-2.99.0_linux64.zip && unzip fgcom-2.99.0_linux32.zip && cd fgcom/bin && ./fgcom
Then run your FlightGear with --generic=socket,out,10,localhost,16661,udp,fgcom that's all.

Try it ! it's already working :)

Let me know if you have suggest.


jomo wrote in Mon Oct 21, 2013 7:09 am:Conflicts between the old and new FGCOM in regards to frequencies used [...]
  • as of today a pilot with the "old" FGCOM on 127.32 cannot talk to one with the new FGCOM
  • Pilots that are used to set the frequency manually cannot set the new frequency (6 digets) e.g. in the c172p Radio-Stack (Most probably that radio is also used in other models.
This information is wrong if you use fgcom.flightgear.org as server. All of this is solved on server side, it's totally transparent for the users. That's why I recommand you to use fgcom.flightgear.org
You can connect on 127.32 with an old FGCom, 127.325 with a new FGCom, 127.32 with FGCom built-in, 127.325 with FGCom built-in all users will be able to listen and talk to each other. All of this is working since September.


jomo wrote in Mon Oct 21, 2013 7:09 am:The often used Debug-Echo-Procedure "use freq. 910 -> talk -> you must hear the last word twice" does seem to become confusing - because people report they hear music on 910 - and do not know what that means!
This information is certainly an error from the user who reported that. I confirm that 910 is for Echo test, 911 is for music. So the user who reported this information has certainly did an error in his frequency dialog.
Looking at the history at http://fgcom.flightgear.org/history.php I can see this user who tuned on 911 and because of this web page I can assure you that this user has selected 911 instead of 910.
So this is not a bug, it's a simple error from one of our user.


jomo wrote in Mon Oct 21, 2013 7:09 am:Also now again nobody is sure if they still can/should use the new server - or the old new - or even the original (old) "UK"-server, etc.
I have personally contact the maintainer of fgcom.flightgear.org.uk, this is his answer when I asked him the state of his server:
Hi Clement
My fgcom server was shut down months ago, after being rudely told that my services were no longer required because someone else had started one up…
I think this sentence is enough clear and we can safely consider fgcom.flightgear.org.uk as "no longer active"


jomo wrote in Mon Oct 21, 2013 7:09 am:The designer plans to disable the possibility to set up several FGCOM Servers. In my view that is a absolute "NoNo":
You certainly misunderstood my MP, I said it could be a possibility to remove the choice of server to our users. That way our users don't have to ask "which server should I use ???? I'm lost ! there is plenty of server ! Which one is the good one ??". However it's already possible to leave a specifc property for this purpose like it's already done :) Look at the wiki documentation http://wiki.flightgear.org/Integrating_FGCom this is working since August 2013


jomo wrote in Mon Oct 21, 2013 7:09 am:am not sure that everybody wants to be listed over a longer time frame in that History-Listing! I do have concerns regarding publicizing those "privat data" to all Internet users.
The history listing is mostly for debug purpose until FG 3.0 release. I've setup this tools in order to track errors/bugs, this is a tools really useful for me in order to know if everythings is working as expected.
This page is available to everybody because I want that everybody know what I'm able to know. That way there is no "oh look ! one of FlightGear developper is tracking a million of informations from us in order to sold them to a company !" Of course this is a caricatural representation and you can be sure this is absolutely not my goal here. My goal is to have a tool who tell me if all my stuff is working as expected because users feedback are finally rare...


jomo wrote in Mon Oct 21, 2013 7:09 am:Yes - MPservers are doing similar things - but mostly only the "actual data" - the history can only be seen by logged in people!
For your information everybody is able to see your history, not only your "actual data" and without login:

http://mpserver12.flightgear.org/tracke ... ght/14146/
http://mpserver12.flightgear.org/tracke ... ght/14125/
http://mpserver15.flightgear.org/module ... GN=ATCjomo (we can clic on each of your flight and see where you were, when, how...15 pages of history)
http://mpserver15.flightgear.org/module ... LSIGN=jomo (37 pages of history)
http://mpserver15.flightgear.org/module ... ID=2900195

So I guess there is much more information on mpserver15.flightgear.org about you than fgcom.flightgear.org. If you disagree with this I would suggest to contact the maintainer of this website as soon as possible !


jomo wrote in Mon Oct 21, 2013 7:09 am:As the guy who has initiated those WIKIs I have tried to "undo" all those changes (for now).
Please don't revert changes if you are not fully aware of the current state of FGCom. All changes that I did for now are mostly not important, I simply changed all the fgcom.flightgear.org.uk for fgcom.flightgear.org (as stated the original server is no longer active so this change will avoid our user to ask "what is this server address ???") And I started to put some {{note}} (I haven't removed or changed any procedural information) in order to show to people that something is being changed.


jomo wrote in Mon Oct 21, 2013 7:09 am:We should start a combined effort to keep the WIKIs in a form to support old and new!
I agree and my current post is mostly oriented in this way. That's why you are invited to do suggest :)

Regards,
Clément
User avatar
F-JJTH
 
Posts: 697
Joined: Fri Sep 09, 2011 11:02 am

Re: FGCOM Conversion Problems

Postby Hooray » Mon Oct 21, 2013 1:07 pm

Sorry - but the now WIKs had been updated already to a version as it hopefully will be in the upcoming FG 3.0 - and that changes have already confused several people. As the guy who has initiated those WIKIs I have tried to "undo" all those changes (for now). We should start a combined effort to keep the WIKIs in a form to support old and new! Sorry enough we will not be able to to change the whole FGFS-world at one point in time!

This was also mentioned at: http://wiki.flightgear.org/Talk:FGCom

In general I agree, and there's really no clean solution with the existing approach - it's not specific to FGCom, we've had the same problem with other features that received major updates. So on the one hand, the good thing is that we actually do have some contributing developers who are actively concerned about the quality of our documentation, and seek to update the wiki as soon as possible - on the other hand, the issue is that it's really just developers and people building from git (or nightly/RC testers) who get to see these new features in the form discussed and documented via the wiki, which usually means that the wiki is more up to date than the latest release, i.e. for another ~6 months - this is a rare problem, and we are actually fortunate that some contributors are eager to update the docs - but it's happened previously, and we need to come up with a solution.

The interim solution would be splitting/forking the FGCom article, and documenting all FG 3.0 features separately - so that existing users of FG <= 2.12 are not confused.

Now all that being said, we've talked about the issue previously - and what we really need to do is to change our wiki/documentation workflows accordingly - wikimedia itself does support extensions to provide support for branching and forking articles and tagging them by version - so that we could have different sets of articles for different FlightGear versions - personally, that's the solution that I'd prefer, not just as a wiki admin, but also as a FG user - so basically we need to get in touch with Gijs and/or Simon and ask them to install and enable the corresponding modules, so that multiple revisions of an article can be easily branched/forked and tagged for different FlightGear versions.

Subject: Help needed - market research for FG

Bjoern wrote:
Hooray wrote in Fri Nov 16, 2012 3:44 pm:I do disagree with your suggestion to only support the latest version. I think we can do far better by using wiki tagging for each release. This works for wikipedia, too - and we're using the same software. So why not use the same method? They also have "stable" versions of articles, and articles that still need to be reviewed. Like others mentioned previously, that shouldn't be hard to start. However, file uploading would need to be specifically dealt with - so that uploaded files can be version-specific, i.e. also "tagged". I'm not sure how WP deals with that.


If you can do version specific articles, and more importantly, keep them updated, I wouldn't mind. Or have a subject-specific article and divide it into subsections dealing with different versions of FG.
In any case, however, having comprehensive articles dealing with the current version is quite important so that new users won't get lost.


Subject: Help needed - market research for FG

Hooray wrote:I'm aware of the documentation-related issues that would cause, however at least for the wiki, this could be solved by using some template magic for different release versions, i.e. by search for "c172p" and "ksfo" and using a wiki template instead.

Overall, our documentation still isn't very good when it comes to providing info for different FG versions. We would actually need to add 2-3 wiki addons so that we can use "tagging" for "stable" versions, and fork/branch our articles after each release.
That would definitely make sense, because people with older FG versions could easily browse accordingly tagged wiki articles.
Arguably, this is easier to support in the LaTex sources because they're alrady being maintained via git and can be easily branched/tagged accordingly.


Subject: Help needed - market research for FG

Gijs wrote:The problem with tagging articles is that lots of stuff that is nowadays added to the wiki also applies to older versions, it was just never documented before. It is impossible to check everything for each version and see if it was available at that release. Simply replacing every occurence of KSFO with something else does not address the issue. Usually there is slightly more written down than "Start at KSFO" (think of navigation tutorials, sentences like "You can find an example of the pick animation in the big hangar at KSFO." etc.). Anyway, discussing that could fill a whole topic on its own :-)

Arguably, this is easier to support in the LaTex sources because they're alrady being maintained via git and can be easily branched/tagged accordingly.

As far as I know the manual is distributed with each release, so people should already have the manual that fits their version.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11185
Joined: Tue Mar 25, 2008 8:40 am

Re: FGCOM Conversion Problems

Postby jomo » Mon Oct 21, 2013 3:41 pm

F-JJTH wrote in Mon Oct 21, 2013 10:12 am:I would suggest to have 3 wiki pages:
- 1 page for FGCom built-in ( a good start is certainly http://wiki.flightgear.org/Integrating_FGCom )
- 1 page for FGCom-sa
- 1 page for "old" FGCom ( mostly all the current wiki page about FGCom as of today )
What is your opinion ? Do you have a suggest ?
I wonder how fast you are with changing (some) documentation - obviously without knowing which is available today and will be affected tomorrow! Today that is:
http://wiki.flightgear.org/Fgcom (also in Français)
http://wiki.flightgear.org/FGCOM_Testing (also in Deutsch and Français)
http://wiki.flightgear.org/FGCOM_for_Windows
http://wiki.flightgear.org/Integrating_FGCom
http://wiki.flightgear.org/Scripted_Com ... ian/Ubuntu
There may be more - maybe even in National-FGFS-wikis! I do not believe that your "quickie" really makes sure that all docs are updated. Anyhow I would not change it before the new design is being tested - and all aspects are known! I told you already (beginning October) that this month I cannot spend much time on it - still I now have tested 3 times for you without any results based on my findings! And sorry: I definitely cannot spend more time on it, at least this month!

F-JJTH wrote:They are functional and doesn't require any installation step (which is simpler for our users). Visit http://fgcom.flightgear.org/download, download your FGCom version depending on your operating system, then unzip it, now you are able to run FGCom-sa from a command line as we have done it for many years.
No compilation is required (which is certainly a huge good things), no GIT software is required (only a web browser for downloading a zip file).
In a terminal it could be as simple as: copy/past this command in a terminal in order to run FGCom-sa:
That is one of the disappointments: I tested like that beginning Oct (with "fgcom-2.99.0_Linux.zip", size 1.3 MB, downloaded Oct.5th) - that failed, i reported, and you agreed that it is/was a problem.
Today I again spent some time to try as you describe (with todays version "fgcom-2.99.0_linux32.zip", size 748.1 kb) it failed again:
Code: Select all
emmerich@emma-work:~$ fgcom -Sfgcom.flightgear.org
No command 'fgcom' found, did you mean:
 Command 'gcom' from package 'comgt' (universe)
fgcom: command not found
emmerich@emma-work:~$


Of course that is the usual thing if you work with a copy in Linux - so I tried:
Code: Select all
emmerich@emma-work:~$ '/home/emmerich/Downloads/fgcom/bin/fgcom' -Sfgcom.flightgear.org
fgcom - a communication radio based on VoIP with IAX/Asterisk
Original (c) 2007-2011 by H. Wirtz <wirtz@dfn.de>
OSX and Windows ports 2012-2013 by Yves Sablonier and Geoff R. McLane, resp.
Version 2.99.0 compiled Oct 12 2013, at 10:26:57
Using iaxclient library Version SVN 261

Successfully parsed commandline options
Failed to load file [../share/flightgear/special_frequencies.txt] !
Using internal defaults
Reading airports [../share/flightgear/positions.txt]
ERROR: open failed!
fopen: No such file or directory
Stopping service
AL lib: ReleaseALC: 1 device not closed
emmerich@emma-work:~$
i.e. it failed again!

Just to make sure I tried the same with the "old" version:
Code: Select all
emmerich@emma-work:~$ '/home/emmerich/fgfs/install/fgcom/bin/fgcom' -Sfgcom.flightgear.org 
fgcom - a communication radio based on VoIP with IAX/Asterisk
Original (c) 2007-2011 by H. Wirtz <wirtz@dfn.de>
OSX and Windows ports 2012-2013 by Yves Sablonier and Geoff R. McLane, resp.
Version 2.10.0 compiled Mar 20 2013, at 14:00:43
Using iaxclient library Version SVN 261

Successfully parsed commandline options.
Loaded file [/home/emmerich/fgfs/install/fgcom/share/fgcom/special_frequencies.txt].
Reading airports [/home/emmerich/fgfs/install/fgcom/share/fgcom/positions.txt]... loaded 36741 entries.
Initializing IAX client as guest:xxxxxxxxxxx@fgcom.flightgear.org

So seems to me there still is a bug in the "new"!

F-JJTH wrote:This information is wrong if you use fgcom.flightgear.org as server. All of this is solved on server side, it's totally transparent for the users. That's why I recommand you to use fgcom.flightgear.org
You can connect on 127.32 with an old FGCom, 127.325 with a new FGCom, 127.32 with FGCom built-in, 127.325 with FGCom built-in all users will be able to listen and talk to each other. All of this is working since September.
That I cannot really test right now because I do not have a functional "new" version! BUT:
1) I am not sure what the server has to do with that - I would have thought that depends on the contents of the "positions.txt" inside the client. And there all the critical freq are doubled (as 5 digit and 6 digit). So a user with the "new" version may be able to set the 172.32 and thus communicate with others using the "old" version on 172.32
2) But what happens when the user with the "new" version sets the "RealLife should be" 172.325? Can he still communicate with a user being on an "old" version - that can only use the 172.32??
3) How do we make sure that we will not be killed if some "Reality-Fan" insists on using the correct freq and a FGFS-fan wants to use what is stated inside FGFS!
4) Just in case you did put some corrective actions for that into your new server - how do the old server cope with that?

jomo wrote in Mon Oct 21, 2013 7:09 am:The often used Debug-Echo-Procedure "use freq. 910 -> talk -> you must hear the last word twice" does seem to become confusing - because people report they hear music on 910 - and do not know what that means!
F-JJTH wrote:I confirm that 910 is for Echo test, 911 is for music. So this is not a bug, it's a simple error from one of our user.
Maybe that is a good point to explain in your documentation (changes?)

F-JJTH wrote:I think this sentence is enough clear and we can safely consider fgcom.flightgear.org.uk as "no longer active"
Yes we surely can - but wouldn't it be nice to tell users about it - and not just delete in the documentation the ".UK". That confuses some people having worked for years with the "UK"-server and now damn the fgcom because that does not work any more!

To the "legal problems because of the history listing:
F-JJTH wrote:So I guess there is much more information on mpserver15.flightgear.org about you than fgcom.flightgear.org. If you disagree with this I would suggest to contact the maintainer of this website as soon as possible !
If that causes a legal problem it is the problem of the owner of the server. In general I stated already that I have no problems with it - it was just a reminder to check the legal aspects!

F-JJTH wrote:All (documentation) changes that I did for now are mostly not important, I simply changed all the fgcom.flightgear.org.uk for fgcom.flightgear.org (as stated the original server is no longer active so this change will avoid our user to ask "what is this server address ???") And I started to put some {{note}} (I haven't removed or changed any procedural information) in order to show to people that something is being changed.
A change saying
NOTE: This section is deprecated because FGCom is now (Oct. 2013) integrated to FlightGear and FGCom standalone is built with FlightGear
seems to prove something different! And it is wrong and remains wrong even after FGFS 3.0 because You cannot control when any FGFS-user will upgrade to newer versions. And thus it definitely will confuse/mislead many readers! You cannot control when any FGFS-user will upgrade to newer versions!

Again: I am very thankful for that job you are doing - but maybe life would be easier for all of us if you could accept "user comments" as something to consider seriously.
rgds jomo
jomo / ATCjomo
ATC at EDDF Fr,Sa,Su,We from 20:00 to 24:00 CET/MEZ., see http://www.emmerich-j.de
User avatar
jomo
 
Posts: 831
Joined: Thu Feb 12, 2009 6:46 pm
Location: Mainz, Germany
Callsign: jomo jomoATC
OS: UBUNTU 17.10

Re: FGCOM Conversion Problems

Postby Hooray » Mon Oct 21, 2013 4:28 pm

You cannot control when any FGFS-user will upgrade to newer versions!


without going into the specifics of this discussion, the FlightGear project has generally a pretty poor history of backward compatibility, and we do always ask people to upgrade to the latest version, especially when it comes to features, documentation and support on the forums/IRC. Honestly, we really only have a handful of people here who actively seek to provide end-user support, and the number of people who regularly and actively contribute to the wiki in order to update our docs is pretty much the same - so it's not that we do not want to provide support to people NOT using the "latest bleeding edge" code, but it's out of necessity that we really only support the latest stable release - most people who do provide support regularly are "power users" (contributors) and usually use head/next/master.

Thus, while I am definitely able to downgrade and build older versions, I rarely see any need to - it would take me 10-15 minutes on average, which is why I really only contribute to articles for the latest stable/next code. For the same reasons, we should seek to support branching articles, so that people who actually are using some older version, cannot only refer to the corresponding information safely, but also help improve these articles by contributing to them.

Providing support for versions way before the latest release/next is simply too much pain for most people here, even seasoned contributors.

So let's stop debating semantics and try to come up with a solution that will allow us to have good documentation for different FG versions, without articles becoming hugely complicated or obscure.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11185
Joined: Tue Mar 25, 2008 8:40 am

Re: FGCOM Conversion Problems

Postby F-JJTH » Mon Oct 21, 2013 4:50 pm

jomo wrote in Mon Oct 21, 2013 3:41 pm:I do not believe that your "quickie" really makes sure that all docs are updated
If you look at my wiki change you will see that I've created a new category named "FGCom". All pages you listed are part of this category, so yes it seems that I'm aware about all documentation available on the wiki ;)
http://wiki.flightgear.org/Category:FGCom

jomo wrote in Mon Oct 21, 2013 3:41 pm:
Code: Select all
emmerich@emma-work:~$ fgcom -Sfgcom.flightgear.org



This is not the line I gave in my precedent post, I can't help you if you use some custom command that I don't know :/

jomo wrote in Mon Oct 21, 2013 3:41 pm:
Code: Select all
emmerich@emma-work:~$ '/home/emmerich/Downloads/fgcom/bin/fgcom' -Sfgcom.flightgear.org


Same here, you are not using the command line I gave in my precedent post, I can't help you until you accept to execute the command line I wrote...
Here you are giving an absolute path from your $HOME directory, so it's normal that "../share/flightgear" are not found since you are executing the binary from your $HOME instead of from $HOME/Downloads/fgcom/bin

Please use the line I gave in my precedent post.
Also, be sure you are selecting the correct architecture (32 bits or 64 bits) for you computer. If you don't know the architecture of your computer do: uname -a in a terminal, if you can read "x86_64" in the line you are 64 bits, else you are 32 bits.

I tried the command line on 4 differents computer and all worked as expected for these 4 computers.


jomo wrote in Mon Oct 21, 2013 3:41 pm:1) I am not sure what the server has to do with that - I would have thought that depends on the contents of the "positions.txt" inside the client. And there all the critical freq are doubled (as 5 digit and 6 digit). So a user with the "new" version may be able to set the 172.32 and thus communicate with others using the "old" version on 172.32
2) But what happens when the user with the "new" version sets the "RealLife should be" 172.325? Can he still communicate with a user being on an "old" version - that can only use the 172.32??
3) How do we make sure that we will not be killed if some "Reality-Fan" insists on using the correct freq and a FGFS-fan wants to use what is stated inside FGFS!
4) Just in case you did put some corrective actions for that into your new server - how do the old server cope with that?


1) The server is a software called "Asterisk" it's a really powerful software who is able to do a lot of things. So clearly, YES a user with the "new" version may be able to set the 127.32 and thus communicate with others using the "old" version on 127.32
2) YES the "new" version user can still communicate with a user being on an "old" version
3) Answer is easy ! tell to your user to use "127.32" they can decide if they want use 127.320 or 127.325, it's not important since the server is merging these frequencies ;) For those who tune the frequency from the cockpit they will tune on 127.325 since every radio in FlightGear are 25KHz spacing. For those who are used to tune the frequency in the GUI dialog they can use 127.320 or 127.325 it's really not important since the server merge them :)
4) If you are talking about delta384.server4you.de I have no clue of the setup of this server, I have no access to this server so I can't answer to this question, I invit you to contact the maintainer of this server to know how his server is setup.


jomo wrote in Mon Oct 21, 2013 3:41 pm:Maybe that is a good point to explain in your documentation (changes?)

Sure, but I was waiting for your opinion before writing big change in the documentation, and I will even wait the end of the month until you have some more spare time ;)


About the documentation you are right that nobody can control when a user will upgrade his FG installation. I would prefer you give me an idea to solve this problem instead of just saying "You are doing something wrong!"


Here is what I have in mind for the wiki:

1) Keep the current documentation for people who still use the "old" FGCom
2) Create an up-to-date documentation like:
  • FGCom built-in
    • How to use it ?
    • Testing
  • FGCom standalone
    • How to get it ?
    • How to use it ?
    • Testing
  • FGCom server
    • Available servers
    • How it works ?
    • How to set an FGCom server ?

How does it looks for you ?

Regards,
Clément
User avatar
F-JJTH
 
Posts: 697
Joined: Fri Sep 09, 2011 11:02 am

Re: FGCOM Conversion Problems

Postby adrian » Mon Oct 21, 2013 5:53 pm

As of today, I'm officially interested and able to work with FGCom.
A few details for people who don't know the way FGCom works, but would like to be able to understand better:

FGCom is basically an IAX client for Asterisk, the free and open source PBX. IAXand IAX2 are a bi-directional (duplex) voice protocol which together with SIP and H.323 are supported by Asterisk.
When setting up the server, one must configure extensions, much like you would do with a normal telephone system. This is similar to radio stations using a fixed channel memory interface, and rather different from the open VFO-capable radios used on AM aircraft band communications.
Fortunately, this can be overcome by some clever usage of Asterisk configuration.

It's been quite a while since I last worked on an Asterisk system (about 5 years) so you will have to excuse my slips. I'm definetly very familiar though with radios :)
Since Clement is in charge of FGCom, I have noticed rapid progress in this direction, but I had no time to get involved. I will definetly make that time though when needed to add realistic radio distances and terrain blocking via the new radio code which is developed and maintained by me. Other than that, my other projects now require me to use a voice protocol, and IAXclient is my first choice. So expect me to jump in into the debate when least expected :)
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 2:15 pm

Re: FGCOM Conversion Problems

Postby Johan G » Fri Oct 25, 2013 11:43 am

As for handling the various FlightGear versions, and versions of other software on the wiki, a commendable example is the Blender wiki, though it is based around a lot more structure and very complex templates.

For example when browsing the manual you can, as long as one page is available in all versions, switch between version 2.4, 2.6 and various languages apart from English using simple drop-down lists.

I'll bet at least some of this can be done in a very much more simple way than that. :wink:
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5294
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: FGCOM Conversion Problems

Postby jomo » Mon Oct 28, 2013 9:05 am

On Oct.10th I was asked by F-JJTH to test the new FGCOM development for FGFS 3.0 and test it as soon as possible within the regular EDDF-ATC events. Please find in the following a summary of my testing, and the reasons for me not yet being able to suggest the usage of that new design in common events.
1) In Generall:
    The main problem seems to be the fact, that engineering is absolutely not interested in considering a parallel operation of the current environment with the new one. Of course Engineering contradicts this, but Forum-statements like the following do indicate the opposite:
    F-JJTH wrote:About the worldwide switch I still have 2 solutions:
    1) Send a special dialplan to Dirk and ask him to install this dialplan which redirect every traffic on the new server
    2) Remove the server choice from FGCom-sa and FG. That way the server will be no longer a choice "-S" arguments is easy to remove

    + (e.g. changing the WIKIs by:) "NOTE: This section is deprecated because FGCom is now (Oct. 2013) integrated to FlightGear and FGCom standalone is built with FlightGear"
    + (e.g. stating in the Forum:) "If you are talking about delta384.server4you.de I have no clue of the setup of this server, I have no access to this server so I can't answer to this question, I invit you to contact the maintainer of this server to know how his server is setup." (I really wonder: I always thought it is standard engineering practise to evaluate something that is used already - before they try to change it!)
    In addition there were more wrong and/or unacceptable statements:
  • In the meantime Lenny was asked to post on his Flight-Plan pages a notice, asking users "to use the official FGCOM server fgcom.flightgear.org"
  • Of course we still operate on the old server in the old environment -- but already during this weekend ATCevents at EDDF I had 4 customers frustrated because "nothing was working any more" - so we needed quite some time to get them back into our functional environment!
  • It was stated: "we won't have more than 15~20 users (when FGCom will be really popular) simultaneously connected"
    In my experience we have already more than that as of today - and hopefully will have much more in the future!

    Over the last 4 years there was a lot of efforts put into building up "Controlled Flying environments using FGCOM" -- I was deeply involved in that myselfe and certainly will not now contribute in destroying this existing functional environment by frustrating my visitors at EDDF --- just because engineering follows his own priorities only! Very definitely my priority remains: We must support a concurrent operation between the "old" and "new" environment over several years! That includes especially also the user-documentation/wikis. There is (and must not be) any need for very big differences inside the user-wikis - all needed changes can be explained with minor sub-statements.

    Based on that I will now start to review those wikis that I had generated in order to help users - and will change them to explain: The currently used version is "delta384.server4you.de", the UK version is not available any more, and a "new design" should be available with FGFS 3.0 - but can already be tested "outside the standard events"! I urge engineering to not change those user-documents in order to mislead users to a not yet fully functional/accepted design! There are many people trying to encourage FGFS-users to start using FGCOM - so incorrect/misleading wikis are disastrous! So we must support also the "old" environment until all users have upgraded their systems - and that may take some years!

    Prior to doing any further testing "Inside of actual events" I suggest that engineering gather a few people to test the new design in all possible mixed environments, containing:
      containing: -sa for Windows/OSX/Linux, integrated in GIT for Windows/OSX/Linux, "old"/"new" design
      and reports which problems my exist between which constellations
2) Technical problems with the Server
  • In general I like the idea of the server homepage (although I have some legal concerns about a long lasting history of private data - but that is no major concern for me)
  • I still do not see my UID when I use the new server with the -sa client:
    Code: Select all
     Callsign                      ICAO    Frequency          Date
    Manual (FGCOM 2.99.0)    EDDF    127.325 MHz    2013-10-25 07:33:21    00h03m02s
    Manual (FGCOM 2.99.0)    EDDF    127.320 MHz    2013-10-25 07:33:21    00h03m02s
    guest  (FGCOM 2.99.0)    EDDF    127.320 MHz    2013-10-25 07:33:17    00h00m00s
    Manual (FGCOM 2.99.0)    EDDF    127.325 MHz    2013-10-25 07:02:58    00h00m32s
    Manual (FGCOM 2.99.0)    EDDF    127.320 MHz    2013-10-25 07:02:58    00h00m32s
    i.e my UID was not displayed although these tests were done with the new FGCOM-sa and obviously the new server.
    ==> Does that mean that each user needs a Login-UID for that server or are there communication problems with the MPservers? (We know they sometimes have problems communicating All to All - but I guess then FGCOM would not have worked at all! ??
  • Even worse: On restarting FGCOM I received several times:
    Code: Select all
    Successfully parsed command line options
    Loaded file [../share/flightgear/special_frequencies.txt].
    Reading airports [../share/flightgear/positions.txt]
    loaded 46927 entries
    Initializing IAX client as guest:xxxxxxxxxxx@fgcom.flightgear.org
    bind(127.0.0.1:16661) failed. Errno 98 (Address already in use)
    That is a major problem for an ATC who works for several hours in one session. We then regularly have to restart because FGCOM starts chopping. In that case we need a fast restart - one reason why I use FGCOMGUI: There you always can restart in sec just by clicking onto two buttons!
    But FGCOMGUI does not work any more (because of the now different start: ./fgcom ....). I would suggest to either integrate the now FGCOMGUI into the -sa version or release a new FGCOMGUI-sa - or whatever
  • Till now there always was the problem that all users must use the same server - in the meantime they also need to agree on frequencies (e.g.: 127.32 or 127.325)! And I do not see any movement towards a combined effort to clean that mess of proposed frq. between: FGFS(PF12 -> ATC Services in Range) ++ MPmap(AirportLabel -> ATC) ++ oldFGCOM ++ newFGCOM ++ aeronautical charts ++ etc.
2) Technical problems with the Client -sa
  • The old version could be started by
    Code: Select all
    /home/emmerich/fgfs/install/fgcom/bin/fgcom
    Thus the user could e.g. just pull the program into a command-box and start it - or use FGCOMGUI and just give as program the "path/fgcom" (as required and prompted by the FGCOMGUI)

    the new one must be started with
    Code: Select all
    cd '/home/emmerich/Downloads/fgcom/bin' && ./fgcom"
    i.e. it cannot be used by FGCOMGUI

    I am not the programmer, but I am pretty sure it should be possible to avoid this problem finding the path of the ".../fgcom/share"-directory based on the ".../fgcom/bin"-directory within the program -- as done in the old version!
  • There still exists the problem that the 6digit frequencies cannot be used by the "old" clients. According to today’s design the "new" clients are able to work with both - but the "old" clients cannot receive those (more realistic) 6digit frequencies from the "new". Also I miss any drive in trying to coordinate the frequencies suggested e.g. in FGFS (PF12 -> ATC Services..), MPmap (Airport labels -> ATC), etc.
3) Problems in Technical User-Support
    Let me give you an example for why the user-support is rather frustrating as of now:
    e.g.: The advise to start the new client was:
    F-JJTH wrote:Download your FGCom version depending on your operating system, then unzip it, now you are able to run FGCom-sa from a command line as we have done it for many years.
    I started like that - but failed! Because the starting command-line is since many years (ref http://wiki.flightgear.org/Fgcom#Start_FGCom):
    Code: Select all
    fgcom -Sdelta384.server4you.de

    To achieve the same you now need the command:
    Code: Select all
    ./fgcom -Sdelta384.server4you.de

    But the answer to my "cry for help" was:
    F-JJTH wrote:This is not the line I gave in my precedent post, I can't help you if you use some custom command that I don't know
    the line that was given is (for Linux 32):
    F-JJTH wrote:wget http://fgcom.flightgear.org/download/fg ... inux64.zip && unzip fgcom-2.99.0_linux32.zip && cd fgcom/bin && ./fgcom"

    Well now - even a stupid user knows that we should not really download the whole program whenever we just want to start that program. But most users (dumb like me) will become frustrated (like me) and find another way to figure it out without ever asking engineering again (or may even never try FGCOM again)! And quite frankly: That is not the last level user-support I believe we need!
jomo / ATCjomo
ATC at EDDF Fr,Sa,Su,We from 20:00 to 24:00 CET/MEZ., see http://www.emmerich-j.de
User avatar
jomo
 
Posts: 831
Joined: Thu Feb 12, 2009 6:46 pm
Location: Mainz, Germany
Callsign: jomo jomoATC
OS: UBUNTU 17.10

Re: FGCOM Conversion Problems

Postby jomo » Thu Nov 07, 2013 6:00 pm

It seems there is not much movement in the direction of a smooth change-over from the old to new FGCom - but the confusion increases for users what to do.
In the meantime I did change the http://wiki.flightgear.org/FGCom to point out the possibility to use "fgcom.flightgear.org" for testing - but use server "delta384.server4you.de" for bigger events, as of today.

But even http://lenny64.free.fr/ does not react to my past 2 personal appeals to remove or at least correct his page-header:
Server setting
Please you are welcome to use the official FGCOM server fgcom.flightgear.org.
This server allows you to see who is on FGCOM and on which frequency. For more info, please refer to http://fgcom.flightgear.org/
In order to prevent further confusions I will not post my EDDF-ATC-sessions any more on that page - unless it is corrected.

I am very sorry to be forced to that move, because that Flight-Plan page belongs to the big advantages made in the FGCOM-project - and I was one of the supporters! But as I stated before: I will do everything I can to continue promoting the FGCom-project - and that includes helping current users to continue as undisturbed as possible - otherwise we might loose them in all that confusion.
sorry
jomo / ATCjomo
ATC at EDDF Fr,Sa,Su,We from 20:00 to 24:00 CET/MEZ., see http://www.emmerich-j.de
User avatar
jomo
 
Posts: 831
Joined: Thu Feb 12, 2009 6:46 pm
Location: Mainz, Germany
Callsign: jomo jomoATC
OS: UBUNTU 17.10


Return to FGCom

Who is online

Users browsing this forum: No registered users and 1 guest