You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently there is an issue that involves players being able to "chain" together to increase the range of proximity chat. The best way to visualize it is an test I did with two other players. Assume horizontal range is 30 blocks. If three players stand 30 blocks away from each other in a straight line, they will all be in the same channel even though two of them are 60 blocks away from each other, as one player is 30 blocks away from both of them. With larger amounts of players, this has potential to drastically and unintentionally increase the range of proximity chat.
A suggestion I have is for an option in the config similar to horizontal/vertical range and falloff. I'll call it "Group Priority Range." Group Priority Range can be set to a certain amount of blocks similar to other config settings, and is only necessary if more then three players are using proximity chat. If there were three players all in range with at least one other player in an area, Group Priority Range would detect the distance between the players and see which is greater. Group Priority Range would then detect the distance between the two players farthest from each other and would disconnect the player farthest from both the other two if the number of blocks between the two farthest players is greater then the number in the config. This system should also be able to work with larger groups of players. It is a bit complicated to explain, so I'll give an example of how this would work.
There is 3 Players: Player A, B and C. The horizontal range is 30 blocks, falloff is 0, and the "Group Priority Range" is set to 40 blocks. Player A and B are 29 blocks apart, Player B and C are 30 blocks apart, and Player A and C are 59 blocks apart. In the current version, they would all be in the same channel. With this new feature, Player A and B would be put in the same channel, and Player C in a separate channel or the lobby. However, if Player A and C get within 40 blocks of each other, then all three would be connected in the same channel.
The Group Priority Range can be set to several values. 0 could be changed to make it function like the old version. Setting it to less then horizontal range would not be recommended as it'd make it so if multiple players are in a channel it would basically reduce the horizontal range to the same value. Setting it to the same as the horizontal range would essentially make it so there would be an imaginary circle with a midpoint, the diameter would equal the horizontal range, and would require all players in the same channel to be in the boundaries of this imaginary circle. Setting it to higher then horizontal range would make it function similar to the "same as" setting, except with a bit more "falloff." It also might make sense to be able to adjust Group Priority Range both horizontally and vertically, so that they can match both values if they are different.
This is a pretty complex idea, so here's a less detailed explanation: Currently Proximity Chat when puts players all in the same channel it only scans the ranges of two people at a time without taking other players in the channel into context. It can do this with several "separate" connections which it then puts together, but it only really takes two people into context at a time. Group Priority Range would make it so the distance between all players in the channel would be scanned, and arrange channels to favor the closest players to each other and make other players have to get in everyone's range to connect. This will make it so you can't connect to the same channel as a player outside your range just because you're both connected to the same player within range.
An alternative might be removing the option to set the Group Priority Range in the plugin, and making it so you can only disable it or set it to be the same as horizontal/vertical range. If setting it to be more "custom" would be to difficult to implement, then these would be the two most important values and there isn't too much loss as it'd already be tied to horizontal + vertical range. If possible to have a custom number, it might also be better to make it so the number you input into the voice.yml config for Group Priority Range is blocks in addition to the horizontal/vertical range. If you set this number as zero, it'd be the same as the horizontal/vertical range. You could set it higher if you wanted to give a bit of "falloff" range, and setting it to a negative number could disable the feature, as setting it to a number lower then the horizontal/vertical range would be useless as previously mentioned. Group Priority Range is the only effective way I could think of to solve the problem of players able to "chain."
Not sure if this idea is even technically feasible. However, considering the only detection in the system is the distance between players (already used to make horizontal, vertical, and falloff range possible, or even proximity chat itself), and not anything currently impossible such as adjusting volume or detecting blocks, this idea does sound possible.
The text was updated successfully, but these errors were encountered:
Currently there is an issue that involves players being able to "chain" together to increase the range of proximity chat. The best way to visualize it is an test I did with two other players. Assume horizontal range is 30 blocks. If three players stand 30 blocks away from each other in a straight line, they will all be in the same channel even though two of them are 60 blocks away from each other, as one player is 30 blocks away from both of them. With larger amounts of players, this has potential to drastically and unintentionally increase the range of proximity chat.
A suggestion I have is for an option in the config similar to horizontal/vertical range and falloff. I'll call it "Group Priority Range." Group Priority Range can be set to a certain amount of blocks similar to other config settings, and is only necessary if more then three players are using proximity chat. If there were three players all in range with at least one other player in an area, Group Priority Range would detect the distance between the players and see which is greater. Group Priority Range would then detect the distance between the two players farthest from each other and would disconnect the player farthest from both the other two if the number of blocks between the two farthest players is greater then the number in the config. This system should also be able to work with larger groups of players. It is a bit complicated to explain, so I'll give an example of how this would work.
There is 3 Players: Player A, B and C. The horizontal range is 30 blocks, falloff is 0, and the "Group Priority Range" is set to 40 blocks. Player A and B are 29 blocks apart, Player B and C are 30 blocks apart, and Player A and C are 59 blocks apart. In the current version, they would all be in the same channel. With this new feature, Player A and B would be put in the same channel, and Player C in a separate channel or the lobby. However, if Player A and C get within 40 blocks of each other, then all three would be connected in the same channel.
The Group Priority Range can be set to several values. 0 could be changed to make it function like the old version. Setting it to less then horizontal range would not be recommended as it'd make it so if multiple players are in a channel it would basically reduce the horizontal range to the same value. Setting it to the same as the horizontal range would essentially make it so there would be an imaginary circle with a midpoint, the diameter would equal the horizontal range, and would require all players in the same channel to be in the boundaries of this imaginary circle. Setting it to higher then horizontal range would make it function similar to the "same as" setting, except with a bit more "falloff." It also might make sense to be able to adjust Group Priority Range both horizontally and vertically, so that they can match both values if they are different.
This is a pretty complex idea, so here's a less detailed explanation: Currently Proximity Chat when puts players all in the same channel it only scans the ranges of two people at a time without taking other players in the channel into context. It can do this with several "separate" connections which it then puts together, but it only really takes two people into context at a time. Group Priority Range would make it so the distance between all players in the channel would be scanned, and arrange channels to favor the closest players to each other and make other players have to get in everyone's range to connect. This will make it so you can't connect to the same channel as a player outside your range just because you're both connected to the same player within range.
An alternative might be removing the option to set the Group Priority Range in the plugin, and making it so you can only disable it or set it to be the same as horizontal/vertical range. If setting it to be more "custom" would be to difficult to implement, then these would be the two most important values and there isn't too much loss as it'd already be tied to horizontal + vertical range. If possible to have a custom number, it might also be better to make it so the number you input into the voice.yml config for Group Priority Range is blocks in addition to the horizontal/vertical range. If you set this number as zero, it'd be the same as the horizontal/vertical range. You could set it higher if you wanted to give a bit of "falloff" range, and setting it to a negative number could disable the feature, as setting it to a number lower then the horizontal/vertical range would be useless as previously mentioned. Group Priority Range is the only effective way I could think of to solve the problem of players able to "chain."
Not sure if this idea is even technically feasible. However, considering the only detection in the system is the distance between players (already used to make horizontal, vertical, and falloff range possible, or even proximity chat itself), and not anything currently impossible such as adjusting volume or detecting blocks, this idea does sound possible.
The text was updated successfully, but these errors were encountered: