Headspace

Yuya: Is there a feature in the OP that you didn't see included in the Youtube video I linked that you would like more preview info on? Remember, it's an alpha/work in progress. I'll also update the OP to include a link to the video I embedded.

Yep! In fact, the TARS I was running on my PC during the video was the x64 build; the one that was "transmitting" that was running on another machine was the x32 version.

Here's a demo of one of the early TARS alpha builds with Teamspeak 3, using the VHF radio. All audio (other than my voiceover right at the start) is coming through Teamspeak. Enjoy!

I am getting a demo presentation ready that will show early Alpha TARS in action. I went ahead and took Teamspeak 3 chatter from an IL-2 game, then "transmitted" it from a CP truck on the airbase next to the A-10 on one of the VHF frequencies. You can see the intercom panel in action, plus what happens when you move further away from the airbase.

I think it's too slow also, unless you want to get really close, which defeats the purpose. The kind of toss bombing the OP is describing is generally done in supersonic aircraft with the ability to leave quickly under afterburner after release.

Well, let's look at the flip side of that equation. Would you want people coming into your channel and talking to you while you're playing, especially if those people are not ingame with you? It dilutes the idea of using the radios in your A-10 as a method of channel enforcement if people can get around that in spectator mode. There will be minimal--if any--"taking over" of Teamspeak 3's own functions by TARS. While the API allows it, it isn't a design path I want to go down. Grimes made the point already, acutually--it interferes with Teamspeak's built in functions. The only exception to this is that TARS locally mutes people who it knows aren't ingame with you-but only if you're already ingame yourself. This allows people to spectate without bothering players, with the added bonus of blocking unnecessary packets from their stream (but that's a technical thing and not necessarily the basis for that decision on its own). Here's an idea, though. How about spectators' voices are automatically routed to the GUARD channel on one of the frequency bands? :D That way, if you want to hear what spectators are doing, you can switch to guard. The only problem with that, is it would allow people "break" spectator mode. However, it does solve the problem. What's the community think about this? The original plan was to have ejected players speak on GUARD only, but I'm having difficulty trying to envision a real use for this. It might be more fun (and more useful) if you just get dumped into spectator mode when you eject.

TARS only turns itself on when you have DCS running.

Sort of. ACRE hooks into ArmA in a completely different way (the two ways probably could not be any more different, indeed). It's really a function of Teamspeak's API that we're able to provide similar functionality for DCS. Sort of a set of "virtual channels" if you will. If you want to make it so people ingame are not crossing into the "territory" of people out of game--while keeping everyone in the same TS3 channel--that sort of setup is the natural result.

Well, disabling a plugin in Teamspeak consists of going to your plugin menu and unchecking, so if you had it installed you could turn it off by doing that. The way it works now is as follows: 1. People without TARS / not in game can hear everything. 2. People using TARS who are spectating or otherwise not in game can hear everything as well, and communicate with (1) 3. People in game, using TARS, can only talk to people who are also in the same game using TARS, within radio rules. They will not hear chatter from people in categories (1) and (2), although (1) and (2) will be able to hear them. Edit: However, that's not to say a hotkey based method of toggling TARS on and off wouldn't be feasible to do. Indeed, given the way Teamspeak is set up, it looks as if there will need to be hotkeys to switch to radios anyway. So, definitely be vocal with your suggestions.

Well, I'm not sure if this helps anyone, but I can confirm that the guard channel selections do indeed work, at least in terms of what data's being registered to the radios. When selecting the appropriate Guard mode for each radio (GRD for UHF, EMER AM and EMER FM for the other two, respectively): UHF: 243.00 VHF AM: 121.5 (naturally) VHF FM: 40.5 Unfortunately, you can't tell (from the cockpit) what exact frequency the VHF radios are switching to when you put them in guard mode, but as of Beta 3 that's what they're on.

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.

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.

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.

This probably doesn't answer your question with regard to what happens when the entire system is powered down, but for the record, Manual Reversion gives you direct elevator and rudder control (through the linkages). Aileron control reverts to the trim tabs on those.

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.

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:

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.

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.

Just a quick update to let you guys know that the delay in getting the SAM interdiction video out is due to the removal of Nevada. However, Beta 3 also removed the ghost RWR threats, which were an annoyance, so it's not all bad.

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.

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.

Actually, you guys, my processor is a Q9550. While it's on the high-end of the pre-i7 era, it's not what you would call "cutting edge." It's more than enough to run DCS though. But here's the story: There's a lot that goes into the video production, voiceover work, etc that you don't see in the final product. One such technique (and we've had discussions about this--I believe some of the other people such as Tyger who do vids use similar methods) is to record in 1/2 or 1/4 speed and then speed it up in post, then overlay the original audio. That's probably what you're seeing here. It's bad form to distract the viewer with framerate stutter, even if it happens on virtually every setup.

In that case, using the plugin, Jack would hear both Billy and Rick, but Rick would only hear Jack and not Billy, and Billy would only hear Jack and not Rick. All three would be in the same (Teamspeak) channel.

The design and prototyping phase of this is going a little bit faster than expected. Here are a few updates. Very early on I decided to go with a socket based architecture so that you can split your TS3 and DCS computers, if you want. This means that if you use TS3 on a laptop or other computer, you'll be fine--there's no requirement that it be on the same machine you use with DCS, and the two will talk with a minimum of configuration overhead on your part. I've made the decision to attempt to stay away from server-based stuff as much as possible, again so that the system is easy to set up for users, and more importantly, so that it doesn't add extra overhead to maintaining a DCS server. It's my hope that once we go into production with this, there won't be any need to do any server-side installation of anything--it'll be very much a 'set up your client and go' type of thing. In the same vein as the above point, a plugin-enabled TS3 client will be able to detect whether or not other clients are using the plugin. That way, non-enabled users won't be able to 'break' comms--they'll simbe moved to the spectator area along with dead players and spectators. Of course, the above is subject to change but that's the direction we're headed here. I want this to be as easy as possible for people to set up and use.

Or you could go one better and ask for a demo flight from just about any flight school...these are generally sold as a discount one-off type of thing and can be less than $50 (US) depending on who you go to. That way you can get hooked on an even more expensive hobby as well.