Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Group Priority Range to Prevent Users from "Chaining" Together #21

Open
yesido9 opened this issue Feb 7, 2022 · 0 comments
Open

Group Priority Range to Prevent Users from "Chaining" Together #21

yesido9 opened this issue Feb 7, 2022 · 0 comments
Assignees
Labels
enhancement New feature or request

Comments

@yesido9
Copy link

yesido9 commented Feb 7, 2022

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.

@carlodrift carlodrift added the enhancement New feature or request label Feb 7, 2022
@LucasCdry LucasCdry added this to the 2.2 milestone Apr 9, 2022
@LucasCdry LucasCdry self-assigned this Apr 11, 2022
@LucasCdry LucasCdry removed this from the 3.1 milestone Jul 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Postponed
Development

No branches or pull requests

3 participants