[ioquake3] VoIP support for ioquake3...

[Ryan C. Gordon]

> I think the way we should have it is first off have vtransmit_to_target, 
> then vtransmit_to_team, then vtransmit_to_everyone. We can make them 
> each be g cvars and it will be up to the administrator what he wants, 
> default being vtransmit_to_team and vtransmit_to_target on by default. 
> We would then make it so that vtransmit_to_team, vtransmit_to_everyone, 
> and vtransmit_to_target are bound to different keys of course else 
> vtransmit_to_everyone would 'override' vtransmit_to_team. 

Maybe one cvar would be better, so we don't end up with conflicts. In 
fact, I'd just reuse cl_voipSend (which is currently 0 to not 
record/transmit, non-zero to record/transmit):

0 == no one (don't even capture from the sound card)
1 == send to everyone
2 == send to your team
3 == send to other team
4 == send everyone within X radius
5 == send to current target

Then have a menu or a keybind that toggles this cvar to the appropriate 
value.

Maybe some extra values for buddy lists, if people get really into this.

> We could add 
> different 'end transmission sounds' to each transmission type.which are 
> easily changeable by the game developer (It can be a simple wav or 
> whatever format you guys want) which is appended/mixed to the end of the 
> respective streams. Again, something short but distinguishable, and also 
> not annoying/obtrusive (We can lower the volume of the end-transmission 
> sound by just a /tiny/ bit).

The current code has no concept of end-of-transmission (it knows what 
"generation" a packet belongs to...each time you start a new recording, 
it's a new generation, and what sequence in that generation the packet 
is part of....this all lets us know when we need to reset the Speex 
decoder, or try to guess the payload of misordered/dropped 
packets)...the problem would be that "this is the end of the recording" 
would need to be a reliable command, and that brings up all sorts of 
tapdancing in a system that's designed to blast out VoIP data without 
much concern for what specifically shows up at the client's machine.

We currently reset the decoder if we get a VoIP packet that suggests 
we're more than 2 seconds behind in the current generation, due to 
packet loss...we could (and probably should) lower this timeout...and 
maybe move this check to somewhere else so it doesn't rely on a new 
packet arriving to decide if the stream has dropped out. But honestly, 
it's a lot of work to add that walkie-talkie beep that pisses me off 
when the guy in front of me at Starbucks starts yapping with it.

But that's just me.

> Of course, on top of this we would have UI confirmation, also something 
> not obtrusive. I think the best UI confirmation I've seen for any game 
> so far has been the one for Counter Strike Source. I'm currently looking 
> for some screenshots of it. Anyways, it simply places horizontal bars on 
> the bottom right of the screen which display (in order) a voice chat 
> icon followed by the name of the player. These only appear when someone 
> is speaking of course, and stack on top of each other as more players 
> begin to talk. The bars are the colors of the teams (Red or Blue). For 
> vtransmit_to_target we could make the background yellow (or purple, 
> since I think that's the text color for text_to_target).

That sounds VERY cool to me.

I also think we still need a bit of UI to let the player know if he's 
recording and how well the game can "hear" him (check clc.voipPower and 
update once per frame). Just a square that gets brighter will do, or 
maybe rejigger the lagometer code, or hell, make a full out sound wave 
display...that'd be overkill, but extremely pimp.

Don't forget a UI to ignore abusers (someone is going to hook up an iPod 
to their line-in port and RickRoll everyone...you know that will be the 
first thing that happens!).

It's worth noting that I have _zero_ personal interest in working on UI 
for this, so I'm relying on someone to step up for that part. Any 
volunteers?

--ryan.