Mumble

[Z-Man]

Fork from here.

I vote to keep the support optional. Some people don't like additional "bloat" if they don't have a headset.

"optional" in the sense that if you don't have installed mumble, nothing happens, yes. But it looks like the support code in arma itself can be really small, so there'd be no reason to leave it out.

[-=VcL.Rajinn]

This is a really good idea!


/me is installing Mumble right now.

[Z-Man]

Hmm, the RPC bindings appear to only be able to control the server component, at least in the current release version. I haven't looked at the GIT repository yet. Not to worry, the basic client functionality we need (IMHO) is to have it connect to a specific server (and maybe a specific username and password), which is all possible via the command line. If there's an instance running already, that one is made to connect to the server.

About the ability to specifically position audio: I think there's a key the user can pres to disable positional audio. Sounds good enough for me.

So, what do we need for something we can call minimal support?
- giving out the coordinates
- adding a serverside config option containing the server URI
- adding a clientside config option letting the client join the mumble server automatically or not (then it should still be possible to join manually on demand)
All that is easy enough for an afternoon project The most difficult bit would be finding the mumble application automatically on Windows.

Definitely-Nice-To-Haves:
- put players into channels specific to their team. May be possible with the serverside RPC stuff.
- tie in with armathentication: let the server give the client a one-time-password, have the client pass that to the mumble login, and have the mumble server verify it.

A problem is the way the server requests username info via RPC. It expects a numeric user ID for every user, and stores that its database. We con't have unique numeric IDs.

[radian]

[/quote]
All that is easy enough for an afternoon project The most difficult bit would be finding the mumble application automatically on Windows.

Definitely-Nice-To-Haves:
- put players into channels specific to their team. May be possible with the serverside RPC stuff.
- tie in with armathentication: let the server give the client a one-time-password, have the client pass that to the mumble login, and have the mumble server verify it.

A problem is the way the server requests username info via RPC. It expects a numeric user ID for every user, and stores that its database. We con't have unique numeric IDs.[/quote]

ok im,e trying to keep up .heh
so aside from windows users manually having to start thier mumble
there could be a useable chat on the menu of arma in the future
is that what your proposing....if so..i wanna buy you guys a beer
i dont have the code knowhow you chaps posess
but if mumble is the way forward
the mentor programme will of course intergrate
whatever client suites armagetron best

is there a patch that could be written for the numeric IDs

[Z-Man]

is there a patch that could be written for the numeric IDs

There's always a way to write a patch, but then we'd have to distribute the build ourselves and it would add complications to the server admins (not the users). But it seems the mumble server can be configured to accept logins from anyone, and no critical stuff is handled over the voice chat, so it'd be reasonable to just not bother with authentication there.

Although, on second thought, restricting voice chat to armathenticated users may help to keep it civilized. We should just test how the server reacts to recycled player IDs.

[sinewav]

Wow, I really like how this is going. So many awesome features. Keep up the good work guys, you'll make me leave 0.2.8.1 eventually.

[Concord]

pfft...real men play with 0.2.5

the fortress zones are hovering red zones, and don't spin when conquered, but I can still play cafe with it.

[-=VcL.Rajinn]

pfft...real men play with 0.2.5

the fortress zones are hovering red zones, and don't spin when conquered, but I can still play cafe with it.

H4X0R!

Anyway, how will people know to download Mumble when downloading this client? You should include a "how-to" in there telling people about it and what it does. I want everyone in tron to use this, not just people here that look at this topic.

[Lucifer]

We might also investigate using some sort of CRC of a player's armathentication name and see how many unique ids can be generated that way.

I think in the long run, embedding a mumble client into arma would be best. No separate download needed, then. That's just me being selfish, though.

We could distribute a mumble binary with our own installer and ask during installation (for win/mac) if the user wants to also install mumble. We might even check the registry to see if mumble's already installed (assuming it puts something in the registry), and we can probably even check the registry to find mumble *if* it puts something there to say where it's at.

So, my questions:

* Does murmur have the ability to determine the player's 3d position from only one process? I.e. can we setup the arma server to update murmur so that our client doesn't have to worry about it?

* How does Mumble's OSD affect arma's fps?

* Should we have a config item on the server ala resource_repository to tell clients what the server's murmur server address is? (I guess it's obvious we should, since z-man also suggests it) Should we also provide a default murmur server and use it as the default, the same way that we do with the resource repository?

* Can mumble users join several rooms at once? If so, can rooms be configured differently? I.e. there could be a general server room, like "Fortress Cafe", then team-specific rooms like "Fortress Cafe/Gold Team". Could we then configure the general server room to use 3d position and the team-specific room to not use 3d position?

I'm about as far from looking at any of this as I can get, other than what I've already done. Not only am I still job-hunting, but now I've got to find a place to lay my head starting in April (which, if I don't get a job, will require relocating to my parents' house in New Mexico).

[Z-Man]

Yeah, mumble adds registry entries that make it possible to find it. All decent programs do, or their uninstaller would not work Mumble also installs a URI handler that stores the full executable path directly. All the better for us.

* Does murmur have the ability to determine the player's 3d position from only one process? I.e. can we setup the arma server to update murmur so that our client doesn't have to worry about it?

No. Positional audio is purely client side.

* How does Mumble's OSD affect arma's fps?

With just me being displayed, much less than 1ms of extra rendering time per frame. It doesn't seem to work on Linux, though, at least not for me (there's an X-Extension-Missing warning on startup, it's possible that's the reason)

* Should we also provide a default murmur server and use it as the default, the same way that we do with the resource repository?

Possibly. However, as far as I can tell, we can't tell mumble to connect to a specific channel, so everyone would just end up in the same room. That may get confusing. But yeah, we should seek a 'it just works out of the box with default settings' scenario. Maybe virtual servers help.

* Can mumble users join several rooms at once? If so, can rooms be configured differently? I.e. there could be a general server room, like "Fortress Cafe", then team-specific rooms like "Fortress Cafe/Gold Team". Could we then configure the general server room to use 3d position and the team-specific room to not use 3d position?

Probably no to all. If there's a way to join multiple channels, I haven't found it yet.

Another problem is: how do we prevent a player from the blue team to enter the private gold team channel? Theres ACLs giving users rights, but they're only checked on login, I think. Again, virtual servers may come to the rescue. But it definitely requires a control connection between the arma server and murmur, which requires authenticating the arma server somehow (I hope!), which makes running a default murmur server a bit of a tough option. We may need to plug a level of indirection between the arma server and the murmur server, either a http interface (like armathentication uses) or something else, where arma servers can request to open virtual servers and channels for them.

After a bit of looking at the docs, it seems the RPC interface to the server allows watching and forcing player status changes (such as hopping from channel to channel). So we're set there. Just prevent them from entering the enemy team's channel and put them into their own team channel by default. The server side is not something one can do before breakfast. We definitely should restrict this to armathenticated players, otherwise, renames will give us massive headaches.

Plus, a default server would consume a lot of bandwidth, probably in the TB/month regime once it's fully adopted (which will take a while, given that it'll require 0.3.x clients and servers). We can do a test installation on bugfarm, but I picked the minimal option of 1.5 TB/month. According to rough calculations, that's about enough to support around 5 full servers. Most servers won't be full, so we'd get away with it for a while. I'd limit the amount of available slots, of course. The server is on Debian 4.0, which may make things tricky, so don't expect anything up right tomorrow.

[compguygene]

ok, I said in an earlier thread..if you could point me to an open source suitable replacement for TeamSpeak, I would pounce on it.

And while writing this post, I decided to research Mumble and it's server component. After reading reviews, doing the math on the networking considerations, etc. I have determined that there appears to be no reason to not use this vs. TeamSpeak. I am going to install it on my VPS and run it in parallel with TeamSpeak during a short transition phase. Unless I see insurmountable problems, I will do my best to get the community as a whole to start using it.
The only problem that I see toward adoption by the community as a whole would be getting someone to offer "turnkey"servers. Like what TeamSpeak servers are. I am certain that Luke-Jr would be willing to offer that service.
TeamSpeak Servers are offered for $0.25 per slot for such service. That would leave plenty of room for profit for Luke-jr or anyone else. Personally, I have no interest in such a business. But would be happy to drive business to someone.
It would also seem to be easy for existing server admins who rent their own vps's like I do to install Murmur (the name of the Mumble server) servers.
Initially, I will get the Wild West Clan using the Mumble/Murmur software as a good live test. It uses the same codecs as TeamSpeak, so my hopes are high.

I really hate using closed source software! Ty joda!

[radian]

i been trying the different chat clients for a while now..
and am busy going through mumble atm..
seems very user friendly and easy to set up..
and good on the grid too...infact im,e getting better gameplay on the grid with it than the rest
il.e gonna push for mumble as --the arma chat client-and will do some trials with my team on the grid

[Z-Man]

Ah. On Linux, you have to start a game with 'mumble-overlay <game name>' to get the overlay. Overhead there seems to be even smaller than on Windows. Then again, on Windows I shut down mumble completely (not that there was any activity on it, and if it was, the second core would have handled it). And on both systems, it's about the difference between 1000+ and 1000- FPS, so for lower end systems, it may matter. But that's life and why it will be optional. Anyway, we'd need a new 'start with overlay' menu entry on Linux, then.

I've looked a bit deeper into channels and stuff. You can link channels: everything said in one channel will then be propagated to the other. However, it will only be heard there if the speaker has talk rights. There's two talk modes, too. Regular talk and alt-push-to-talk, where you have to definitely press a button while speaking. Both have separate rights settings .We could use the alt talk for more public messages. For example, this channel setup would be good for tournaments:

Code: Select all

Spectators
   Admin
Team A
   Team A Leader
Team B
   Team B Leader

Where you link: the two team leader channels, each team leader channel with its team channel, and the admin channel with all channels. For regular chat, everyone only gets rights in his own channel and superchannels (so a team leader can talk to its team). The admin gets alt-talk permissions on all channels so he can make announcements. The team leaders get alt-talk permissions to the other team leader channel and the admin (possibly the spectators, too). Then, regular chat stays between the spectators and teammates, while organizational stuff can be handled in alt-talk.

I think we should stick to the 'alt-talk broadens your audience' in the setups. So default talk on a regular team server would be team/spectator talk, alt-talk goes to everyone.

Also, instead of letting murmur poll arma for accounts, we can just push player accounts to murmur on demand. That way we can delete users once we're done with them and recycle their IDs.

General remark: don't get carried away too much with enthusiasm. This is all early planning, still. But yeah, test the practical performance of mumble if you can and report back.

[Z-Man]

Right, test server is up: mumble://@simamo.de/Sandbox/
It's also available on the server browser as "Armagetronad Mumble Server". Glad to see we're not the only ones flooded with server names starting with spaces. Anyway, the sandbox channel has admin rights for all, so feel free to experiment with ACLs and channel linking. It seems to work a little different than I thought Links are always two-way and recursive. That means you can only define channel groups. In the tournament example, we'd need to link all channels and handle the rest via permissions.

* luke-jr wonders why we can't just add a VOICE_URI setting and support standard SIP or IAX2

If it's as simple as supporting mumble, which consists of calling the mumble program with mumble://playername@<server_name>/<channel>, we could have that, too. I'm just not aware of a program there that supports HUD overlays, so we'd really have to integrate all clientside stuff into arma itself (not necessarily a bad thing, mind you, but much more work), and I have the impression the standards are more for point-to-point connections and regular conference calls and not for organized conference calls with subgroups for teams and the ability to talk locally to your team and globally with the press of a button. Suggestions (actually usable SIP libraries and audio capture libraries, mostly) welcome.

[Your_mom]

After playing around with mumble and finding no one in the server i disconnected from the mumble server and then closed mumble only to realize this had crashed arma. I repeated this later on and the same thing happened. Bug?

using a windows xp march 08 19 build wrtl made.