Headspace

I have just released TARS Beta 9. A whole bunch of improvements have been made, and are listed on my site as well as in the changelog included with the file. WarriorX's issue is also fixed, and you now get multiple push to talk buttons in the A-10C. Have fun.

Before anyone rides me out of here on a rail, you might actually look into Blender's video sequence editor, if: - You have a passing familiarity with 3d modeling - You aren't afraid of lower level MPEG related stuff and understand how it works - You are prepared to deal with a very steep learning curve.

Mower: I had this huge post that either 1) I screwed up and misposted elsewhere or 2) The forum ate. Here's the tl;dr version: Right now, the FM model is still being tuned and will be better tuned once I can get better data on usable FM signal propagation in the frequency band employed. Generally, FM sounds better and can theoretically be heard further than AM, but there's a cutoff point known as the improvement threshhold where the SN ratio drops dramatically and AM tends to gain the advantage there. This is why with FM radio the quality tends to be good throughout most of the usable range and then drops. As of the current TARS, the lowest band on AM has the best usable range. Line of sight is the primary limiter (earth curvature). Edit: I should mention that you can't actually tune down to a seriously low AM freq...so I guess that would mean the FM radio technically has the longest range at this point. Expect this to be tuned (no pun intended) when I redo the sound system in preparation for the new Teamspeak.

I believe I've found and nailed this particular issue over the weekend. Please test the new beta when it comes out and let me know if it comes back.

Part of the next beta changelog, should be out this week at some point: 1.0.0b5 - Plugin: Radio keys function as push-to-talk buttons for A-10C. - Plugin: Fixed an issue that would cause Teamspeak 3 to lock up when it tried to mute players. - Plugin: Radio frequency display set to rounded Mhz values. - Control Panel: Key bindings will be properly cleared out if the user selects less than the default number of keys.

Thanks, every time someone uses the correct reporting procedures, TARS gets better. Got the report and it will be fixed in the next beta release. In the meantime, go to the tars.ini file in your Teamspeak 3 folder and clear the second key setting out for each key--that should fix the issue.

TARS uses Export and therefore there is no way to join servers which ban modifications to Export.lua when TARS is enabled. The fix to beta 2's control panel was correct reversion to the original Export.lua. There's nothing involved in the cockpit to do any of that; it's enabled if it's enabled in Teamspeak 3 and all of that information is written down in step-by-step instructions in the manual.

Moa, I think we are in agreement on how this sort of thing works. Sounds awesome, looking forward to trying something like that, Moa. The IL-2 campaign generator (I forget who wrote that, but it's pretty sweet) was fun, such a thing is missing for DCS.

Not to butt in here, but I think you're right (sorry misunderstood what you wrote the first time and edited). I'm not a lawyer (or your lawyer), obviously, but as far as US Copyright law is concerned a derivative work is something that is derived from the original work in the sense that it includes major elements of said work. Writing a program from scratch that utilizes original source code that happens to interface with an API offered to third parties is not a derivative work. If Eagle Dynamics provided you with a scripting language that was their IP, and you made something with it just for lock-on, it might be a different situation. For instance, if you reverse-engineered someone's software or took their source code, and then made your own version of the program, that would be a derivative work and would quite possibly violate your original EULA depending on what EULA it was. Now, with the above in mind, look at a program such as TacView, which utilizes an open scripting language (Lua), which interfaces with several different games, and just happens to also interface with ED's product. Would they suddenly now "own" TacView? Under the logic that any third party content is a derivative work, anyone who writes software which interfaces with any of Microsoft's proprietary APIs (DirectX, Win32, .NET, etc) would be Microsoft's IP. That's quite clearly false; while the APIs are Microsoft's property, the 3rd party content's copyright rests with its respective creators. I have read the license agreement that comes with the product. There is a difference between creating content on your own and creating content using the proprietary utilities provided by the game's creators. If I make a skin, for instance, in photoshop and happen to use that skin in the game, does my photoshop image--which I created--suddenly become some third party's property? I think not. However, if you use ED/TFC's mission editor to make a mission, that's a different story--and of course the EULA contains provisions for use of the mission editor and distribution of content created with such. There's certainly a lot of confusion going on here regarding EULAs. You should check out the ArmA community if you think that this is the only community where petty flamewars break out over who created what, despite the fact that all mission content is strictly NFR. It gets seriously ridiculous at times. The type of thing has been going on since well before people were making custom .wads for Doom.

You know, Mower, I might take you up on that at some point. While I am still in the process of getting a regular session of DCS going that I run, I wouldn't be adverse to occasionally playing with another group, and the "democratic, no ban on being a part of another group" thing appeals to me. Banning gaming participation elsewhere whether express or implied is an enormous red flag (for me) when closed groups do that. After 15 years of gaming online (starting out with flight sims) it's become one of my dealbreakers.

A good chunk of this is TARS prerelease stuff, but there was so much action involved that I stitched together some of the more memorable moments of the past few weeks. Enjoy.

You can, but it's not necessary; it will install over the old one.

Beta 2 is out, go get it. This should resolve the control panel uninstalling issue--I'd recommend installing over a clean Export.lua and config.lua to be sure. However, removing the final carriage return (the last Export.lua character is a space in the original file) will fix the problem, if restoring from a fresh copy is not an option for you. I fixed a few minor bugs in the Teamspeak 3 plugin side of TARS. As stated in the post, current development efforts are geared towards fixing major bugs (which will be the focus of any near-term betas) and then bringing TARS in tandem with the upcoming release of Teamspeak 3. Enjoy.

That's a good idea, problem is, people may have other export related mods installed (tacview being the prime example). TARS does make a backup while it edits your files (so if there's a crash you can restore from them) but it doesn't persist these, because I don't want to end up inadvertently giving the false impression that "pristine" files were backed up. For instance: 1. You install TacView 2. You install TARS -> Backup Export.Lua 3. You uninstall TacView 4. You uninstall TARS Export.lua would not be pristine in that case. Beta 2 encodes the files correctly and will restore your file to pristine condition if you have no other mods installed. It also restores your export settings to what they were before you installed TARS (ExportEnabled in the config file).

zdXu: Sorry to hear, obviously I don't want you to be unable to play. I am working on a fix but in the meantime please uninstall and then replace the config.lua and Export.lua with the files attached to my post here (after unzipping). They're the original BS 1.02 ones. I'll be pushing the latest beta out tonight for people to test, which resolves the issue you're having--it will clean everything out properly on uninstall. config_export.zip

I've been running it with the various people who have been testing it with me before the beta 1 release. No integrity check failures on vanilla BS 1.02, A-10 Beta 3, or A-10 Beta 4. Is your network.cfg set up to run integrity checks on additional folders, and if so, what folders? The Advanced section of the manual explains, in detail, everything that TARS does with your folders and files so that you know what's going on. I have attempted to "touch" as little of the DCS file structure as possible. Feel free to ping me on Skype (it's in my profile) if you need me to help you with this. EDIT: Nevermind, I know what the issue is. I'll have a patch for the control panel out ASAP that will resolve this problem for users.

DH is good for a lot of things but I use an internal means of bug reporting and tracking (for now). There are various reasons for that that are outside the scope of the thread. If you find a bug, use the reporting form on the site. I promise that someone does look at all of them and if possible, you will get a response.

You don't need to keep the CP running-I should mention that in the FAQ, I think.

That's no big deal. Originally, I named them that way before the decision was made to incorporate the SPU-9 switch in Black Shark into the radio selection--Black Shark handles it differently and you don't need those keys as a result. But, initially they had generic names because TARS works with more than one game. I'll likely rename them for the next beta. Keep the suggestions coming, guys!

Good point, mikey. The current plan is to define a special frequency that people who are spectating will always be audible on, and that will be explored in a future release as well.

Feel free to put them in touch with me if necessary. Also try sticking the TARS line in your Export.lua to be at the end. TARS should properly run other exports (it works fine with Tacview, for instance) if they're defined before it is.

This is a flight sim community. It's a given. ;)

As I said: I can make it do multiple PTT. That's not an issue. The issue is what to do about cases where people use voice activation. How about this. For later release (since this is going to take time to develop, and I'm interested in catching serious bugs in the short term): - If the user has PTT selected, then the binds become PTT binds, and will transmit on the given radio. - If the user has voice activation selected, then the binds function as they do now. Does that work for everyone? I can stick that on the to-do list.

It does for black shark, because the sim can tell TARS which radio is selected with the SPU-9. But in A-10, with the multiple PTT controls of the HOTAS, all three radios can be active at once.

What if a person decides that they want to configure Teamspeak 3 to do voice activation instead of PTT? I know not many use it, but for those who do, mandatory PTT for TARS would pre-empt a normal function of Teamspeak. If it absolutely ends up having to be in there, I'll add it, but I want to give the community enough time to establish consensus on how it should work. Edit: I'd also like to point out that with that method, a fourth PTT isn't necessary. You would simply use whatever the user has bound for PTT under normal Teamspeak as the PTT button for teamspeak.