Jump to content
Mumble forums

zsawyer

Members
  • Posts

    10
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

zsawyer's Achievements

Newbie

Newbie (1/14)

  1. Isn't that what https://github.com/mumble-voip/libmumble was intended for? But I guess it is not up-to-date really.
  2. Hi there, I know this is a fairly old post but I wanted to drop a note that we are partly investigating this possibility over at https://github.com/zsawyer/MumbleLink (the Minecraft mod for positional audio). https://github.com/zsawyer/MumbleLink/pull/35#issuecomment-787217898 Thanks for the request. I will keep the mute on death idea in mind if we ever get that far. On your use-cases: 1./2. channel movement and dynamic creation as well as muting would be something that has already been done for other games using the mumo plugin 3. This is a tough one. Project Reality solved this by building their own mumble version. We probably won't go this far. Also this is a bit tricky because how do you ensure that you can trust which settings the client is reporting? It would be very easy to cheat still. Regards, zs
  3. -> Easy positional audio for java! I have implemented an interface library which uses the link plugin to hand over positional audio information to mumble. https://github.com/zsawyer/mumble-LinkAPI This will come in handy for basically all Java applications, I think. I could use some help with cross compiling if it doesn't make it into mumble directly (see https://sourceforge.net/p/mumble/feature-requests/1094/). comments, help, ideas? Thanks for reading, zs
  4. 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
  5. 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. 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
  6. 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.
  7. 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
  8. 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. :)
  9. 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 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.
  10. 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. What is "extended positional audio feature" as compared to "allow positioning"? Any hints would be appreciated. Regards, zs
×
×
  • Create New...