Forum

Mumble delayed-relaybot for listening to match comms while watching STV

Created 24th January 2010 @ 00:27

Add A Reply Pages: 1 2 3 Next »

frymaster

As some of you may know, me and a mate have been working on this for about some time, and with the release of mumble 1.2 final we’ve decided to distribute it.

THE PROBLEM
Your clan is playing a match. Those who haven’t been picked / your supporters / girlfriends / grandparents want to watch on source tv. But of course, the TV is delayed by 90 seconds. So they don’t get to listen to your epic team comms like “kill the scout! he’s over there! no, there! theeeeere!”

THE SOLUTION
Eve joins your match channel and… eavesdrops. When JoeBloggs joins the match channel, Mimic-JoeBloggs automatically connects and joins the spectate channel. Every time JoeBlogs speaks, Eve funnels it to Mimic-JoeBloggs. 90 seconds (or whatever) later, JoeBloggs relays it to your adoring fans

We’ve been using it for a little while and it seems to work well (i.e. isn’t crashing out any more ) and makes watching your team’s matches a lot more interesting, so now I’d like some feedback from a wider audience

Things we’re considering:
– Having the mimics be in a different server than the eavesdropper – in terms of programming this is easy (we just have to turn OFF some code designed to prevent mimics of mimics) – if we did this, then you could have BOTH teams comms available in the one server, for the listeners to compare and contrast
– Turning the volume level of the mimics down so it’s easier to talk over them – this is pretty hard, at the moment we just store the data payload and forward it on, we’d actually have to parse the packet, decode the audio, re-encode the audio, and repackage… but it could be done IF there’s sufficient interest

A windows package is available here here – if it doesn’t work you might need this package from microsoft

The python source can be downloaded from here
(requires a mumble 1.2 server and either python 2.6, or python 2.5 with added ssl support, as well as the google protocol buffers module as explained on the webpage)

One thought is it could be very useful for e.g. the mentor project – the mentor doesn’t have to join the actual game server in order to see the play and listen to the comms (which some opposing teams object to) – he could listen to the delayed comms while on STV instead

feedback welcome


Last edited by frymaster,

Serious Cat

PaC

That’s some nice work there Frymaster!

I remember you talking about this while you were still developing it; kudos for releasing it to the public!

Arie

(serveme.tf)
FB
[FB]

We have this running on our 1.2 Mumble, works as advertised, A+++

Cloud

.wldcrd!

Sounds awesome :)

ilike2spin

RLM

Quoted from Cloud

Sounds awesome :)

It certainly does, does it cause any increase in latency or anything though?

Vazzan

TwistedPlay.

This is awesome! end of

Doesn’t support mumble 1.1.8 ?

anyway, awesome job :)

frymaster

Quoted from Peio

Doesn’t support mumble 1.1.8 ?

anyway, awesome job :)

Nope, mumble 1.2 standardised a lot of control messages making this sort of thing a lot easier to write, and anyway this was done back in december when 1.2 came out so we didn’t see much point in spending a lot of effort getting 1.1 working

Quoted from ilike2spin

It certainly does, does it cause any increase in latency or anything though?

not for the match players because they don’t have to do anything; as far as they’re concerned it’s just an extra user sitting in the match channel

it does use TCP mode instead of the faster UDP mode to talk to the server, but generally it’s going to be on the server itself, so it doesn’t matter. If you think the relay is slightly delayed you can always turn down the delay to e.g. 89.5 seconds (although I’ve just realised that at the moment you can only do a whole number of seconds, for no good reason at all)

I’ve just put up a slightly updated version that lets you set fractions of a second delay, in case you are finding any lag in the relay. For rather tedious efficiency reasons, a delay of under 5-and-a-bit seconds doesn’t work well (if mimics aren’t currently waiting to say something, they only check for new data every 5 seconds)


Last edited by frymaster,

oblivion

This looks really awesome, I’ve often wondered if this was possible and now it is!
Best get onto 1.2 instead of 1.1 for a bit i guess…:D

AuguR

nice work comrade, sweet idea tbh

kira!

xen
don\\\'t

Didn`t find any simple Installation F.A.Q. :(

So this is only for mumble? or can be used for murmur, so anyone who connected to Spectators channel and don`t have this plugin(?) will have 90sec delay?

frymaster

It’s not a mumble plugin, it’s a bot that connects to the murmur server. So no clients need to do anything, it just needs a server to run on.

So in this screenshot, the bot (Eve) sits in the match channel. When I join the match channel, it spawns a relaybot (Mimic-Frymaster) which sits in the spectate channel and relays the comms on a 90 second (or whatever) delay.

As it’s just a python script, there’s no installation per se; the “Prerequisites” section of the webpage shows how to set it up (get a computer with python, download an extra python add-on, compile the python/mumble protocol module)

There’s no FAQ because noone’s ever asked me any installation questions yet :P


Last edited by frymaster,

DeNeusbeer

(Legend)
HoT<3

So, what’ll happen if i call myself Mimic-frymaster and go sit in your match spec channel before you connect:D

But in all seriousness, this is a cool script.

it would call the mimic Mimic-frymaster0

A similar thing happens when a player looses their net connection during a match and then rejoins within 90 sec. The original mimic is still in the spec channel therefore that name is taken so it creates a new mimic with a 0 on the end of it.

Nmx

ᴷᵈ

Nice stuff
edit : my bad, bad reading ( again ) :D


Last edited by Nmx,

Add A Reply Pages: 1 2 3 Next »