Hello Jomo,
jomo wrote:Sorry that my point is actually OUTSIDE FGFS!! Generally I agree to your 3 points above
Firstly let me express that in this instance, YOU are the ATC, so YOU make the rules how pilots may contact you.
Then there are different entities we need to separate cleanly.
- FGCom-3.0: this is the currently, FGFS-integrated voice client
- FGCom-mumble: this is a new mumble-plugin, about which i talk here. It has nothing to do with fgfs or FGCom-3.0 and is a completely separate development. Basicly, its just a DLL that will get loaded from the mumble client (starting with the future mumble release 1.4.0).
- FGFS: this is, in view of FGCom-mumble, just a client, that supplies information about location and radios.
- ATC-Pie/OpenRadar: that are ATC-clients and again have nothing to do with FGCom-mumble. Both however support the FGCom protocol and are thus able to connect to the FGCom-mumble plugin, so you can use the ATC-integrated radio stack.
ATC-Pie's integration is very good, but Openradar is just basicly implemented, and, in addition, has a bug (see below).
As a principle, FGCom-mumble (which is not to be confused with the built-in FGCom-3.0!) has no concept of "Flightgear" as a specific client. FGCom-mumble offers a generic interface that arbitary clients can use to inform the plugin about the position and radios of the user. They do that using the UDP-Protocol with ASCII/text based messages. They are compatible to the old FGCOM-3.0 messages, so any client that can already talk to FGCom-Standalone is supported. That is at least Flightgear, ATC-Pie (newer versions have native support, which brings some cool features like RDF), and also OpenRadar.
Openradar just supports one Radio (COM1) because of a bug, that also affects the former FGCom-3.0, so its a problem to solve on OpenRadars end (i made a
issue ticket for that, but the dev seems to be out of office for some time now).
jomo wrote: -- but miss a forth one: COMMUNICATE (i.e. not just hear and not just on "fgcom-mumble" channels)
Communcation in mumble has two streams per user: sending and receiving. FGCom-mumble will adjust these streams, when active&in the fgcom-mumble-channel:
- The sending side is not altered in any way. Sending is always possible like in the stock mumble client without loaded FGCom-mumble plugin.
- The receiving side is only altered, when the plugin is active and the client inside the fgcom-channel. Only then are ALL received streams subject to the radio model, that means you only hear the other party, if he tuned the proper frequency, has operable radios, is in range etc.
Turned the other way around, if the plugin is NOT active OR the client in any other channel, the plugin does not do anything, and you can "mumble" as usual.
jomo wrote:1) Can a FlightGear-user communicate via mumble with someone anywhere in the world - even if that someone does not have FGFS installed??
Of course: FGCom-mubmle has nothing to do with flightgear. its just a small DLL, loaded by the mumble client.
All channels work like they do without FGCom-mumble plugin.
- If YOU are inside the fgcom-mumble channel with active plugin, you can send as usual. others will hear you, depending if the use the plugin or not: With plugin, they need to have radios set up etc. Without, they will hear you as usual.
You will not hear anybody, unless the sending party has the plugin active, properly tuned operational radios and is in range. - If YOU are in any other channel, you can always hear others - the plugin is not active there. Same for sending.
jomo wrote:2) Can a ATC without FGCom installed communicate with ALL FGFS-models ?
Yes. Its basic mumble.
However: in case you are doing this in the "fgcom-mumble"-channel, you risk that others will
not hear you if they use the plugin; because you are not supplying radio+location information to them via the plugin.
But why would you do that in the first place? Either you want the radio simulation or you don't... (i see the "but i want both!"-usecase, see below, to keep things more simple).
jomo wrote:Pls accept and consider that communicate does not just include "hearing"!
I do. I separated the crowd in the following two categories: The ones that want a radio simulation (and therefore load the plugin and join the designated channel), and the ones who don't (and don't load the plugin and neither are joining the channel).
For technical reasons, currently only this separation is possible.
jomo wrote:So very clearly: Someone may be ATCing FGFS-users with or without using FGcom on either side! (Maybe due to not yet updated old FGFS-models or even that the ATC uses a completely different RADAR than used today or similar changes to come!!) Is that possible?
Also very clearly: FGCom-mumble does not depend on Flightgear or the Aircraft model. It depends solely on the client supplying the proper UDP-messages to FGCom-mumble; FGFS can do this with the years-long integrated FGCom-3.0-Standalone protocol. That in turn sends the standard radio stack properties, which all to me known aircraft use. Of course, some Aircraft dev may deviate from this and implement his own thing, but then he breaks standards compliance for his client, which would also have affected the FGCom-3.0 implementation. This constitutes a bug to be fixed in the aircraft.
jomo wrote:Pls understand: When I ATC I do not have FGFS nor FGCom running! Also I do not care what kind/level of model I control! I guess that possibility is needed in order to support not only the newest/updated targets!! Also we should consider possible future possibilities as well in FGFS as also in radar as also mumble!
In case of FGCom-mumble, you have the choice if you want to service traffic using that or not - like you already decided with FGCom-3.0 (->you dropped supporting it), and for that reason you may also decline to use FGCom-mumble users.
The "but i want both!"-usecaseThe probably best and most simple option is, to just open two mumble instances (call `mumble -m` resp. on windows adjust your desktop shortcut to `C:\Programme\Mumble\mumble.exe -m`).
- The first instance you use as usual.
- The second one, you activate the FGCom-mumble plugin. You may connect ATC-Pie or OpenRadar to it, OR use FGCom-mumbles RadioGUI to setup your location and radios.
- a) when "normal" clients join one of your airspace channels, you can service them with your normal mumble instance like usual.
- b) the FGCom-mumble users are served trough RadioGUI or ATC-Pie or OpenRadar which are connected to the second mumble client (you just use the PTT-buttons of ATC-Pie/RadioGui/OpenRadar in those cases).
And another (not yet available) option could be, that i add an Option to FGCom-mumble that will, if activated, not touch audio streams from mumble clients without FGCom-mumble-plugin. This will go as following, but has the drawback that you can always just service one channel.
- You have a single mumble instance. You stay in the fgcom-mumble channel with active plugin.
- You tune your radios (in ATC-Pie or OpenRadar or RadioGUI)
- You just hit the PTT-button to speak, regardless of the clients type (FGCom-mumble or just mumble).
- FGCom-mumble users will hear you, when tuned correctly and in range etc.
They respond and are subject to the radio model automatically. - Normal-mumble users will always hear you. You will always hear such users too.
Depending on the radio you PTT'ed, the FGCom-mumble users will receive your words as subject to the radio model (so if you PTT on the TWR frequency, only FGCom-mumble-people tuned in to that will hear the transmision).
Normal-mumble users will hear you regardless of the radio's PTT (so they hear TWR and GND from any participant in the channel, for example)
The multiplex nature of this kind of option made me stay far away from implementing that:
Let's say the fgcom-mumble channel hosts the entire earth: Users without plugin will hear any user on that channel. That is surely no good thing (you will hear GND voice traffic for KSFO for example...).
The Option two above seems way more practical.