By joining a Mumble Channel and then right-clicking on the name of one of its Children or Descendants, a Mumble Administrator is presented with a menu option that can be used to "Link" them. Mumble allows this through a tool that it calls "Channel Links". In this larger situation supporting two different Missions, it might be desirable for everybody participating in Mission1 to communicate with one another in one large group, without interfering with conversations associated with Mission2, and vice versa. For example, suppose that the simple Channel Hierarchy shown in the prior example grows into a larger Channel Hierarchy like this: Even though all three of these Mumble Channels have an obvious Hierarchical relationship, conversations within one of them are still isolated from the others unless additional Mumble tools are put into place.Ĭhannel Links: After a Mumble server grows enough to support several channels, it is sometimes desirable for two or more channels to be "Linked" so that their conversations can be shared. Following the same pattern, the Channel named "Team2" has one Parent ("Mission1") and one Sibling ("Team1"). The Channel named "Team1" has one Parent ("Mission1") and one Sibling ("Team2"). In that example, the Channel named "Mission1" has two Children, named "Team1" and "Team2". Here is a picture of a very simple Channel Hierarchy: In large Mumble Channel hierarchies, we might refer to a channel's "Ancestors" and "Descendants", and we might refer to the common ancestry between two related Channels according to the number of "Generations" back to a common Ancestor. The depth of this Parents/Children hierarchy can continue to grow.
This can go on for several "Generations", so that one Channel can be the Child of its Parent and it can also be the Parent of its own Children. Channels can have "Children", "Parents", and "Siblings". In these simple situations, conversations within one Channel are not heard in any of the other Channels.Ĭhannel Hierarchies: Related Mumble Channels can be organized Hierarchically, like members of a family. As simple Mumble servers attract more users, it is commonplace for them to be expanded with several distinct Channels, allowing different groups of people to isolate their conversations within those distinct Channels. In its most basic configuration, Mumble servers create just one Channel, and all users communicate with one another simultaneously by entering and speaking within that channel. In order to understand those tools, it's essential to understand certain fundamental terms as follows:Ĭhannel: The most basic tool for separating Mumble conversations is the "Channel". Mumble has a rich and powerful set of tools for controlling access. 5.1 Channel Group - Speak to children but not siblings.3.2 Channel Passwords and Access Tokens.I agree though that it would be desirable to have consistent naming throughout the UI. I think because neither works in the context the other is currently being used.
#Mumble access token password
It is not obvious that I have to put a channel password in an Access Tokens list (why 2 different terms, btw?) However I suggest making it separate from the other permissions to behave more like a password. If it isn't a password, it shouldn't be called password. I mean technically it could of course be done, but it's not as straight forward as one might expect. Access tokens are groups to the implementation. And when you look at the implementation you'll see that in fact there is no such thing as a password. It just checks if the user has permission to enter. The problem is however that the server doesn't check for password separately.
Can't the server just send a “password incorrect” message, when all other restrictions are met, to make it clear?
0 kommentar(er)
