Voice Chat - Thoughts & Opinions on what is needed for widespread community adoption

[Aarnoman]

As a longstanding strong proponent of voice communication in games, and with a long history of using voice communications including SRS, TFAR (Arma), and DCS native voice chat, I have decided to create the following list of obstacles that I think will need to be addressed for widespread community adoption of the native DCS voice chat. With the 2.7.9 update, we have taken a significant step in the right direction, but we still have quite a long way to go. The following points are based on my personal thoughts and experiences, discussions with other discord users, and community comments including server owners in the wake of the recent release of the improved voice chat.

All discussion following referencing "voice chat" will be referring specifically to the native voice chat implementation in DCS.

 

Simplicity in setup

One common argument that has come up repeatedly is that more options are better, and that options of room mode/radio mode/etc should be customizable by the end user. I want to address this argument first, as I have seen it used commonly to derail discussions about further points outlined below.

Voice chat first and foremost relies on sufficient community adoption. If not many people use it, it quickly loses its purpose, as less and less users will go through the trouble of setting it up to work for them. This is something we see currently - very few servers have voice chat enabled, as other more powerful and intuitive options such as SRS are available.

Simplicity and intuitiveness mean the following to me in the context of voice chat:

• Minimal steps should be required by the user to set up and enable voice chat.
  • Voice chat should be enabled by default (once the system is mature enough).
  • PTT keys should be easily bindable by the user.

 

 

On rooms and radio frequencies

In the current implementation of voice chat, there are two modes - room mode, acting like a discord room, and radio mode, where you transmit on in game selected radio frequencies (as picked in the plane). There are a few issues with this, specifically the following:

• By default, once loaded into a plane, the user remains in room mode. Most users are not even aware that you have to manually switch to radio mode to transmit on selected frequencies. From discord discussion including input from @Ciribob (SRS creator), a general consensus as follows was reached:
  • Both room and PTT mode have a purpose in context of DCS.
  • Room mode should be available for voice discussion restricted to users selected side while the user is in the lobby, spectating, or using the mission planner - effectively any time not loaded into a plane.
  • Once the user loads into a plane, voice chat should immediately and automatically be moved from room mode to PTT/radio mode, where in game selected frequencies are used.
  • Once loaded into a plane, room mode should be unavailable. This ties in with the earlier point on simplicity and intuitiveness, as most users expect to use the in-game selected frequencies to communicate. This creates the best of both worlds - a room mode available for planning/discussion akin to a briefing room prior to flight, and use of the planes native radios for voice communication once loaded in game. This mirrors real life (-> intuitive) as well as how the community uses SRS to communicate once loaded into a plane. It also provides the ability to brief/discuss/plan with your side before boarding a plane, allowing for coordination that is not possible using SRS currently, and has been requested by community members a number of times in the past.
  • The reason that room/PTT radio mode should NOT be an end user options is as follows:
    • Room/radio users are not able to communicate with each other, so by allowing this options selectable it will create barriers for entry, as the user may not be aware of which voice chat mode they should be in for a given server.
    • This leads to confusion, which may put users - particularly new users - off from using voice chat altogether, leading to decreased use. This again ties in with the ethos from earlier - it requires widespread adoption to be successful.

 

Quality of life features

A number of quality of life additions are needed to the current implementation of voice chat to make its use easier and more immersive.

• Clear aural feedback that the user is transmitting. This means having "radio clicks" when engaging/disengaging the PTT buttons. Currently, voice chat does not have this.
• Radio effect to received voice chat - already planned, but will add to the authenticity. SRS is an excellent example of how this can be done. Ideally, some option (e.g. minimal/realistic) to the level of distortion should be selectable, to aid users with existing hearing impairment/foreign language users/etc.
• Default keybinds for all modules, with option to override these per module.
  • One option for doing this would be as follows:
    • Default Radio 1->9 PTT keybinds in voice chat keybinds under its own category. This by default applies to every module in DCS.
    • In the specials tab, for every module have a checkbox (default disabled) for "Use custom Voice Chat PTT buttons".
    • For every module, have a keybind section for "Custom voice chat PTT". This can then be bound on a per module basis.
    • Now, the user can easily create a default profile for most modules using the specific general voice chat keybinds, and also have per module keybinds for ones where a different profile is desired, that can be enabled for that module specifically using the options -> special -> [module] tab.

 

Other barriers to community implementation

With SRS now long established as the preferred community voice chat tool for DCS, a number of additional hurdles exist for DCS native voice chat to overcome to see it receive widespread server and community adoption. The previously discussed points are all important influences, but a number of additional hurdles also exist:

• Voice chat requires a degree of API access for mod developers. Specifically, established tools such as ATIS, Overlordbot and Hound ELINT are not able to be integrated with voice chat currently, leading to decreased server adoption in lieu of SRS, therefore hampering community uptake. Either native alternatives to these tools would have to be developed by ED, or voice chat API access would need to be allowed for mod developers to allow the integration of these tools with DCS voice chat.
• External voice chat access for GCI/AWACS. This means being able to connect to a servers voice chat without being in a plane, to allow for users (e.g. of LotATC) to act as a GCI/AWACS for fellow players. An alternative would be to have a dedicated slot(s) available in mission for users to join as GCI/AWACS, with access to the in game radio.

 

 

This post is intended as a summation of the most integral features needed for widespread community adoption. Simplicity, intuitiveness, and community support are needed for DCS voice chat to be successful.

SRS servers as an excellent template of how the community intends to use voice chat, and many useful lessons can be learned from observing how the community currently uses it. DCS voice chat has a number of advantages to SRS, the most significant of these being the lack of setup required to get it working in the first place. Additionally, by integrating the room mode for briefing/mission planning/spectating and exclusively forcing PTT/radio mode while in a plane, DCS voice chat will have a range of features not currently available in SRS, assisting in its adoption.

Ultimately, voice chat needs to be simple to set up, intuitive to use, yet remain powerful and capable like its predecessor SRS - it requires server and community adoption to be successful, as voice chat without uptake loses its purpose. I wish the DCS developers all the best, as there is huge potential in transforming the DCS experience using voice chat, particularly if largely adopted by the community.

 

 

 

 

[evanf117]

i found it odd all the ptt keybinds, shouldn't it be plane level, ie the MiG-21 has a PTT on the stick and you can bind it so it brings up the radio, that should be the ptt for the MiG-21

[Worrazen]

On 12/26/2021 at 5:27 AM, Aarnoman said:

Other barriers to community implementation

 

With SRS now long established as the preferred community voice chat tool for DCS, a number of additional hurdles exist for DCS native voice chat to overcome to see it receive widespread server and community adoption. The previously discussed points are all important influences, but a number of additional hurdles also exist:

• Voice chat requires a degree of API access for mod developers. Specifically, established tools such as ATIS, Overlordbot and Hound ELINT are not able to be integrated with voice chat currently, leading to decreased server adoption in lieu of SRS, therefore hampering community uptake. Either native alternatives to these tools would have to be developed by ED, or voice chat API access would need to be allowed for mod developers to allow the integration of these tools with DCS voice chat.
• External voice chat access for GCI/AWACS. This means being able to connect to a servers voice chat without being in a plane, to allow for users (e.g. of LotATC) to act as a GCI/AWACS for fellow players. An alternative would be to have a dedicated slot(s) available in mission for users to join as GCI/AWACS, with access to the in game radio.

 

I'll try to reinterate what I hastly and unclearly wrote in an earlier post that I will avoid linking to now. I'll reiterate the elephant in the living room here I think, at least to me. It is apparent that things like SRS and other things that may or may not rely on it are infact just temporary community stop-gap measures to ease the wait until the actual feature officially supported and integrated with all the other subsystems across DCS.

Absolutely good on all of you who supported and contributed to these great community projects, but, I would like to, in the spirit of realism that we're trying to simulate, offer a bit of a reality check.

So why would the lack of API access prevent it's usage and uptake ... if DCS Voice, eventually will be able to do everything these community mods and utilities can do and more. There shouldn't be any need for these temporary utilities anymore, optimally.

I hope people who are developing them are fully familiar with this most probable reality, that they are regularly re-evaluating how much effort spent into them is worth it depending on the hints and news of incoming mirror features DCS would officially support, and it would be quite rude for such community people to pony up some made up reasons to try to continue their pet projects, claiming some things to justify further relevance and it's development. It would be best to keep this finiteness in mind and to simply let it gracefully retire. I understand people can be emotionally attached to creations and legacy built around these community projects, but it would be most healthy for DCS, it's developer and the whole DCS community to not have things actually be in the way of DCS evolvement, sort of. This is why such community contributors should seek out and start new relevant supplemental projects earlier, so that they have somewhere to continue to put their energy any passion into much quicker, ahead of the retirement of the current stop-gap supplemental utility or mod, this should ease out and might even extinquish any bad feelings about the loss of relevancy of the current stop-gap.

There is justified reluctancy from DCS developers to provide API access. Instead of spending time to evolve DCS, they would spend time developing a subset of the API available to the general public and maintaining it's functionality across updates; ... is that really the best use of their time, does that help DCS as a whole in the long-term. Furthermore, it may not just be simple access like a flip of a switch, even if it is, I think they would only unnecessairly encourage such temporary stop-gaps to continue dragging on, while the community as a whole would actually be lesser off in the long-run because of the side-effect of the stop-gap development efforts never moving onto other and newer supplemental DCS community projects, particularly in areas that are lacking and may not even be officially planned for the near or even long term.

I think it would be a bad example of negotiation and unfair if someone takes this lack of API access here and argues that ED doesn't support modding in general. API access is something quite a bit more than just modding, modding it self isn't an established standard anyway, in regards to how much has to be moddable or how easy should it be. Yes the customers do have a voice and vote but it is still down to the specific game, product, platform, demographic, ecosystem, market, etc, and a more complicated relationship between the community and developers determines the right balance of modding access. The kind of API access you're asking here, modding level access, is the most open of them all, the DCS developer gets absolutely nothing too metered in exchange, benefit in new players (customers) attracted by the solutions using the capabilities of that access is only vaguely potential and hard to guarantee.

Ultimately it's about simulation and the replication of systems and mehanics of the real world. The DCS developer has taken upon themselfs to simulate reality in such a wholesome way, then it's their job to worry about it. They or anyone could indeed decide to go for a modular and open-source approach, but it's a completely different model, mindset, philosophy and a lot of other things that would require either a whole market or a vision change for the company. Technically a modular approach would also change the way he end product would function and behave, you could say it for the better, but I think it's always a set of trade-offs. During my recent deep dives into Linux (3 distros on 3 PC at once :D) I've seen many cases where modularity isn't always the best approach, I can't remember the exact example right now, stuff like lack of updates to some dependency that provides a feature that should be considered core/basic, etc and the idea of "others will take care of that side of the system". Fracturing these systems into various random github scripts is just not really sounding like what DCS vision was, tho this paritcular API access might not necessairly become such a scenario ofcourse, I'm speaking in general as well.

I am not on the side of one or the other, I chose to dwelve into why there wouldn't be access. If it works out for both sides and access is granted than that's totally fine.

There can be no limit, a modder could use these same original arguments of "VoolKhan is an established community 3D-graphics engine, please open up the access so we can integrate into DCS" or whatever. Or the sound engine does not have API Access so we can't integrate our binaural-audio plugin, or something.

If I'm technically wrong in any of this then I am absolutely open to correction. Disclaimer: Unfortunately trying to be the voice of reason a bit ahead of my self again. I never used SRS nor any of these mentioned community projects, ehm, yet. I am well into all things PC and tech in terms of HW and SW and I do a lot of work with PC, to the point that playing games is pretty low sometimes, so that's where I'm pulling the wisdom from for this post.

Edited December 28, 2021 by Worrazen

[Aarnoman]

1 hour ago, Worrazen said:

 

I'll try to reinterate what I hastly and unclearly wrote in an earlier post that I will avoid linking to now. I'll reiterate the elephant in the living room here I think, at least to me. It is apparent that things like SRS and other things that may or may not rely on it are infact just temporary community stop-gap measures to ease the wait until the actual feature officially supported and integrated with all the other subsystems across DCS.

Absolutely good on all of you who supported and contributed to these great community projects, but, I would like to, in the spirit of realism that we're trying to simulate, offer a bit of a reality check.

So why would the lack of API access prevent it's usage and uptake ... if DCS Voice, eventually will be able to do everything these community mods and utilities can do and more. There shouldn't be any need for these temporary utilities anymore, optimally.

I hope people who are developing them are fully familiar with this most probable reality, that they are regularly re-evaluating how much effort spent into them is worth it depending on the hints and news of incoming mirror features DCS would officially support, and it would be quite rude for such community people to pony up some made up reasons to try to continue their pet projects, claiming some things to justify further relevance and it's development. It would be best to keep this finiteness in mind and to simply let it gracefully retire. I understand people can be emotionally attached to creations and legacy built around these community projects, but it would be most healthy for DCS, it's developer and the whole DCS community to not have things actually be in the way of DCS evolvement, sort of. This is why such community contributors should seek out and start new relevant supplemental projects earlier, so that they have somewhere to continue to put their energy any passion into much quicker, ahead of the retirement of the current stop-gap supplemental utility or mod, this should ease out and might even extinquish any bad feelings about the loss of relevancy of the current stop-gap.

There is justified reluctancy from DCS developers to provide API access. Instead of spending time to evolve DCS, they would spend time developing a subset of the API available to the general public and maintaining it's functionality across updates; ... is that really the best use of their time, does that help DCS as a whole in the long-term. Furthermore, it may not just be simple access like a flip of a switch, even if it is, I think they would only unnecessairly encourage such temporary stop-gaps to continue dragging on, while the community as a whole would actually be lesser off in the long-run because of the side-effect of the stop-gap development efforts never moving onto other and newer supplemental DCS community projects, particularly in areas that are lacking and may not even be officially planned for the near or even long term.

I think it would be a bad example of negotiation and unfair if someone takes this lack of API access here and argues that ED doesn't support modding in general. API access is something quite a bit more than just modding, modding it self isn't an established standard anyway, in regards to how much has to be moddable or how easy should it be. Yes the customers do have a voice and vote but it is still down to the specific game, product, platform, demographic, ecosystem, market, etc, and a more complicated relationship between the community and developers determines the right balance of modding access. The kind of API access you're asking here, modding level access, is the most open of them all, the DCS developer gets absolutely nothing too metered in exchange, benefit in new players (customers) attracted by the solutions using the capabilities of that access is only vaguely potential and hard to guarantee.

Ultimately it's about simulation and the replication of systems and mehanics of the real world. The DCS developer has taken upon themselfs to simulate reality in such a wholesome way, then it's their job to worry about it. They or anyone could indeed decide to go for a modular and open-source approach, but it's a completely different model, mindset, philosophy and a lot of other things that would require either a whole market or a vision change for the company. Technically a modular approach would also change the way he end product would function and behave, you could say it for the better, but I think it's always a set of trade-offs. During my recent deep dives into Linux (3 distros on 3 PC at once :D) I've seen many cases where modularity isn't always the best approach, I can't remember the exact example right now, stuff like lack of updates to some dependency that provides a feature that should be considered core/basic, etc and the idea of "others will take care of that side of the system". Fracturing these systems into various random github scripts is just not really sounding like what DCS vision was, tho this paritcular API access might not necessairly become such a scenario ofcourse, I'm speaking in general as well.

I am not on the side of one or the other, I chose to dwelve into why there wouldn't be access. If it works out for both sides and access is granted than that's totally fine.

There can be no limit, a modder could use these same original arguments of "VoolKhan is an established community 3D-graphics engine, please open up the access so we can integrate into DCS" or whatever. Or the sound engine does not have API Access so we can't integrate our binaural-audio plugin, or something.

If I'm technically wrong in any of this then I am absolutely open to correction. Disclaimer: Unfortunately trying to be the voice of reason a bit ahead of my self again. I never used SRS nor any of these mentioned community projects, ehm, yet. I am well into all things PC and tech in terms of HW and SW and I do a lot of work with PC, to the point that playing games is pretty low sometimes, so that's where I'm pulling the wisdom from for this post.

 

While the argument as a whole is valid, and I agree with it in parts, bear in mind that these community mods are likely still ahead of where DCS voice chat will be in 5 years time, given its current rate of development.

It's quite clear you haven't used any of these tools yet, hence your formulation of the argument. I would suggest playing around with them for a bit, and then reevaluating your position.

SRS, rather than a "community stop-gap", has long since evolved into the most feature rich and intuitive way to communicate in DCS. To say it's light years ahead of the native voice chat is an understatement, it's in a complete league of its own currently.

 

 

[Northstar98]

On 12/26/2021 at 4:27 AM, Aarnoman said:

Voice chat first and foremost relies on sufficient community adoption. If not many people use it, it quickly loses its purpose, as less and less users will go through the trouble of setting it up to work for them. This is something we see currently - very few servers have voice chat enabled, as other more powerful and intuitive options such as SRS are available.

Absolutely agreed.

On 12/26/2021 at 4:27 AM, Aarnoman said:

On rooms and radio frequencies

 

In the current implementation of voice chat, there are two modes - room mode, acting like a discord room, and radio mode, where you transmit on in game selected radio frequencies (as picked in the plane). There are a few issues with this, specifically the following:

 

• By default, once loaded into a plane, the user remains in room mode. Most users are not even aware that you have to manually switch to radio mode to transmit on selected frequencies. From discord discussion including input from @Ciribob (SRS creator), a general consensus as follows was reached:
  • Both room and PTT mode have a purpose in context of DCS.
  • Room mode should be available for voice discussion restricted to users selected side while the user is in the lobby, spectating, or using the mission planner - effectively any time not loaded into a plane.
  • Once the user loads into a plane, voice chat should immediately and automatically be moved from room mode to PTT/radio mode, where in game selected frequencies are used.
  • Once loaded into a plane, room mode should be unavailable. This ties in with the earlier point on simplicity and intuitiveness, as most users expect to use the in-game selected frequencies to communicate. This creates the best of both worlds - a room mode available for planning/discussion akin to a briefing room prior to flight, and use of the planes native radios for voice communication once loaded in game. This mirrors real life (-> intuitive) as well as how the community uses SRS to communicate once loaded into a plane. It also provides the ability to brief/discuss/plan with your side before boarding a plane, allowing for coordination that is not possible using SRS currently, and has been requested by community members a number of times in the past.
  • The reason that room/PTT radio mode should NOT be an end user options is as follows:
    • Room/radio users are not able to communicate with each other, so by allowing this options selectable it will create barriers for entry, as the user may not be aware of which voice chat mode they should be in for a given server.
    • This leads to confusion, which may put users - particularly new users - off from using voice chat altogether, leading to decreased use. This again ties in with the ethos from earlier - it requires widespread adoption to be successful.

Absolutely agreed on all points.

I might be inclined to include an option to enforce room mode unavailability when in a slot, but I'm not too sure.

On 12/26/2021 at 4:27 AM, Aarnoman said:

Quality of life features

A number of quality of life additions are needed to the current implementation of voice chat to make its use easier and more immersive.

• Clear aural feedback that the user is transmitting. This means having "radio clicks" when engaging/disengaging the PTT buttons. Currently, voice chat does not have this.
• Radio effect to received voice chat - already planned, but will add to the authenticity. SRS is an excellent example of how this can be done. Ideally, some option (e.g. minimal/realistic) to the level of distortion should be selectable, to aid users with existing hearing impairment/foreign language users/etc.
• Default keybinds for all modules, with option to override these per module.
  • One option for doing this would be as follows:
    • Default Radio 1->9 PTT keybinds in voice chat keybinds under its own category. This by default applies to every module in DCS.
    • In the specials tab, for every module have a checkbox (default disabled) for "Use custom Voice Chat PTT buttons".
    • For every module, have a keybind section for "Custom voice chat PTT". This can then be bound on a per module basis.
    • Now, the user can easily create a default profile for most modules using the specific general voice chat keybinds, and also have per module keybinds for ones where a different profile is desired, that can be enabled for that module specifically using the options -> special -> [module] tab.

Agreed on all 3 points, though personally, I'd rather just have the PTT switches just in the modules, with the voice chat category for custom radios and anything for the voice chat GUI specifically.

On 12/26/2021 at 4:27 AM, Aarnoman said:

Other barriers to community implementation

With SRS now long established as the preferred community voice chat tool for DCS, a number of additional hurdles exist for DCS native voice chat to overcome to see it receive widespread server and community adoption. The previously discussed points are all important influences, but a number of additional hurdles also exist:

• Voice chat requires a degree of API access for mod developers. Specifically, established tools such as ATIS, Overlordbot and Hound ELINT are not able to be integrated with voice chat currently, leading to decreased server adoption in lieu of SRS, therefore hampering community uptake. Either native alternatives to these tools would have to be developed by ED, or voice chat API access would need to be allowed for mod developers to allow the integration of these tools with DCS voice chat.
• External voice chat access for GCI/AWACS. This means being able to connect to a servers voice chat without being in a plane, to allow for users (e.g. of LotATC) to act as a GCI/AWACS for fellow players. An alternative would be to have a dedicated slot(s) available in mission for users to join as GCI/AWACS, with access to the in game radio.

Absolutely agreed.

On 12/26/2021 at 4:27 AM, Aarnoman said:

This post is intended as a summation of the most integral features needed for widespread community adoption. Simplicity, intuitiveness, and community support are needed for DCS voice chat to be successful.

[...]

Ultimately, voice chat needs to be simple to set up, intuitive to use, yet remain powerful and capable like its predecessor SRS - it requires server and community adoption to be successful, as voice chat without uptake loses its purpose. I wish the DCS developers all the best, as there is huge potential in transforming the DCS experience using voice chat, particularly if largely adopted by the community.

Once again, absolutely agreed, though I don't have any experience with SRS.

On 12/26/2021 at 4:37 AM, evanf117 said:

i found it odd all the ptt keybinds, shouldn't it be plane level, ie the MiG-21 has a PTT on the stick and you can bind it so it brings up the radio, that should be the ptt for the MiG-21

Personally, yes, there should be individual binds for each module/aircraft.

My preferred method would be to have a short-press for the communications menu and a long-press (and hold) would inhibit the the communications menu, and to transmit on voice chat. Currently the JF-17 has this AFAIK.

I also think that there should be dedicated binds for voice chat and the communications menu, right now a few modules have this.

It's something I've asked for in this thread.

Edited December 28, 2021 by Northstar98

[Cathnan]

3 hours ago, Worrazen said:

 

I'll try to reinterate what I hastly and unclearly wrote in an earlier post that I will avoid linking to now. I'll reiterate the elephant in the living room here I think, at least to me. It is apparent that things like SRS and other things that may or may not rely on it are infact just temporary community stop-gap measures to ease the wait until the actual feature officially supported and integrated with all the other subsystems across DCS.

Absolutely good on all of you who supported and contributed to these great community projects, but, I would like to, in the spirit of realism that we're trying to simulate, offer a bit of a reality check.

So why would the lack of API access prevent it's usage and uptake ... if DCS Voice, eventually will be able to do everything these community mods and utilities can do and more. There shouldn't be any need for these temporary utilities anymore, optimally.

I hope people who are developing them are fully familiar with this most probable reality, that they are regularly re-evaluating how much effort spent into them is worth it depending on the hints and news of incoming mirror features DCS would officially support, and it would be quite rude for such community people to pony up some made up reasons to try to continue their pet projects, claiming some things to justify further relevance and it's development. It would be best to keep this finiteness in mind and to simply let it gracefully retire. I understand people can be emotionally attached to creations and legacy built around these community projects, but it would be most healthy for DCS, it's developer and the whole DCS community to not have things actually be in the way of DCS evolvement, sort of. This is why such community contributors should seek out and start new relevant supplemental projects earlier, so that they have somewhere to continue to put their energy any passion into much quicker, ahead of the retirement of the current stop-gap supplemental utility or mod, this should ease out and might even extinquish any bad feelings about the loss of relevancy of the current stop-gap.

There is justified reluctancy from DCS developers to provide API access. Instead of spending time to evolve DCS, they would spend time developing a subset of the API available to the general public and maintaining it's functionality across updates; ... is that really the best use of their time, does that help DCS as a whole in the long-term. Furthermore, it may not just be simple access like a flip of a switch, even if it is, I think they would only unnecessairly encourage such temporary stop-gaps to continue dragging on, while the community as a whole would actually be lesser off in the long-run because of the side-effect of the stop-gap development efforts never moving onto other and newer supplemental DCS community projects, particularly in areas that are lacking and may not even be officially planned for the near or even long term.

I think it would be a bad example of negotiation and unfair if someone takes this lack of API access here and argues that ED doesn't support modding in general. API access is something quite a bit more than just modding, modding it self isn't an established standard anyway, in regards to how much has to be moddable or how easy should it be. Yes the customers do have a voice and vote but it is still down to the specific game, product, platform, demographic, ecosystem, market, etc, and a more complicated relationship between the community and developers determines the right balance of modding access. The kind of API access you're asking here, modding level access, is the most open of them all, the DCS developer gets absolutely nothing too metered in exchange, benefit in new players (customers) attracted by the solutions using the capabilities of that access is only vaguely potential and hard to guarantee.

Ultimately it's about simulation and the replication of systems and mehanics of the real world. The DCS developer has taken upon themselfs to simulate reality in such a wholesome way, then it's their job to worry about it. They or anyone could indeed decide to go for a modular and open-source approach, but it's a completely different model, mindset, philosophy and a lot of other things that would require either a whole market or a vision change for the company. Technically a modular approach would also change the way he end product would function and behave, you could say it for the better, but I think it's always a set of trade-offs. During my recent deep dives into Linux (3 distros on 3 PC at once :D) I've seen many cases where modularity isn't always the best approach, I can't remember the exact example right now, stuff like lack of updates to some dependency that provides a feature that should be considered core/basic, etc and the idea of "others will take care of that side of the system". Fracturing these systems into various random github scripts is just not really sounding like what DCS vision was, tho this paritcular API access might not necessairly become such a scenario ofcourse, I'm speaking in general as well.

I am not on the side of one or the other, I chose to dwelve into why there wouldn't be access. If it works out for both sides and access is granted than that's totally fine.

There can be no limit, a modder could use these same original arguments of "VoolKhan is an established community 3D-graphics engine, please open up the access so we can integrate into DCS" or whatever. Or the sound engine does not have API Access so we can't integrate our binaural-audio plugin, or something.

If I'm technically wrong in any of this then I am absolutely open to correction. Disclaimer: Unfortunately trying to be the voice of reason a bit ahead of my self again. I never used SRS nor any of these mentioned community projects, ehm, yet. I am well into all things PC and tech in terms of HW and SW and I do a lot of work with PC, to the point that playing games is pretty low sometimes, so that's where I'm pulling the wisdom from for this post.

 

I get where you're comming from. And I agree with you that ultimately these community projects should not be necessary because they are part of the core game. But as things stand, they are not part of it. And considering the development time I have observed in my 1.5 years of actively playing and enjoying DCS, it will easily be another several years until DCS with core functionality comes even close to offerig the features the community projects offer today. Personally I mainly use SRS and Overlord Bot (the later if available on the server). And since you said you never used any of these projects, using SRS is as simple as installing any other windows program, choosing your settings and starting it when you start dcs. And if I didn't know better I could easily mistake it for professional software. From a user perspective it's the same for overlordbot.

The experiences these projects offer are so good, that I can see only a tiny fraction -if any- of the community switching to built in VoIP any time soon. I for one sure won't as long as something like Overlord Bot isn't available. That is something that can be fixed if ED develops a possibility to assign voice Chat slots to Bots and LotATC users. That way the community can use the Built in Voice Chat without loosing functionality currently provided by third party projects. In the meantime ED can built their own Overlord Bot and LotATC. You could consider that a stop gap solution on ED's side until it won't be necessary anymore.

I think the most likely outcome if ED doesn't provide this possibility is, that no one will switch to built in Voice Chat and it'll burn itself in the communities memory as a sub par experience you don't have to bother with.

Again this is not to say the community projects won't be replaced by built in features at some point. But realistically these features won't be available for several more years. And the community won't just sit and wait without the features if they're available outside of built in Voice Chat.

[Parabe11um]

Until the in-game comm system supports Overlord Bot or LotATC, I don't really see a reason to swapping over from SRS.

Supporting third party comm tools is pretty much the most important thing at the moment given how long it has taken for an in-game voice comm system to be provided (unless ED is really interested in dedicating a massive amount of time in replicating the wide range of features these external tools provide and that many players have come to rely on for their MP experience).

Edited December 29, 2021 by Parabe11um

[Blackeye]

Quote

So why would the lack of API access prevent it's usage and uptake ... if DCS Voice, eventually will be able to do everything these community mods and utilities can do and more.

Because a) that's a big if  and b) it stifles invention: Since the community solution is open to interaction people built new stuff around it and created overlord bot and connected LotATC. If that was locked behind corporate walls we'd have to hope ED listens to new ideas and implements them on short notice...

 

13 hours ago, Worrazen said:

hey would spend time developing a subset of the API available to the general public and maintaining it's functionality across updates; ... is that really the best use of their time, does that help DCS as a whole in the long-term.

From the customers perspective absolutely. For ED I guess it depends on what they want: scraping by with minimal effort or creating a great user experience allowing customers to create features ED didn't know they needed.

And while you obviously cannot create a public API for every aspect of DCS I think radio features are disconnected enough from the product as nicely demonstrated by the tools you haven't used and call "stop-gap" whereas I think they're pretty much the gold standard on how it should be done. It's the best voice chat I have seen in any product and ED hasn't caught up to it after 2-3 years of development.

I really hope they go with an open approach and not just work with the authors of existing tools "in secret" as this would lock out any future improvements by the community.

[IkarusC42B Pilot]

Restrictions are fine as they are,no need for more.

[StandingCow]

Pretty simple for me, ED needs to open this up to mod devs to integrate things like Overlord bot before I will be interested.  Once that is added I will happily use their in house voice.

[uri_ba]

I personally am waiting for the API access they had promised. Mostly the TTS engine.

 Allowing us as script/mod developers to at least provide VoiceChat as an option, allowing mission developers the choice.

For Hound I know that having VoiceChat integrated will lower the complexity involved allowing more people to integrate it into more missions. 

But unfortunately, was are all fimiliar with delays in low priority components in DCS.

 

[shagrat]

Am 26.12.2021 um 05:27 schrieb Aarnoman:

The reason that room/PTT radio mode should NOT be an end user options is as follows:

• Room/radio users are not able to communicate with each other, so by allowing this options selectable it will create barriers for entry, as the user may not be aware of which voice chat mode they should be in for a given server.
• This leads to confusion, which may put users - particularly new users - off from using voice chat altogether, leading to decreased use. This again ties in with the ethos from earlier - it requires widespread adoption to be successful

 

The thing is, when introducing people to the radios, or simply doing training sessions in general, the instructor needs to explain stuff and talk to the trainee. A simple thing like explaining how the radios in an aircraft work, without the trainee knowing how they work to be able to communicate is a pretty bad idea.

When instructing on bomb runs, how to setup the aircraft etc. I need to be able to talk to the guy AND hear questions... Additionally it is annoying to need to PTT for 60 minutes plus to explain stuff and answer questions. 

So we definitely need the room option to replace Discord/TeamSpeak etc. and especially for training.

I just yesterday made the Voice chat setup with a buddy of mine. We would never have succeeded with just radios in the cockpit and given up ultimately. We even required Discord to troubleshoot room mode until we found he had room mode default on "Push-to-Talk" and not "microphone on". Next issue was troubleshooting the radio setup in-cockpit, when setting up keybindings (ESC menu) while in the aircraft.

By the way, if you later managed the setup etc. and can confidently use the radios from cold and dark, there is already the option to default to radio mode immediately when you enter the cockpit. It's a simple checkbox in the individual menu of the voice chat window.