WIP DCS A-10C and Teamspeak 3 Integration

[Headspace]

Update to the OP. We now have a name for the plugin, and development is progressing nicely.

 

A quick note about radio filter effects--since they're mentioned in the feature list as a secondary item. Teamspeak 3's sound engine is slated to be reworked in the next release, so expect more info on this feature of TARS later on after we have a better understanding of what this reworking will entail.

[BoneDust]

This is an awesome improvement for A10! Make sure the radio volume controls are sync'd also and make the AI voices independant of voice volume. Also, put some mic clicks and a suttle hiss when transmitting as well as channel block noise when people are stepping on each other. :)

 

I sincerely hope you can complete this project. :)

[Headspace]

This is an awesome improvement for A10! Make sure the radio volume controls are sync'd also and make the AI voices independant of voice volume. Also, put some mic clicks and a suttle hiss when transmitting as well as channel block noise when people are stepping on each other. :)

 

I sincerely hope you can complete this project. :)

We'll get there. Hisses and clicks, channel block noises, and so on are going to depend on the Teamspeak sound engine issue that I referenced earlier. In the meantime, it would be helpful if I people could provide reference material on the different nuances of how the UHF and VHF FM radios sound in real life, and what the issues are with regard to things like duplexing and so on.

[BoneDust]

I understand wanting to keep things simple but I think you're overlooking an unavoidable logical problem by simply wishing for simplicity.

 

Billy is on frequency A and B

Jack is on frequency B and C

Rick is on frequency C and D

 

Because Billy and Jack share a frequency they must be in the same channel. Because Jack and Rick share a frequency they must be in the same channel. Therefore Rick and Billy have to be in the same channel, except they don't share a frequency.

 

The problem you've stated is irrelavant because most wings would have comm plans such as:

 

4 flights are flying

 

victor channels 1 - 4 are assigned to each flight for flight comms

uniform is a wing tac freq that all aircraft would be on for interflight comms.

 

Then there's guard for everyone. So, I don't see an issue with what's planned by the devs.

[Spetz]

Subsribed ! Can't want to see this working !

[GGTharos]

Very good idea Headspace. I will point the devs to this and request that there is a way to include TS URL/PORT/PASS in the .miz so that your plugin can launch and join TS automatically without requiring configuration ... you just join the game from within A-10C, and the plugin automatically launches and configures TS and you are in comms, as long as you are playing MP.

 

Sound like something you might want to do? If so I'll make the request.

 

 

TARS is a plugin which will allow you to integrate DCS: A-10 with Teamspeak 3.

 

The concept is simple: No channel switching in Teamspeak to ruin immersion. Rather, multiplayer communication ought to be accomplished by setting the radio in the plane to an agreed upon frequency and using that. You have radios in the game, so why not be able to extend that level of immersion to the multiplayer environment using Teamspeak? If other Teamspeak users are on that radio channel and they're in the same Teamspeak 3 channel as you, they will be able to communicate with you over any of the radios in your aircraft. If you die and/or go to spectator mode, you will automatically be placed into a parallel “virtual channel” where you can communicate with your fellow spectators without having to switch channels in Teamspeak.

 

We hope to release a beta for testing in early 2011. Since we are in a very early phase of development now, the TARS team's current goal is to gather input from the community at this stage, just in case there's a gem of a feature that heavy-MP users need that we can try to implement in the first phase of the project.

 

 

Planned features include:

• Automatic control of your radio communications based on what channel you're tuned to and whether or not your radios are on. If you are on a given channel that other players are on, you'll be able to communicate with them without having to worry if you're in the correct Teamspeak channel.
  
• Dead/Spectator enforcement. If you get killed in-game, you will be sent into a spectator mode where you'll be able to communicate with other players who are dead and/or spectating.
  
• Radio effective range enforcement. VFM FM radio, for instance, has a limited broadcast range when compared to its AM counterpart. This ought to reflect in gameplay.
  
• TARS is planned around a client based architecture, with no need to install extra software or otherwise modify the Teamspeak 3 server where you play.
  
• Planned future integration with Black Shark once A-10 integration is complete.
  
• If possible (and as a secondary objective), we'll be adding radio filter effects based on things like distance and radio type, for a more immersive gaming experience.
  

There are plenty of additional goodies that may become possible in the future. However the above are the main gameplay-enhancing goals. The purpose of this announcement is to engage the participation of the community early in the development cycle so that we can be as responsive as possible to your needs. When it comes time for beta testing, we plan to fully engage the participation of the community.

 

Last updated December 5, 2010

[Headspace]

Very good idea Headspace. I will point the devs to this and request that there is a way to include TS URL/PORT/PASS in the .miz so that your plugin can launch and join TS automatically without requiring configuration ... you just join the game from within A-10C, and the plugin automatically launches and configures TS and you are in comms, as long as you are playing MP.

 

Sound like something you might want to do? If so I'll make the request.

That's an interesting idea--right now the development version of TARS is communicating to Teamspeak via Export.lua + Luasocket. This allows a user to put teamspeak on a laptop if they want to (and there are plenty who do this). I think just having Teamspeak 3 up and running before DCS gets started is enough. Once DCS is in mission, it will search for (and connect) to the Teamspeak plugin. I have a working prototype of this already.

 

However, it would be helpful to know what the best configuration is that the developers recommend to make it as integrity-check friendly as possible. I've never run a dedicated server for DCS, and I'd rather not have to force people who want to use this plugin to make changes to their dedicated server just so that clients can connect. However, the plugin has to be able to export aircraft locations and device settings otherwise it won't work. Is this something that can be worked around in the mission file settings themselves, or does modifying anything in Export.lua basically require altering dedicated server settings?

 

Thanks.

[GGTharos]

The problem with this is a fear of cheating. If you export locations of all aircraft and you have two sides playing ... you get the idea. So yeah, I expect that would end up being locked down, unless you can have aircraft on the same channel (at minimum) communicate their coordinates to each other, so you only have to use local exports ... but then we get into a LEAVU-style datalink which people cry, moan, whine about and fear it more than death ;)

[Steel Jaw]

The problem with this is a fear of cheating.

 

I *cannot* for the life me fathom ANY hardcore or serious simmer, flying DCS A10C, who would even consider cheating.

 

I am AGHAST at the very suggestion.

[GGTharos]

I see you are not a believer in human nature ;)

[Steel Jaw]

I see you are not a believer in human nature ;)

 

LMAO: I have a front row seat.

 

My wife is a cop.

 

:D

[Grimes]

The problem with this is a fear of cheating. If you export locations of all aircraft and you have two sides playing ... you get the idea. So yeah, I expect that would end up being locked down, unless you can have aircraft on the same channel (at minimum) communicate their coordinates to each other, so you only have to use local exports ... but then we get into a LEAVU-style datalink which people cry, moan, whine about and fear it more than death ;)

 

Lockon doesnt equal DCS. Besides if the AI, mission editor, and online experience all improve by the time we a fighter aircraft the seemingly current necessity to play against human players might be overshadowed by the changes. In other words LockOn online is driven by PvP, whereas DCS online is driven by co-op. I'd hope by the time we get a DCS fighter the capabilities to product more complex teamwork driven scenarios will be built in and well accepted into the online community, so if we do have a PvP in DCS it will look completely different than that of FC2.

[Headspace]

TARS' architecture actually allows for Teamspeak to request only specific aircraft coordinates (Teamspeak sees a client that's running DCS and sends a friendly "hey dude, start streaming me some sweet, sweet coordinate data for that aircraft"). However, DCS needs to be able to export that. Teamspeak's API is able to cache and release (no pun intended) data about players. There's tradeoffs to using this, though--it's incapable of updating it in a quick, streaming fashion. (edit: When I say Teamspeak, I mean the Teamspeak TARS plugin that I wrote--not a default function of Teamspeak).

 

Now, you might not think that's a very big deal, but radios do have maximum ranges. Not that I'm clawing at the wall to implement high-end sound effects for FM frequency conflicts based on decibel levels and that sort of stuff just yet, but I would like some basic enforcement of not being able to use the UHF radio to speak to someone on the other end of the map.

 

So, at this point, TARS is going to require that export be turned on. This may be a problem for public servers, but those types of servers are probably not going to benefit as much from this plugin. I am not hot on the idea of writing a seperate TARS server application (it could be done, no doubt, but it would require someone to run it if anyone wanted to use TARS). Architecturally this is a client based solution.

Edited December 10, 2010 by Headspace

[flightace37]

Instead of exporting the exact location of every aircraft, why not use the engine's built-in capabilities and do this:

 

For every player currently flying, export the list of players within radio range of that player, broken down by radio type. That way no one needs to know where the aircraft are explicitly. In the same listing, you could also export a flag indicating blue or red force for TS separation of teams.

 

"Within radio range" would mean the engine's definition of actually being able to receive a transmission, ala terrain masking, etc. You could do it for both the AM and FM radios if you like. You could also export a variable that indicates quality of the transmission, ie floating point 0-1, where 1 is crystal clear, 0 is pure white noise.

 

A separate "dead list" could be exported without all the extra information, save for maybe team flags.

 

This solution gets rid of most of the worries about someone using the position exports for cheating, and brings it under direct control of the game engine as much as possible while giving radio plugins the information they need.

 

- WH_Mouse

Edited December 10, 2010 by flightace37
sig

[Headspace]

Instead of exporting the exact location of every aircraft, why not use the engine's built-in capabilities and do this:

 

For every player currently flying, export the list of players within radio range of that player, broken down by radio type. That way no one needs to know where the aircraft are explicitly. In the same listing, you could also export a flag indicating blue or red force for TS separation of teams.

 

"Within radio range" would mean the engine's definition of actually being able to receive a transmission, ala terrain masking, etc. You could do it for both the AM and FM radios if you like. You could also export a variable that indicates quality of the transmission, ie floating point 0-1, where 1 is crystal clear, 0 is pure white noise.

 

A separate "dead list" could be exported without all the extra information, save for maybe team flags.

 

This solution gets rid of most of the worries about someone using the position exports for cheating, and brings it under direct control of the game engine as much as possible while giving radio plugins the information they need.

 

- WH_Mouse

flightace:

 

Maybe you could clarify, are you saying that all of the functionality you listed is something I can access from DCS while it's running and without turning export on? Forgive my ignorance, but the export functions in DCS didn't seem to include any of that (radios being in range, etc). I *am* calculating that information, but after it reaches the Teamspeak plugin. DCS requires you to turn exporting on in order to get information about any object in the game other than your own airplane.

 

By turning export on, I mean setting

EnableExportScript = true

in the Config\Export\Config.lua script. It was my impression that DCS does not offer a way to get around this. There also doesn't appear to be a function or metafunction to dump the MP playerlist, although perhaps my Lua metatable dump search (heh) came up short.

 

There might be some confusion here as to what's being discussed. Are you saying you have a way of doing this in DCS? If so, how? Many thanks if you can point me in a direction I haven't yet discovered. :beer:

Edited December 10, 2010 by Headspace

[flightace37]

Headspace,

 

This is not something available now, but food for thought for the devs to further support your project, while retaining their designs to prevent cheating (statement a few posts ago about exporting all player aircraft coordinates). Something to collaborate on with the devs if it's possible to have changes made to what the engine can export. :)

 

Sorry for the confusion.

 

- WH_Mouse

Edited December 10, 2010 by flightace37
sig

[Headspace]

Ah, I get where you were coming from. The confusion was on my end--I was hoping you had some sort of knowledge regarding the exported Lua functions that I hadn't come across yet. No big deal.

 

As far as the cheating thing is concerned, the point GGTharos was trying to make (as I heard it, anyway) is that turning on the Export functions allows someone--if they were so inclined--to write their own cheating script. TARS is not somehow magically going to enable people to cheat beyond the capability already provided by Export.lua.

[159th_Viper]

.....TARS is not somehow magically going to enable people to cheat beyond the capability already provided by Export.lua.

 

We are all well aware of that.

 

It's when Export.lua is enabled that the shite hits the fan. One can argue that it is not relevant now with the A10C and that is fair enough. It will however be more than relevant if and when integration with the Kamov takes place and missions are ran with flyable clients on opposite coalitions in MP servers and even more so with the release of multiple flyables on opposing coalitions.

 

In such a scenario one cannot even begin to contemplate the trainwreck that would occur with exports enabled. One only has to look back in LockOn's history to appreciate it.

 

Do not get me wrong: Not in any way attempting to cast a shadow on your work here. It's just that i see major issues ahead in future, dictated largely by our dear friend and villian, Mr Export.lua.

 

Time will Tell :)

[Headspace]

In such a scenario one cannot even begin to contemplate the trainwreck that would occur with exports enabled. One only has to look back in LockOn's history to appreciate it.

 

Time will Tell :)

If there's an alternative to enabling it (i.e. if there ever is an alternative) I'll use that. But, unfortunately, I don't see a viable alternative at this point. If anyone does have an alternative, though, this would be the thread to suggest it.

[159th_Viper]

But, unfortunately, I don't see a viable alternative at this point. If anyone does have an alternative, though, this would be the thread to suggest it.

 

I would not sweat it too much at this stage.

 

It will be an invaluable application for closed servers (Squad Flights/Inter-Squad events etc etc) and might even be useful as a 'fishing' tool to hook potential 'exploiters' (when we now have the necessary 'hammer' to deal with them adequately) on open servers when that time eventually arrives :)

[Headspace]

Oh, I'm not particularly worried. But it's worth discussing in the community. In many ways this is analogous to the use of some of the similar mods in the ArmA community (closed servers tend to be more mod-heavy). ArmA has signing which is analogous (very, very loosely) to the integrity check of files that the DCS games can be set up to do.

[159th_Viper]

...But it's worth discussing in the community...

 

Quite so.

 

I'll be the first to admit that I have not the slightest programming ability/understanding at all when it comes to scripts and the like for the purposes of cheating or otherwise. However, with global exports enabled I can have a second monitor running in-game with a real-time Gods-Eye view of the entire operation/mission and all participants thereto without breaking a sweat.......It's just that easy.

 

I'm sure we can agree that that will never find acceptance in an open, public server :)

[CyBerkut]

That would definitely not be a good thing...

 

Since we are getting into discussing issues that came up during LEAVU's development, I'll just throw a pointer in here to something I suggested (a more granular approach to export functions) a little over a year ago. Maybe it will appear more worthwhile in light of this new Teamspeak integration project...

 

http://forums.eagle.ru/showthread.php?p=794037

[diveplane]

 

TARS is a plugin which will allow you to integrate DCS: A-10 with Teamspeak 3.

 

The concept is simple: No channel switching in Teamspeak to ruin immersion. Rather, multiplayer communication ought to be accomplished by setting the radio in the plane to an agreed upon frequency and using that. You have radios in the game, so why not be able to extend that level of immersion to the multiplayer environment using Teamspeak? If other Teamspeak users are on that radio channel and they're in the same Teamspeak 3 channel as you, they will be able to communicate with you over any of the radios in your aircraft. If you die and/or go to spectator mode, you will automatically be placed into a parallel “virtual channel” where you can communicate with your fellow spectators without having to switch channels in Teamspeak.

 

We hope to release a beta for testing in early 2011. Since we are in a very early phase of development now, the TARS team's current goal is to gather input from the community at this stage, just in case there's a gem of a feature that heavy-MP users need that we can try to implement in the first phase of the project.

 

 

Planned features include:

• Automatic control of your radio communications based on what channel you're tuned to and whether or not your radios are on. If you are on a given channel that other players are on, you'll be able to communicate with them without having to worry if you're in the correct Teamspeak channel.
  
• Dead/Spectator enforcement. If you get killed in-game, you will be sent into a spectator mode where you'll be able to communicate with other players who are dead and/or spectating.
  
• Radio effective range enforcement. VFM FM radio, for instance, has a limited broadcast range when compared to its AM counterpart. This ought to reflect in gameplay.
  
• TARS is planned around a client based architecture, with no need to install extra software or otherwise modify the Teamspeak 3 server where you play.
  
• Planned future integration with Black Shark once A-10 integration is complete.
  
• If possible (and as a secondary objective), we'll be adding radio filter effects based on things like distance and radio type, for a more immersive gaming experience.
   
  

There are plenty of additional goodies that may become possible in the future. However the above are the main gameplay-enhancing goals. The purpose of this announcement is to engage the participation of the community early in the development cycle so that we can be as responsive as possible to your needs. When it comes time for beta testing, we plan to fully engage the participation of the community.

 

Last updated December 5, 2010

 

hopefully the dev team will implement and test this prior to launch and include a package like this in final product will be a massive selling point on its own right.

Edited December 13, 2010 by diveplane

[Headspace]

Things are looking very good on the development front. So far the piece of TARS that keeps track of radio horizon (due to the curvature of the Earth) and signal attenuation is up to where it needs to be in the alpha and seems to be testing pretty well. That's as advanced as we're going to get in terms of simulating that for now.

 

CyBerkut:

 

I checked out your LEAVU thread. Looks awesome. Definitely should talk at some point about the best way to do the import/export thing via sockets and what your results were (performance wise) using TCP.