information request 3rd party access to DCS VOIP?

Ahoi ED types.

As you know the current standard tool for voice communication for DCS players is the 3rd party SimpleRadio Standalone (SRS).

As well as SimpleRadio Standalone the client for use by players in-game (and external for people using LotATC in an AWACS role) there is the Network Protocol that can be used by anyone who integrates with it.

This has lead to applications such as:

• A 3rd-party ATIS application which is used on major servers such as Hoggit: https://github.com/rkusa/DATIS/
  
• A prototype AWACS Bot: https://old.reddit.com/r/hoggit/comments/dbkea7/overlordbot_preview/
  
• A music player that broadcasts over SRS.
  

Basically the open ecosystem of SRS allows people to do interesting things with voice & DCS.

My question is: What is the plan for the built-in DCS VOIP System? (as described by Wags in https://www.mudspike.com/mudspike-ama-with-eagle-dynamics-senior-producer-matt-wagner/ )

I seem to remember that it was going to be based on Discord and their GameSDK but not sure.

So my questions are:

1. Can you share with us what VOIP solution you are going with?
   
2. Is the technical solution ED is using for VOIP going to be externally accessible? (Externally here meaning accessing VOIP outside of DCS)
   
3. Will ED allow external access?
   
4. Will ED require a bureaucratic process to get such access or will it be freely available?
   
5. Will this access be only to the Lobby system or also to be able to communicate with Clients using Stage 3 radio communication (as described by Wags.
   

I think Wags talk about them on the Mudspike interview.

https://www.mudspike.com/mudspike-ama-with-eagle-dynamics-senior-producer-matt-wagner/

Is ED looking at integrating features like those from the community (like SRS, SLmod, etc)?

 

These are great products, but we prefer to develop in-house solutions that we can better support and avoid core product conflicts.

"...but we prefer to develop in-house solutions that we can better support and avoid core product conflicts."

SRS is one of the most stable things about DCS!

To be honest, I am very wary of ED spending any dev time on this and if the result will be worth it. SRS is simply that great already, that we currently do not need this. Only argument is, that it's 3rd party and minimum effort people use that as justification not to use it. But those people are not really a factor anyway, since they most probably will not interact on a lvl in MP that the extra mile for them is worth it.

We need a lot of stuff far more urgent for MP experience, mission planning tools etc. list is long, pick your poison.^^

Seriously, just accept that you got bested by a 3rd party, man up, and pay a fair licensing fee for SRS.

The potential growing pains that will come from starting from scratch literally makes my stomach hurt.

3rd party access to DCS VOIP?

I think Wags talk about them on the Mudspike interview.

 

https://www.mudspike.com/mudspike-ama-with-eagle-dynamics-senior-producer-matt-wagner/

The interview only talked about that ED is planning to provider their own VoIP solution (at least if I didn't miss anything). The question of this thread though is more about whether 3rd party develops will be able to get access to ED's solution as well.

As the author of DATIS I am really interested in this question as well, because I'd love to be able to update DATIS to also be capable of broadcasting ATIS reports to ED's upcoming VoIP solution, once it is out. This would only need documentation about the ports and packet formats send to those ports (and the approval of course to run such tools).

If ATIS repots aren't enough motivation to provide access to 3rd party devs, since ED is considering to provider their own ATIS reports anyway, we could also focus on more sophisticated use-cases involving text-to-speech and speech-to-text recognition - like the mentioned AWACS bot for example.

Seriously, just accept that you got bested by a 3rd party, man up, and pay a fair licensing fee for SRS.

 

The potential growing pains that will come from starting from scratch literally makes my stomach hurt.

Seriously. You must be new around here.

Just FYI, the modding community has "bested" ED on many things regarding public and private mods as far back as LockOn. Eagle Dynamics over the years have seen and learned what users like and use and have integrated their own versions which in turn most of the time have been better than the competition and better in general. It only makes perfect sense for ED to integrate their own radio and communication system because the support for more than just comms is built into the core.

Seriously, just accept that you got bested by a 3rd party, man up, and pay a fair licensing fee for SRS.

 

The potential growing pains that will come from starting from scratch literally makes my stomach hurt.

I have to agree... why re-invent the wheel. Pay the man for his great work, and have your devs doing more important stuff!

+1 I hope that I could connect LotAtc on this !

With the latest news about Voice Chat in https://forums.eagle.ru/showpost.php?p=4409321&postcount=260

Is it possible to get an update on this request?

I'll try and get some answers to the questions at the bottom.

Thanks very much. We know the answer to the first one is WebRTC. The rest are the open ones.

As for the comments about SRS

Honestly, please ignore those mostly uninformed comments and don't let them derail the requests for information from myself, n26, DArt and other Developers who are working on Voice integration in various ways.

Thank you for the update Kate and a apologies for the late reply.

ED do not plan to provide access to any external software to DCS Voice Chat at the moment.

Disappointing but understood.

We might consider such possibility later on. We are always open for cooperation.

I don't really understand this bit. The requirement is that ED don't restrict access to the voice system. It sounds like is based on open protocols and therefore would be accessible by default and probably only restricted by an authentication system.

So I am not really sure what you mean by "Open to cooperation", could you clarify?

So I am not really sure what you mean by "Open to cooperation", could you clarify?

My perspective, SRS team turn as 3rd party or make your project as LocATC.

My perspective, SRS team turn as 3rd party or make your project as LocATC.

Without going off-topic (I would prefer to keep this thread mainly between SRS based Voice Developers and ED) LotATC will also be badly affected by this change since people will not be able to use it and the voice system at the same time.

Hence my request for clarification from @Kate Perederko .

In the 17 December 2021 Newsletter the announcement has been made that the in-game comms system will be in the next open-beta release.

Has there been any more thought on providing access to the system from outside DCS itself? Any update would be highly appreciated.

Bumping as Overlord is a neat thing.

Agree, please don't shut out modders

20 hours ago, Poulet67 said:

Agree, please don't shut out modders

I've got mixed feelings about the modding arguments in this case. I'm not too sure how valid this case is.

If I understand this subject correctly (i've been busy with non-DCS for a while so I'm not the best guy for this right now) Not allowing access might actually be a safety feature to protect simulation realism and prevent fragmentation in the community rather than shunning of modders.

Way back when I was talking about this feature on wishlist, "DCS Voice Chat" was always going to be an in-game in-house official component in my mind, it's what the actual radio simulation needs, it just never existed before, infact it wouldn't even need to have such a specific name nor be regarded as a separate feature. It's just one of the components that should have always existed but in our simulation reality it takes time and resources to build it, it should operate wholesome with every unit in the game, not something extra. Remember all the discussions of what is "Core DCS thing", this is suppose to be one of them.

I think some people are approaching radio communication from the wrong angle because of it's nature and similarity to computer internet chat, while this is many times necessary in practice for DCS users, particularly multiplayer, as we indeed do have some limitations (physical life, logistics, resources) that we cannot bypass when trying to experience the simulation, but that's not really a thing as far as simulation of the airplanes and it's radios is concerned, and extra features modding might do on top of to this system might go outside of the radio simulation and might over-convenience some aspects of chat and promote less realistic experience overall. The kind of applications that may be developed by the use of DCS Voice might be cool but if those tools are then used as a standard ... did someone weight if they might be unrealistic and giving an advantage over reality. I am however speaking generally here, I do not currently know nor I have spent speculating what would be the features and capabilities the modders would want to add on top of DCS Voice, so that's actually a good question for the OP here, what actually are you trying to do that you can't do without API access?

The primary thing from the realism point of view is the simulation of the radios, not our computer internet chat, just like radars, it involves electro-magnetic radiaion that has a lot of depth to it, many factors affect the radio signal and this is reflected in the way we hear the audio signal, noise, volume, static, clicks, interference (environmental), jamming, knife-edge effect, antenna orientation, antenna radiation pattern, need to be simulated the same wholesome way as other components the focus was on all these years, it can't be just a bolt-on, because it's not about internet chat, that's just our convenience.

To me, modding solutions to these well-known to-be-developer core components were always seen as temporary, stopgaps.

The DCS Liberation mod is suppose to be the same thing. I hope it's just meant to be a fun project that while is not technically necessary, attracts the community, gives the upcoming DCS feature more interest and might even assist passively in the development because of the participant's exchange of thoughts and visions about the system, so it is healthy to have such projects, but not that these projects would then refuse to retire, but I do know how it's like to be emotionally attached to a creation, that's why it's important to realize sooner rather than later of the limited nature of such stopgap projects, so that it would be easier to digest the retirement later on. The effort done in the modding project and the results at retirement should be redirected to the main course and then those caretakers would be available to start another project in an area where a stopgap solution is lacking.

Eventually, for a greater (*proper*) realistic "hardcore" dynamic-campaign experience, the DCS in-game communication simulation system should absolutely keep going pretty much everywhere for the duration of the battle session, even if the session is paused and resumed (not a thing, wishlist) or you come back to the session on a MP server later. Some aspects are debatable, but generally whatever state you are in, considering if is simulated, let's for example say that in case everything is, aircraft or not, every unit you're using, you shouldn't be able to switch to computer voice chat and talk with everyone unimpeded, using an unrealistic service to gain information and giving them information that would affect overall gameplay.

Currently because a lot isn't yet simulated, you have no choice but to swtich to Room Mode as soon as you eject, though unless DCS would purposely prevent that even before CSAR and pilot radios are implemented? Probably not, still, everyone using a lot of traditional internet chat which I'm not sure but think is being used unimpeded (I'm sorry I actually don't do MP a lot, yet) should start thinking about these limitations and prepare for these proper limitations, because, not necessairly intentionally, but unintentionally gave away a lot of information that affected gameplay while bypassing realistic limits, similarly to how TGP displays we were experiencing all this time were reportedly way too good quality and we shouldn't have seen all the detail we did, some people may have harder time getting used to such a substantial change and it's good to start the psychological transition early, to assure the mind the change is proper and get rid of the old habit.

Back to the eventual proper scenario, there should be a MP server admin setting to disable Room Mode, so after you eject, all you should be able to do is communicate via the radio you get from the ejection suit or seat, and/or hope that the emergency rescue radio beacon got activated and wait for CSAR. Whether direct or relay, respecting the physical limitations. Additionally, the good simulation of what a crashed pilot is usually suppose to do, like safe landing, finding a hiding spot, contacting and interacting with CSAR, survival on ground, recon of the area for extraction zones, should give focus on resourcefulness, so if you do get into a direct contact with your buddy, flying nearby, the sim forces you to talk only the most relevant stuff, in your opinion ofcourse. As a pilot on ground you are busy with other things, so DCS Voice and whenever CSAR comes and actual virtual debreifs at a base location in-game (only for in-session), it will reshape the way comms are done in DCS in many ways. Coincidentially for those FPS fans, this is where DCS would get pretty close to first-person shooter style gameplay, without taking infantry warfare into the equation, because it can be quite a part of the CSAR component.

----------

Not having Room Mode (or any other external unimpeded comms) should not mean you wouldn't be able to communicate with your buddies/allies without direct radio contact, DCS should eventually, as per the radio simulation across all units, support AI relaying functions. In this case I'm talking about an actual signal relay where each ends of the comm link can hear each other as if it were a directly comm link, if the radios in the relaying units have such a "repeater" function (tho I only know the old A-10C Radio has it, but if that has it, any AWACS surely has it too), it's the similar kind of function as your Wifi Repeater for your home internet (tho rather go Ethernet wired only, it's healthier and more reliable :p)

Example1: Ejected Pilot(Human) -> closest CSAR unit (AI/Human) -> Squad Member in Aircraft (Human)

Example2: Ejected Pilot(Human) -> CSAR Unit (AI/Human)-> ... -> AWACS or ATC (AI) -> Squad Member in Aircraft (Human)

The other mode of relaying is just forwarding the kind of predefined radio commands and request we're already doing right now, it's just that you can't relay them AFAIK, this would be used when the target is an AI ... at least until DCS implements AI unit voice recognition which is a whole other discussion of feasibility and depth of recognition I won't go into right here. In this case

These two modes are in on top of the standard dynamic AI-to-AI communication that the DCS dynamic-campagin engine AI system should use to manage all the units across the battlefield, issue orders, give headings, update locations, so you don't really have to, as an Ejected Pilot, contact any CSAR for help, the AI that saw you crashing, the locator beacong going off, the AI that can't get your reply and signal rom datalink would already contact the higher command and CSAR will beging searching for you and they'll talk and exchange info amonghs themselfs automatically. Just for full realism, this intra-AI communication should also use the same comm link and respect physical limitations as humans have to, not sure if this will be so when dynamic campaign launches initially, depends whether the big radio comm overhaul happens before or not.

It gets hard when you try to have direct relay beween two humans but one of the AI's in the middle does not have that capability, this would require AI to analyze speech, again probably not happening anytime soon, or no? You'd just get reply back that direct relay isn't possible and should use the pre-defined message forwarding instead, the target unit wuld then hear audio of an AI tellhim

Now I say pre-defined because I'm on the reserved side of what's possible, it might be possible to create a dynamic system where you could input different parameters not just the pre-defined options we have today, "Tell my target to go to heading: (insert or speak custom numbers )", perhaps a simple set of AI voice recognition could be implemented to recognize numbers. Additionally you could have the signal be affected by interference factors and have that voice recognition hear that. I'm not really sure of the feasibility of full blown voice recognition for AI aircraft.

However, DCS eventually needs a system to prevent relaying absue particularly if Room Mode is disabled. Room Mode or not, in real life the military point of view "waste of resources" or "unnecessary" would be the valid reasons, because providing relays takes resources, attention, effort, unavailability to do other tasks, etc so it can affect gamplay a lot more than it seems.

Relaying Priorities:

This would be a system that many AI components would be aware of, the high-command AI engine (dynamic-campaign) and the units themselfs.

The standard factors are ofcourse the individual unit's own availabilities. If the unit is in combat it probably won't be able to provide steady relay at all. If the unit is just cruising then it can easily provide relay and even change course to provide better relay for a longer period of time.

As a player in a dynamic-campaign scenario you shouldn't be able to get relays as you please, the whole AI comm and relay system should use a priority system. The bigger (coalition) scale should be taken into account as well, to prevent relaying "abuse", because the Master AI, which would behave to how a real military would, won't just let you use up unit availability and resources for your potentially unnecessary, prolonged or completely off-topic relay links, even if the individual unit might be able to keep relay link ongoing, the Master AI might step in and determine that the relaying unit needs to do something else, giving it a different task elsewhere in the battlefiled where urgent support may be necessary.

Naturally, if you're an ejected pilot, CSAR-related comms and relay requests would be high up on the priority list, treated with high or maximum priority, but there's a catch, only up to a point that is necessary for the situation.

And this can get quite complicated, it would take some effort implement the priority system.

Factors such as whether or not you are in the same squadron, reigment, wing, etc would matter, and affect the priority of your relay request.

Location or zone that you're trying to contact should matter, is the target of your relay request even within the vicinity of your crash, is it even inside your mission zone, etc.

An ejected pilot that should be thinking about CSAR-related duties should not easily get direct-relay with some random ally unit in a totally different location, outside of the ejected pilot's mission zone, performing a completely different task, that was totally unrelated. For that ejected pilot to know their location in the miitary structure, name, rank, ID numbers, it's highly likely it would be an attempt to chat with a off-militay buddy about off-topic things. Some familiarity of military operations that I have, I do not believe a real military would be eager to fly, spend fuel, open relay channel, if they were all hearing the relayed messages (I think they do?), to provide long-distance phone network for 2 to talk about the sunday's airshow or whatever which is not really necessary for the current situation, so DCS needs to do something to simulate this without spending a big deal on processing requirements. This is the scenario human players in DCS might try to poke into, when an ejected pilot would wait for CSAR and feel bored, would want to contact some other truck driver 400 kilometers away. While off-topic chat doesn't hurt (cheat) gameplay, it would still take resources away if the relaying units need to be in position and unavailable for some duties in order to provide the good relay signal, so this anti-abuse priority feature should be an integral part of the radio overhaul in DCS when support for full relaying comes to AIs. Ofcourse this is all from the DCS Voice point of view, we can't control whether those two use an external chat to communicate, this is for the torunament organizers to figure out a way to enforce and prevent potentially cheaty comms.

For a low priority relay to work, all units which are relaying would need to be in state that allows them to even accept low priorities, cruising and not doing anytihng in particular, additionally, they would only provide that low priority relay

It's not the player/source who sets the priority, might as well set it, but the relaying units would change it  when forwarding it to the next relaying unit, or the Master AI should be able to override it.

So you could for example select max priority:

Ejected Pilot (P:10/10) -> CSAR-1 (P10:10) -> CSAR-2 (P10/10) -> AWACS-1 (P: 4/10) -> Airbase (P:2/10) -> AWACS-2 (P:2/10) -> Ground Command Post (P:2/10) -> FuelTruck-Driver-007 (Destination)

The CSAR units will try to do everything in their power to do so ASAP, unless any other emergency factor prevents them to respond to priority 10 relay requests (max), such as being under fire or low-fuel. The reason why CSAR units in this case wouldn't downgrade the priority themselfs is because they (as also in real-life probably wouldn't) don't know where exactly your destination is, they might, but in this example they don't, unless they would ask the higher command to tell them, but I think this isn't usual military operation, I believe in real-life they would just let the higher-command deal with that themselfs, so they relay the same priority they got from source. The AWACS is the first that downgrades the priority in this example, because it knows or it figured out (attempt to contact, no reply timeout, a thing for DCS simulation depth in comm delays) that target unit is not in it's area of reach, then the Airbase gets the request with priority 4 and if it can it does handle it as a priority 4 request, again the factors if the AirBase is in a state that is able to process priority 4 requests (so not preoccupied with base defenses, airport activity, etc), but the AirBase, which has more info on units on the whole battlefiled (as a component of the master dynamic-campaign AI) sees that the target/destinatinon is even further out, requiring another AWACS relay, so it further downgrades the priority before sending it to the next relying unit. The second AWACS receives priority 2, not 4, AirBase downgraded it, so the second AWACS would respond only if it's available to respond to priority 2 requests, so that AWACS has to be relatively free of occupation, not refueling, certainly not under fire, probably circling without much other relaying radio traffic, the AWACS-2 might do it's own priority recalculation whether to downgrade or forward the request with priority as it is, same for the Ground Command Post, each unit would have it's own AI component recalculating whether to change the priority it sends to the next. Only after this journey would it be down to the FuelTruckDriver-007 to see if it can respond.

That is, if real militaries would even allow for such a relays in the first place, direct ones, but then again we're at that question of whether we simulate full technical realism and allow all posibilities even if the military structures in real life have artifical limits in some ways. It might just involve 1 to 2 hops of direct relaying, then the higher command would take it and repeat it with their own mouths to the destination through more relays which would use their own mouth to repeat their relative source (not the original source audio), off-topic would most likely not have good chances of going through and would be denied in real-life, the source wouldn't even attempt it IMO, otherwise each stage would probably filter more out on their own, but we do not have the ability in DCS to have a super AI that scans all talk and thinks what's not necessary to spend relay resources on. But this is the kind of system I came up with right now to simulate the artificial relaying limitations a real military might have while keeping it technically possible.

Alternatively if DCS ever supports human players in all* roles of the chain, which I already have thoughts written down on notes and probably spoke about it in wishlist threads, simulation of the command structure by AI in that case would already have to be a major part of dynamic-campaign, how diverse the AI structure is planned I do not know. Eventually it could be human controlled, having an advanced situational view, and that's why flyable wide-body jets aren't a joke, someone needs to fill AWACS/tanker/ground command and outposts too for this to function,  higher commands, AWACS roles, and the whole thing with human players.

Cases where the relaying units would upgrade your priority would be squad leaders trying to get direct contact to higher command, so the rank is also a factor, might get upgraded, or not downgraded as much.

Priority may not need to be user selectable when making an inital request, because such a thing does not exist in real life is one reason, secondly if the units can't handle high priority they'll not be able to handle lower either and if the source does select a lower priority knowing it likely won't get a contact with higher priority through, their request would just be forward with the same priority they selected, without any difference in the end result versus if they selected a higher priority, because they would get automatically downgraded anyway.

It might be simpler and well functional for the initial priority be an internal hardcoded one based on unit types and their tasks (and perhaps states) that would be predefined in and not adjustable by any player or AI in a session (unless modding), for example an ejected pilot contacting a CSAR unit or a unit in CSAR mode at the time of relay request, would have a priority of 10, automatically, without any pre-thinking by the receiving unit, the CSAR unit AI and the whole DCS AI's down the line would know the source is a pilot without it having been figured out by any of the AIs or the master AI or whatever. This is the first stage, the CSAR unit then sees priority 10 and starts behaving accordingly, and then comes the rest I talked about.

That would look like:

EjectedPilot1 request to EjectedPilot2 (different aircraft type, different mission zone, different rank, different task, different squadron, 800 km) == priority 1 -> CSAR-1 (P:1/10) -> CSAR-2 ...etc

I felt enthusiastic today so I dug deep into this one, now I feel this could be way simpler, while still a similar safety net for simulating difficulty and necessity of long-distance relays. You can ofcourse hardcode the priority by source and destination, distances, check the lookup table and if it's too low get an instant denial for relay even without sending any request to any AI, and the AI's dealing back and forth.
 

11 hours ago, Worrazen said:

I've got mixed feelings about the modding arguments in this case. I'm not too sure how valid this case is.

If I understand this subject correctly (i've been busy with non-DCS for a while so I'm not the best guy for this right now) Not allowing access might actually be a safety feature to protect simulation realism and prevent fragmentation in the community rather than shunning of modders.

The way I would set it up would make it completely up to the servers if they allow access to their server's system or not according to the goals they want to achieve with their servers.

The rest of your post would probably be better as a separate thread as, as far as I can tell, it goes very off-topic from this request and more into "hard-coded" DCS behaviour.

On 12/18/2021 at 2:13 AM, NineLine said:

I've asked the team for more info for sure. Thanks.

Hell yeah. Overlord bot has been a game changer for MP flying, it would be cool as hell to see it continue on with the official DCS comms update. 

5 hours ago, rurounijones said:

The rest of your post would probably be better as a separate thread as, as far as I can tell, it goes very off-topic from this request and more into "hard-coded" DCS behaviour.

Yep, that's one of my bad habits I can't shake off lately when I get enthusiastic I want to put it down on paper and can't easily stop. I'll fix it and I actually partially did here

On 12/19/2021 at 5:21 AM, Chiwie said:

Hell yeah. Overlord bot has been a game changer for MP flying, it would be cool as hell to see it continue on with the official DCS comms update. 

+1

Interoperability should be considered too...