Hi all!
I'm maintaining a new incarnation of the FGCOM server that FlightGear uses, and this thread is for all interested in helping me test it out.
Please send me testing reports on this thread so everyone can have input, and send me their experiences.
Testing Night
I'm planning a Many Users at once Testing Night this Thursday 14th at 21:30 GMT, and all are invited to participate.
In preparation for this **** I have populated the server with the full 2018.3.6 version frequency list **** All frequencies should be up and working as long as they were in the 2018.3.6 version of FG. I hope to upgrade this further by building the latest 2020 version of the frequency list and uploading to the server if all our tests work out satisfactorily.
Now, to answer some questions and testing results that were sent to the FGCOM Announcements thread before I started this one, specifically "Simworld2020"... and I'm sorry it's so long.
I think your connection issues on the 8th were because the server machine did updates and restarted. Since the testing server is in a VM on my machine at the minute, the VM did not automatically restart after these updates.
The music you hear at the moment is mostly default phone system exchange music that is installed with Asterisk, the server software that the FGCOM client connects to.
Asterisk is a telephone exchange software and handles MONO audio only at 8000hz via GSM, ulaw, and alaw audio codecs. All other codecs used have to be encoded on the fly and use CPU power to do.
When you "Echo test", use the FGCOM Dialog box to do so because that causes the FGCOM client to open both mic and speaker. If you are an aircraft, you have either mic working or speaker, but not both. Only echo testing done on the dialog box or with a correctly formatted FGCOM External command line will give live audio return.
For Pilot external FGCOM sessions you need to pass the following as arguments to your fgcom binary. Your callsign would be what you are using in FlightGear and not guest, although it works for testing...
--server=fgcom.ddns.net --host=127.0.0.1 --port=16661 --callsign=guest
To echo test with the External FGCOM, pass these arguments to your FGCOM Binary --server=fgcom.ddns.net --frequency=910
Radio Static.
This will be coming from your COM2, usually because FlightGear does a "Text to speech" conversion of metar data and adds an amount of static to the generated voice to simulate distance from the ATIS station. Turn off COM2 when completing further tests or swap it to a known nearby ATC frequency to stop the static.
FGCOM Status Page (fgcom.flightgear.org)
This unfortunately is out of my control at the moment. Any test calls on my server do not show up on the above status page since the status page is running on the original FGCOM server.
COM2 Transmit
Check your keyboard Layout Settings for which key to press to activate COM2 transmit. Or if you have a joystick, you can map COM2 transmit to a different Joystick button than COM1. Built in FGCOM will use both COM1 and COM2 and you do not need any start-up options added.
External versions need a separate instance of FGCOM running for COM1 and COM2. Your start-up options in the simulator launcher need a further two lines added.
generic=socket,out,10,localhost,16661,udp,fgcom
generic=socket,out,10,localhost,16662,udp,fgcom
You then start up Two instances of FGCOM external that point to the ports opened in the start-up options. Looking at the arguments line from before, usually just by changing the port argument from 16661 for COM1 to 16662 for COM2 in another shortcut or shell script, you should be able to run both links or scripts simultaneously for COM1 and COM2 External together and they won't interfere with each other and be completely independent.
Specific Answers
A. Limit the test to COM1 unless there is a specific reason to also test on COM2.
Both may still be used and I'm hoping that people can get both COM1 and COM2 working in due time. However, for compatibility or to start, I personally will be focusing on COM1 Functionality.
B. Specify that it is not necessary to connect to the MP network in order to do these tests.
This is true, and is not a requirement to join Multiplayer to be testing the FGCOM Server. It just provides a live chat link to me if the voice system has issues or is re-booting whilst I have made a live change. When reloading, all existing audio links should still work and all new links are refused until the loading is completed.
C. Either include another --prop command to enable the appropriate dialog box options or instead specify which options in the dialog box must be checked.
I am not that up with what --prop commands I need to give you to sort this out immediately since I was given the ones I have from a code ticket when I started this endeavour. However, always load the FGCOM dialog, Close it and Load it again to see that the server has been selected and not set back to Default. My server will have hold music on 911.000 Music Box.
Also, 700.000 Radio Station works. The Radio Station Frequency plays one sound file ONCE, then hangs up. I was thinking it would be good for Versioning the test sequence at the moment as you suggested as it takes too much getting rid of all music out of the server as it's in multiple folders in different areas. Also just to put it back when the server is about to go "into service" seems too much fuss.
Radio Tuning Range in cockpit
This seems like it's in keeping with reality ( all HF/VHF radio sets do not go up to the 900MHZ range.) Since the F12 radio stack is part of the simulator and not an aircraft that's loaded into the simulator, 900MHZ+ tuning is possible though the dialog to frequencies built into FlightGear. Tuning to random high frequencies (900MHZ+) or frequencies that the simulator does not recognise could cause the simulator or FGCOM, both Built-in and External, to crash. Only use known frequencies in tuning the radio.