Minecraft positional audio

[zsawyer]

Hi,

I have created a Minecraft-Mod that adds support for mumble's positional audio. http://www.minecraftforum.net/viewtopic.php?f=1032&t=235800

It uses the Link-Plugin (1.2.0) - so basically it should be called "native" support.

I now would like to add Minecraft to the list of supported games but I am unsure as of where to insert it. And I do not understand what the difference between "Basic support" and "Yes" is.

Basic support means that the games don't use the extended positional audio features of Mumble 1.2, but still allow positioning.

What is "extended positional audio feature" as compared to "allow positioning"?

Any hints would be appreciated.

Regards,

zs

[pcgod]

AFAIK extended support means that it uses the context and identity information correctly (i.e. ingame username in the identity field and server/team/etc in the context field).

[kissaki]

Yes, that's also how I understand it.

http://mumble.sourceforge.net/Games#Native_Support_Plugins

is the place, which you probably found.

Plugins is for those which are hacked via mumbles plugins. As your mod provides native support, add it to the Native Support Plugins. Name it "Minecraft Mod" and add a link, so ppl know which game it is and that it is a mod.

[zsawyer]

Sorry for the delayed response but the forum would keep freezing on me for no reason.

Thank you both for your replies. That is exactly what I wanted to know.

The mod basically supports identity and context - however it is not really used since Minecraft doesn't seperate teams and squads - context will be "MinecraftAllTalk" (i might add the server IP in a later version) and identity will be the player's nick.

So just to be sure I would go for "basic support" untill I inserted the server ip into the context.

Anyways: So I tried to edit the page like it said here: http://mumble.sourceforge.net/Link

Note: Please don't forget to add your game to the list of link plugin supported games.

 

However this seems deprecated. I was not able to edit the page (http://mumble.sourceforge.net/Games) due to insufficient privileges.

Maybe this "Autoconfirmed users" thing does not work correctly or:

Could someone with elevated rights edit the page please (and maybe correct the quoted text to something more appropriate)?

Thank you.

[kissaki]

So just to be sure I would go for "basic support" untill I inserted the server ip into the context.

Yes.

Wiki needs you to wait 3 days for your account to be useable.

[zsawyer]

Good to know.

Thank you very much for your kind help!

Edit: Thank you for putting it in there too!

Regars,

zs

PS: I love the Mumble project and I hope that by getting this important feature to work with such a relatively popular game like Minecraft that the knowledge of this great project will spread even more. :)

[zsawyer]

Hello again,

Right now I am porting the mod to Linux and all went well.

At the same time I wanted to integrate the "context" more correctly and add Server IP and Port.

For creating the context I was Planing on something like this:

String context = "Minecraft:" + server_ip + ":" + port + ":AllTalk";

 

However I came to think that this will pose some problems that actually would effect myself (and I imagine this would apply to some others as well):

There is a scenario where this will cause problems for use with local servers

- I access my dedicated Minecraft server which is another PC in my LAN - thus Minecraft will "know" the LAN-IP - however my friends who are connecting from the internet via my router + port forwarding will "know" the server by the router's "Internet"-IP-address. My context will not match their context. "Minecraft:192.168.0.1:10000:AllTalk" != "Minecraft:209.85.148.104:10000:AllTalk"

- The same applies for local servers: "Minecraft:127.0.0.1:10000:AllTalk" != "Minecraft:209.85.148.104:10000:AllTalk"

Using a DNS-name would maybe be a work around but connecting to something like "myrouter.intheweb.com" would attempt to create an inbound connection on the same interface (router's WAN-Port) that is opening the connection (most routers do not allow that).

Having a local DNS server might help but I don't like that idea as it is too much effort.

Am I missing something? Is there any better way of handling this? If not I will have to stick to "MinecraftAllTalk" and creat one mumble channel per minecraft server.

Thanks in advance.

zs

[kissaki]

Even when in LAN, simply connect via remote IP. :)

[zsawyer]

Even when in LAN, simply connect via remote IP. :)

 

Using a DNS-name would maybe be a work around but connecting to something like "myrouter.intheweb.com" would attempt to create an inbound connection on the same interface (router's WAN-Port) that is opening the connection (most routers do not allow that).

 

It doesn't matter if I am using an IP or a DNS-name - the router simply does not allow it. The source interface cannot be the target interface. Some routers allow NAT Loopback in that case there would be no issues - but that is not default for all routers.

So "Extended Support" infact makes using the Mod impossible for those that have no NAT Loopback and are hosting a server in their LAN. While right now with only basic support there will be no issues.

Also: Creating a channel in Mumble is alot easier then either buying a new router or setting it up with NAT Loopback.

I am going to stick with just basic support for now untill we find a better solution. Any suggestions are much apprechiated.

[hacst]

You don't have to necessarily put ip:port in there. Just something that - as uniquely as possible - identifies the "unit" (be it server, team, squad) in which players should hear each other positionally. Meaning that even a servers name might be sufficient and still better than no context at all. The basic rule however is: When in doubt put the information into identity or leave it out before messing up context.

Now if one ever wants to do any fancy stuff (switching into channels, giving rights etc.) based on these fields having an easily parseable format in there might be a good idea. For the BF2 one we chose a json dictionary (something like {"squadleader":false, "teamleader":true, "name":"Bernd"}).

Not sure if this makes any sense in Minecraft. I guess you know much better than we do what information, if any, might be worth getting out of the game.

[zsawyer]

The basic rule however is: When in doubt put the information into identity or leave it out before messing up context.

Now if one ever wants to do any fancy stuff (switching into channels, giving rights etc.) based on these fields having an easily parseable format in there might be a good idea. For the BF2 one we chose a json dictionary (something like {"squadleader":false, "teamleader":true, "name":"Bernd"}).

Not sure if this makes any sense in Minecraft. I guess you know much better than we do what information, if any, might be worth getting out of the game.

 

Thank you for your response.

About the "identity" as JSON-String: Is this being parsed by Mumble/Murmur by default or did you have to write a custom Mumble/Murmur or script? I do not see how identity is evaluated by Mumble. I am having a hard time finding the documentation for the link plugin and the developers documentation of Mumble.

 

You don't have to necessarily put ip:port in there. Just something that - as uniquely as possible - identifies the "unit" (be it server, team, squad) in which players should hear each other positionally. Meaning that even a servers name might be sufficient and still better than no context at all.

 

Furthermore: You gave me an idea:

I am applying that json approach to context (not that it matters) and instead of using the server IP and Port I will try to get a unique id from the world that one plays on. I actually found something and it works:

Appearently there is a world object in Minecraft that has a name and a random seed (as java Float) this looks quite promising. And after testing I am getting a context like this:

 {"game":"Minecraft", "WorldName":"MpServer", "WorldSeed":"-7682797762619213734"}

While I was disappointed that the name appears to be for all multiplayer maps always "MpServer" the random seed prooved quite helpful and I successfully tested and concluded that this context-string differentiates between servers like desired without the NAT-Loopback problem.

Now I have a new problem... yet again:

I do not like the default behavior of the mumble client. More precisely how it is handling linked players that are on different servers (not paired).

To elaborate:

When players are in the same mumble channel but on different worlds (respectively servers) they should NOT hear each other when using PTT since they are transmitting locally. This is simply because different worlds mean different locations.

Instead right now when a player is in World A locally (with positional audio) talking to another player in World A a third player in World B would hear the other 2 non-positionally (force center) when he should not hear them at all.

This imo defeats the whole purpose of differentiating base on the context.

Why have them in the same channel if they do not hear each other? Well I'd like to take the Project Reality (Squad Leader Radio) approach and have the users assign a 2nd Key to Shout to Channel.

This way people can use it like Teamspeak and talk to the whole party in the channel using Shout and when it comes to local chatter ("where are you", "come here" etc.) the rest of the party minding their own business is not bothered by cluttered comms.

So my questions:

Is there some client setting that I am unaware of (like default volume for no-linked users = 0%)?

Am I doing this whole context approach wrong?

Thanks for reading,

zs

[kissaki]

Using pos. audio in such a heavy simulating way is the minority. The standard use-case is that ppl. will want to talk to each other and have pos. audio as a nice plus-feature and fun thing. They still want to talk to the other players who are not in-game or not on that server. Thus, it should be configurable or the keys mapped the other way around (the minority bind and use a extra key).

No, there is no such thing yet.

[zsawyer]

Using pos. audio in such a heavy simulating way is the minority. The standard use-case is that ppl. will want to talk to each other and have pos. audio as a nice plus-feature and fun thing. They still want to talk to the other players who are not in-game or not on that server. Thus, it should be configurable or the keys mapped the other way around (the minority bind and use a extra key).

No, there is no such thing yet.

 

Ok this ofcourse is not what I was hoping to hear. I am sad that this is the way positional audio is seen - "a nice plus-feature and fun thing".

I can see that the above is still a rare use case. However positional audio is one important feature of Mumble and as such I would like to see more emphasise on this "unique selling proposition".

Mumble has the potential for this "heavy simulating way" as shown by PRMumble (http://www.realitymod.com/mumble) with daily 100+ people joining one server where the main focus is on this positional audio feature.

I submitted a new Feature Request (https://sourceforge.net/tracker/?func=detail&aid=3252866&group_id=147372&atid=768008) hoping that this sector gets some more attention and shifts this nice-to-have to a must-have feature when playing games and using mumble (I am also confident that this would also be useful for the upcoming PRMumble).

Thanks,

zs

[kissaki]

Yes, but still, confusing ppl. because they won’t hear each other is not the way to go.

So many ppl. can’t even read the audio wizard, which explains so much. Thus, I still think having to bind key and shout to channel to be able to hear each other at all is not what we want, by default! Nothing against a setting-flag to switch to just that behavior though.

/e:

Btw, I’d be happy to join a session there, but not with Bf2 (mod) … :)