Teamspeak
Teamspeak
From what I've read to date, TS3 still doesn't support channel commander or key-binds stored in a distributable file (two lovely features from TS2). However, TS3 sound quality is very good. Another factor to consider is A2TS3, which ties ArmA2 and TS3 together, and then adds all sorts of functionality around frequencies, range, LOS etc. Still another factor to consider is TSOverlay, which I know works with TS2 but I'm not sure it does with TS3 - but perhaps there is a replacement application for TS3?
What are people's thoughts? I'll post my own thoughts later.
What are people's thoughts? I'll post my own thoughts later.
- Tigershark
- Posts: 414
- Joined: Wed Jun 09, 2010 5:56 am
Re: Teamspeak
Absolutely, 100%, TS2. TS3 fucks with my soundcard, and until that's fixed I can't use TS3 for anything serious.
Re: Teamspeak
My inclination is to go with TS2 + custom folk keybinds + TSOverlay. TS3's lack of channel commander is a deal-breaker for me, and the complexity of A2TS3 doesn't immediately align with the folk ethos (but let's keep an open mind about it). In terms of channel set-up, how about:
Because of the flexibility the folk platoon structure provides - i.e. the formation of single or multi-fireteam squads under the CO and DC, or even acting independently under an FTL - should we work on the basis that the CO assigns FTs to channels as required? For example:
During slotting for a co-operative mission we are all in Primary. In terms of groups, we have the CO, DC, FTs Alpha, Bravo, Charlie and one MMG team. Before asking the server host to begin loading the mission, the CO will ask the DC, FTLs and MMG team leader to join him in Channel 1, and everyone else to remain in Primary. The CO decides to tackle the mission by splitting his force into 3 parts: CO+Alpha+Bravo, DC+Charlie and MMG1. The leaders all return to Primary and the CO informs everyone of the channels split: CO+Alpha+Bravo to Channel 1, DC+Charlie to Channel 2, and MMG1 to Channel 3. The leaders will all remain on channel commander.
Is that too complicated? The alternative is for us to have set relationships between FTs and channels. Thoughts?
Code: Select all
|- Primary / Dead Channel
| |- Channel 1
| |- Channel 2
| |- Channel 3
| |- Channel 4
| |- Channel 5
| |- Channel 6
|- Secondary / Dead Channel
|- Channel 1
|- Channel 2
|- Channel 3
|- Channel 4
|- Channel 5
|- Channel 6
During slotting for a co-operative mission we are all in Primary. In terms of groups, we have the CO, DC, FTs Alpha, Bravo, Charlie and one MMG team. Before asking the server host to begin loading the mission, the CO will ask the DC, FTLs and MMG team leader to join him in Channel 1, and everyone else to remain in Primary. The CO decides to tackle the mission by splitting his force into 3 parts: CO+Alpha+Bravo, DC+Charlie and MMG1. The leaders all return to Primary and the CO informs everyone of the channels split: CO+Alpha+Bravo to Channel 1, DC+Charlie to Channel 2, and MMG1 to Channel 3. The leaders will all remain on channel commander.
Is that too complicated? The alternative is for us to have set relationships between FTs and channels. Thoughts?
Re: Teamspeak
It purely depends on our attachment to VON. I'm personally quite comfortable with the concept of VON for Fireteams, but on the other hand we've got the option to use TS for fireteams so why not try it out?
I am adverse, however, to the idea of having set fireteam channels. Flexibility is absolutely paramount in this platoon design, and it would simply add an extra layer of logistics and confusion if it had to be over-ruled.
However - we do not absolutely need to get this sorted instantly. If it becomes clear that we're always using one channel per FT, and they're always twinned, then we could say that it's standard.
I am adverse, however, to the idea of having set fireteam channels. Flexibility is absolutely paramount in this platoon design, and it would simply add an extra layer of logistics and confusion if it had to be over-ruled.
However - we do not absolutely need to get this sorted instantly. If it becomes clear that we're always using one channel per FT, and they're always twinned, then we could say that it's standard.
Re: Teamspeak
I'd favor the use of VON until we get a suitable version of A2TS3 going for AO, whenever that pans out. Given that it could become heavily adopted by the community (look at what's going on in the biforums regarding this), and given that TS2 is what, 6 years old at this point? It seems like a good idea to stick with VON or some interim solution and then adopt A2TS3 when it's matured.
Re: Teamspeak
Headspace, what's the best thread / location for keeping up to date with the development of A2TS3? Also, when you have a moment, would you be able to share your thoughts on why it would be good to use - and what aspects are currently preventing you from recommending it for adoption now?
Re: Teamspeak
The thread is here: http://forums.bistudio.com/showthread.php?t=95918
I would certainly favor trying out whatever version of it is available (if any) but since there isn't one specifically for AO, it seems like we would need to wait to use it in any kind of normal capacity.
I would certainly favor trying out whatever version of it is available (if any) but since there isn't one specifically for AO, it seems like we would need to wait to use it in any kind of normal capacity.
Re: Teamspeak
Headspace : Do you mean VON-only, or VON with TS2 for some other stuff, a bit like ShackTac. I'm absolutely behind getting TS3 working in the long run, but unless OA VON is going to be a LOT better than the previous incarnations then I think we ought to keep TS2 around until that date, just in case.
Re: Teamspeak
Now that I think of it Xia, you're probably right. VON these days kind of sucks.
I was thinking of when we played with TG, and then it dawned on me that we'd been using ArmA 1 VON instead of A2 VON--i.e. the old OpenAL version where after it had been fixed. So yeah.
I was thinking of when we played with TG, and then it dawned on me that we'd been using ArmA 1 VON instead of A2 VON--i.e. the old OpenAL version where after it had been fixed. So yeah.