[SPIGOT-3705] Handling scoreboard objectives separate from each other and teams Created: 21/Dec/17 Updated: 22/Dec/17 |
|
| Status: | Open |
| Project: | Spigot |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Minor |
| Reporter: | Maxim Van de Wynckel | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | scoreboard | ||
| Environment: |
Scoreboard API changes |
||
| Description |
|
I regretted creating this issue for a few years now, but I decided to create it for the archive. This change has a huge positive impact on the way scoreboards work but requires so much API changes that I can understand why it will never be added.
The problem In Spigot/Bukkit there is a new "container" for scoreboards that does not really exist in the client side. This container being the "CraftScoreboard". For clients you only have objectives that are shown in a display slot and teams that are completely separate from them. In NMS this container is present as well, since there is only one "main" scoreboard. And while the API allows you to create separate containers that each contain objectives, they override the "set of players" it applies to. This has huge compatibility issues with plugins wishing to create scoreboards with their own set of players the scoreboard applies to. For example: If I want to create 1 scoreboard with all players having teams it is very easy. But if another plugins wants to create separate scoreboards each being unique per player, it breaks the teams. While this seems like a compatibility issue (what it is) it is something that isn't or shouldn't be a problem clientside, seeing objectives and teams are completely handled seperately. Proposed change A way for teams and objectives to be registered with their own set of "entries". That way, when changes occur, those changes are send to the respective entries only. Proposed compatibility In order to keep it compatible I think the best way should be to register the teams and objectives inside the CraftScoreboardManager and keeping the current "CraftScoreboard" container and it's functions. The objectives and teams should have ways to add entries to them. When the objective/team is not created "globally" but inside the container it will add the entries to the scoreboard instead |
| Comments |
| Comment by md_5 [ 22/Dec/17 ] |
|
Feels free to open a PR containing these changes for review. |
| Comment by Maxim Van de Wynckel [ 22/Dec/17 ] |
|
Sorry for the late reaction The issue better explained: Currently the scoreboard API allows you to set a "scoreboard" for eah player. Each scoreboard can be assigned to multiple players. And each scoreboard contains both objectives and teams. Every player can only have **one scoreboard. So if a plugin wants to create their own teams or objectives they have to either check if the player has an unique scoreboard or is shared with multiple players (what is not something you can unless checking all hashes of the scoreboard instances of online players -> there is no "getAssignedPlayers()" for example). Or plugins just simply set a new scoreboard for the player - erasing everything other plugins have done Due to players only having one scoreboard this limits plugin compatibility, especially because it contains all objectives and teams. The protocol and clients however completely handle teams and objectives separately. This becomes even more clear now in 1.13 the "/scoreboard" command is removed and "/team" and "/tag" are created. Scoreboards handle PvP and player behavior because they contain teams that handle this, in fact it's actually just the teams that change the behavior of players, and not objectives. My proposal is to handle each objective separately from teams, so developers can create objectives (and display it where they want) without interfering with teams. Objectives alone are pure cosmetic, the only link with teams they have is the team color for the setDisplaySlot. But because they are grouped together with teams in a "scoreboard" it seems like "scoreboards" are the thing that handle player behavior About your reply: As it is now, it does indeed offers different functionality for PvP and player behavior. But that is mostly with teams. Scoreboards itself don't really do anything. The idea is not to have message boards, but to have compatibility for plugins to utilize teams and scoreboards without having to worry it breaks what other plugins try to achieve.
If you look at the scoreboard wiki (what is not updated to 1.13 but the changes in 1.13 concerning scoreboards are mostly command based) You can see there is a big difference between teams and "objectives". Teams , like you said do handle PVP differently. But the objectives have no interference with the teams apart from the display slot (with team color). -> What is something pure cosmetic and not player behavior. The command changes in 1.13 (from /scoreboard ..." to "/team ...") make it more clear that these two things are completely separate just like the protocol suggests. |
| Comment by md_5 [ 21/Dec/17 ] |
|
I don't fully understand the issue here, but I will say this: Scoreboards are very sophisticated things server side that encapsulate a lot of different functionality including the way PvP and other player behaviour operates. They are not glorified message boards. In particular it sounds like you want to decouple teams and objectives from eachother and allow players to be present in an arbitrary mismash of scoreboards, possibly including ones that they can't even see. It seems to me like this proposed API breaks what a scoreboard actually is to the server and repurposes it for something it is not designed to be (and may not able to be in future versions) |
| Comment by Maxim Van de Wynckel [ 21/Dec/17 ] |
|
The proposed API changes will not break any plugin that currently exists. In the "deprecation" period there will be basically two systems 1) The one with the Scoreboard containers where the scoreboard contains the SET of players it applies to 2) The one where the Team's and Objective's have their own SET of players it a applies to (calling it "entries" was incorrect)
When a plugin decides to update to 2) it will still be compatible with all others. The only thing that should be looked out for is making sure that the API is still understandable. Currently the "set of players" a scoreboard applies to is done using the "player.setScoreboard" method. My change would either need for those players to be registered on the teams/objectives (xxx.addPlayer) but this can be a bit confusing with "addEntry" seeing I made the same mistake. Or add them like currently but with "player.addToObjective" , "player.addToTeam" , "removeFromTeam" ,... |