Here's a proof-like justification that my proposed fix is necessarily safe (using information I only just realized), in case it helps expedite things:

(1) The only thing that can enable an objective for a player is `/scoreboard players enable`.
(2) A player `/trigger`ing an objective requires the objective to be enabled for the player.

`/scoreboard` can only act on the main scoreboard.
=> `/scoreboard` cannot act on a non-main scoreboard objective.
=> `/scoreboard players enable` cannot act on a non-main scoreboard objective.
=> A non-main scoreboard objective cannot be enabled for any player, because (1).
=> `/trigger` cannot act on a non-main scoreboard objective for any player, because (2).
=> `/trigger` cannot act on a non-main scoreboard.
=> `/trigger` can only act on the main scoreboard or be unable to act on any scoreboard.
=> Changing it so `/trigger` can only act on the main scoreboard removes no functionality.
=> Changing it so `/trigger` can only act on the main scoreboard is a safe fix.

And of course feel free to let me know if there's some part of this you don't understand or don't agree with.

[5:16 PM] GrantGryczan: (this is mainly directed at md_5 since they're who i was discussing this with, but i dont want to ping them in case they dont like being pinged. also sorry if this is the wrong channel--wasnt sure if it belonged here or in general)
hey, im the one who reported SPIGOT-6917, the issue about /trigger

considering it seems there is an in-depth discussion to be had about how to address this issue, would it be better to discuss it over discord instead (perhaps in DMs)? i find discussion over discord to be much easier, especially since this discussion might be more on the lengthy side. plus then we (me especially with my edits) wouldnt be sending so many email notifications to all the watchers for each message

and of course, there would be no obligation to respond to me immediately if we do discuss it in discord, just as there isnt over jira. it would just be easier due to discord being synchronous, and because it's easier to keep track of full discussion in discord than in jira comments
[5:19 PM] GrantGryczan: link to issue for convenience
[5:19 PM] GrantGryczan: https://hub.spigotmc.org/jira/browse/SPIGOT-6917
[5:25 PM] GrantGryczan: dont have the perms to pin it
[5:45 PM] GrantGryczan:
You're effectively saying that trigger is only ever used as a datapack function caller, rather than incrementing a scoreboard objective.

That's correct. /trigger is the vanilla interface intended as a stand-in for custom commands (hence the name--it triggers data pack functionality). There is a different command dedicated to incrementing a score, /scoreboard players add. The effect of incrementing a score is not the end goal of the /trigger command in general; it's just the means by which Mojang chose to accomplish allowing us to detect players entering /trigger. That's the sole purpose of the /trigger command: something non-ops can enter in chat that can be detected in vanilla.
[6:52 PM] GrantGryczan: (read the above message before this one since i believe it should resolve an important misunderstanding)

Are they broken by this, or are they broken by a plugin manipulating the scoreboard in a way which is impossible in Vanilla? Depends on your perspective.

Consider the parallels between this (multi-scoreboard support) and multi-world support. In Vanilla a command such as /gamerule affects all worlds, whereas in Spigot it only affects the player's current world. That's roughly analagous to the situation here.

That's true, but there are three important differences between that situation and this one in your analogy:

1. Per-world game rules can be worked around: a data pack can set a game rule in multiple worlds. On the other hand, a data pack cannot work around this issue whatsoever. Normally, there's no way for data packs to detect non-ops entering anything in chat except /trigger. But with this issue, not even /trigger can be detected, leaving us with no means to detect any chat input from non-ops at all.

2. Users can naturally understand and be satisfied with game rules being per-world. In fact, that functionality is often desirable. On the other hand, for this issue, all the user knows is that /trigger spawn, for example, is supposed to teleport them to spawn. If it instead gives an error, the user is not going to naturally understand or be satisfied with that. There's nothing desirable to be gained from it by users, data pack devs, or plugin devs.

3. If this issue were fixed by making /trigger only interact with the main scoreboard, plugins could continue manipulating scoreboards however they want, with no loss of functionality. In fact, not a single thing would need changing in any plugin, because /trigger is not a feature any plugin uses or would have any reason to use. The same is not true of per-world game rules.
[7:24 PM] GrantGryczan: the two above messages are my replies to @md_5's last comment on the issue (sorry theyre so long!)

(pinging you so you automatically join the thread and see new messages in it since you were participating in this discussion, but feel no obligation to reply immediately, or at all if someone else decides to chip in instead)
[7:47 PM] md_5: Moving discussion from JIRA to Discord is not helpful. When someone wants to look into this bug 5 years from now it is a hell of a lot easier to refer to the bug report than search for a thread on Discord
[7:48 PM] GrantGryczan: really? i was thinking worst case i could just link the thread from jira when we're done
[7:48 PM] md_5: I'm not against your change, I simply think it is not as one-sided as you make it out to be and careful examination is needed before changing a behaviour that has existed for 5+ years and was for one reason or another coded that way by Mojang
[7:49 PM] md_5: I don't really have anything else to add, that's why I didn't make any additional comments on the ticket
[7:49 PM] md_5: I am leaning towards making the change, but I want to investigate it further and see if anyone else makes comments
[7:50 PM] md_5: It's clearly not a time sensitive issue given it seems to be 5+ years old
[7:52 PM] GrantGryczan: ah okay, yeah thats fair. my biggest concern with the fix for this is that it wouldnt be nice to implement on spigot's end, not that it would have any negative effect for plugins or players
[7:52 PM] GrantGryczan: but thats up to you
[7:52 PM] md_5: again, I really don't think you can say that with such conviction
[7:53 PM] md_5: https://xkcd.com/1172/
xkcd: Workflow

There are probably children out there holding down spacebar to stay warm in the winter! YOUR UPDATE MURDERS CHILDREN.
[7:56 PM] GrantGryczan: well i have years of experience with commands and the community surrounding commands, and thus with really weird edge cases in which devs use commands in ways theyre not intended to be used. but despite that, i would still argue there couldnt possibly be a big enough issue to make it not worth fixing in the way ive recommended. and even if a plugin is, hypothetically, using /trigger for something (even though they could and normally would be using custom commands instead), itd still be a trivial fix for them to switch to custom commands instead. plugins could work around this change, but we cant work around not having this change
[7:57 PM] md_5: You're reading into what /trigger is 'meant to do' based on what you want it to do. You may be right, but it's not a particularly convincing argument when it clearly is more general
[7:57 PM] md_5: It's not just about plugin commands
[7:57 PM] md_5: the MC wiki states 'Modifies a scoreboard objective with a "trigger" criterion. Allows non-operator players to modify their own scoreboard objectives under tightly controlled conditions. '
[7:58 PM] md_5: It seems reasonable that a player might expect the trigger command to do exactly that, modify their own scoreboard objectives
[7:59 PM] md_5: Again, I'm not against your change, on balance it probably is the correct change; but it is definitely not 100% wrong the way it is and you should recognise that
[7:59 PM] GrantGryczan: no, no player would expect that, i can assure you. theres already the /scoreboard command for that which players are much more inclined to use.

but even if they did, if a data pack (or plugin for that matter) wanted to let players modify their scores using /trigger, they very well could with or without this change, so thats not exactly relevant either way
[8:00 PM] md_5: You can't speak for every MC player. It's literally what I expect based on reading the MC wiki
[8:01 PM] GrantGryczan: even if a player tried to use it for that purpose without this issue, it wouldnt let them, because it would say "You cannot trigger that objective yet", since a data pack is required to enable the trigger
[8:01 PM] GrantGryczan: unless they manually enter /scoreboard players enable @s test before each time they want to run the trigger command. in which case they would just use the /scoreboard command to change their score in the first place, if they understand how triggers and scoreboards work well enough to know to do that
[8:04 PM] GrantGryczan: it doesnt really matter though; theres little problem with just letting this issue settle for a bit either way as you suggested. players would just have to wait a bit longer for compatibility between their favorite plugins and data packs
[8:04 PM] GrantGryczan: so if you believe thats the safer route, then im good with that
[8:06 PM] md_5: It needs to be checked, but my assumption is that this has been the behaviour for 7 years
[8:06 PM] md_5: That's what you need to understand, you're looking to change behaviour that is at least somewhat justifiable and has been in place for 7+ years
[8:07 PM] md_5: Just because you think it is stupid someone would rely on it, doesn't mean that people don't
[8:07 PM] GrantGryczan: no im not saying it's stupid that someone would rely on it; im saying nobody would rely on it
[8:07 PM] md_5: The fact that you're the first person to ever bring it up is proof of that
[8:07 PM] GrantGryczan: i understand that you dont see it the same way that i do though, and that we disagree on that
[8:07 PM] GrantGryczan: oh actually, on that note
[8:07 PM] md_5: Again, you can't say statements like '; im saying nobody would rely on it'
[8:08 PM] md_5: That is literally the only point I'm trying to make to you
[8:08 PM] md_5: You need to understand the scope of what you're asking
[8:09 PM] GrantGryczan: and i gave my argument against that. believe me when i say i understand the point youre trying to make, because in general i would agree, but i have an understanding of the full context surrounding this as this has been my full-time hobby for as long as i can remember, and in this case i believe that general truth is irrelevant. again though it doesnt matter; i dont want to waste your time discussing this side point since going with what you think is fine either way
[8:13 PM] GrantGryczan: unless you particularly want to, in which case im down, but i dont see that being something youd enjoy
[8:16 PM] GrantGryczan: heres what i was going to reply to this with:
oh actually, on that note: the reason this took so long to report is because it was actually very difficult to determine the cause of the issue. i intended to report this years ago, and data packers have been running into this issue with plugins for ages. (i can show you many examples of this if you dont believe me, haha.) but we just tell our users not to use plugins if they want to use our packs because we had no clue what caused it.

i was only able to report this due to the fact that i got a hold of a plugin developer who was actually interested in helping me figure out the cause. neither i nor any other data pack developer had ever considered bukkit would add entire separate scoreboards from the vanilla one, so that was really interesting to discover and explained a lot. the plugin developer who explained that to me is also the one who made the minimal repro thats attached to the jira issue
[8:17 PM] GrantGryczan: case in point, it's not because it's a rare issue, but because we couldnt figure it out well enough to make a meaningful report lol
[8:26 PM] GrantGryczan: to demonstrate that, when i shared the report on the Minecraft Commands server, i got responses such as
Image
[8:26 PM] GrantGryczan: and
Image
[8:26 PM] GrantGryczan: hahaha
[8:33 PM] GrantGryczan: in fact this issue is reported to us (not to you guys) like every other day. and it's even been reported to spigot twice before (https://hub.spigotmc.org/jira/browse/SPIGOT-6358?jql=text%20~%20%22You%20cannot%20trigger%20this%20objective%20yet%22), but their reports were bad so they were closed as invalid
[8:34 PM] md_5: Right. Again, it'll be investigated and probably fixed
[8:34 PM] md_5: I don't really think this discussion added anything to that
[8:35 PM] GrantGryczan: it hasnt! but it did let me know the reason you didnt respond, because i only started this discussion under the impression you didnt respond just because you hadnt gotten the time to yet
[8:36 PM] md_5: Well if I didn't have the time to respond then harassing me for a response probably wouldn't be the smartest move 😉
[8:36 PM] md_5: But also yes, I haven't had time to dig into the entire history of /trigger
[8:36 PM] GrantGryczan: i did not harass you for a response, did i? i repeatedly said you arent obligated to respond immediately
[8:36 PM] GrantGryczan: i wanted you to respond on your own time
[8:37 PM] md_5: The fix is obviously a dead simple one line of code, but the difficulty here isn't the fix itself
[8:37 PM] GrantGryczan: if you saw what i did as harassment then i apologize
[8:38 PM] md_5: Well its more if time was the issue moving it to discord doesn't make more time
[8:39 PM] GrantGryczan: it wasnt meant to make more time, it was just meant to possibly make communication easier. i wasnt even sure youd be in favor of the idea, which is why i asked before making the thread
[8:39 PM] GrantGryczan: even though someone else answered for you and i took their word for it
[8:40 PM] md_5: bugs on the bug tracker 🙂

(Moving this discussion to a thread in the SpigotMC Discord server.)

> I'm talking about the functionality seen by the end user, not the internal implementation. You may not have changed the internal implementation, but the functionality seen be the end-user is still indirectly affected by a Bukkit API.

Is it? You can equally say that your proposed change: editing a shadow scoreboard the user can't see is a change to the functionality seen by the end-user.

> There is no such use case. Plugins don't use `/trigger`–they have no reason to since they can add custom commands. It's only useful for data packs. There are countless tangible use cases where data packs are broken by this, as `/trigger` is a very common command for data packs to use. There are no such use cases for plugins, so I don't know why you would prioritize consistency with plugins' scoreboards here.

You're effectively saying that trigger is only ever used as a datapack function caller, rather than incrementing a scoreboard objective.

> There are countless tangible use cases where data packs are broken by this

Are they broken by this, or are they broken by a plugin manipulating the scoreboard in a way which is impossible in Vanilla? Depends on your perspective.

Consider the parallels between this (multi-scoreboard support) and multi-world support. In Vanilla a command such as /gamerule affects all worlds, whereas in Spigot it only affects the player's current world. That's roughly analagous to the situation here.

PS: Please stop editing your post, every time you do it an email is sent.

> The functionality is exactly the same as Vanilla in that /trigger is Vanilla code untouched by Spigot.

I'm talking about the functionality seen by the end user, not the internal implementation. Bukkit may not have changed the internal implementation, but the functionality seen by the end user is still indirectly affected by a Bukkit API in a way which breaks vanilla functionality. The same vanilla commands yield a different result in Bukkit than in vanilla, in a way which end users do not expect (and frequently complain to us about).

> For a player expecting /trigger to increment their score as displayed on their scoreboard, that behaviour is now broken.

Plugins don't use `/trigger`–they have no reason to since they can add custom commands instead. In the real world, there is no such use case where any plugin's functionality would be broken by this fix. But there are countless real-world use cases where data packs are broken by the lack of this fix, as `/trigger` is a very common command for data packs to use. There are no such use cases for plugins, so why prioritize consistency with plugins' scoreboards here?

> The issue here is that this vanilla functionality is not provided as expected: `

The functionality is exactly the same as Vanilla in that /trigger is Vanilla code untouched by Spigot. Vanilla doesn't have per-player scoreboards so your justification there is moot.

Playing devil's advocate here, if this change was made /trigger would not increment the scoreboard currently visible to the player. For a player expecting /trigger to increment their score as displayed on their scoreboard, that behaviour is now broken.

Also, just in case, it may be worth noting that the fix for this presumably should ideally involve no client-side effects. For example, the vanilla command `/execute as @a run trigger test` (which may be inside a data pack function running purely server-side) runs the trigger as all online players, incrementing their `test` score, without necessarily sending a single packet to any client.

Using the main scoreboard is the functionality that data packs expect from `/trigger`, as it is the functionality provided by vanilla. The issue here is that this vanilla functionality is not provided as expected: `/trigger` sometimes doesn't use the main scoreboard.

For this issue not to be the case, `/trigger` must always use the main scoreboard. That's the expected functionality, so that's necessarily the fix. If that expected functionality is not implemented, players with data packs installed will continue to have this issue.

And making `/trigger` always use the main scoreboard would certainly do no harm, since plugins never use `/trigger` (they use custom commands instead). It is not useful for `/trigger` to use any scoreboard but the main one.

Well the two commands are not touched... and Trigger use the Main Scoreboard for suggestions but not for run...

but not sure if the fix is make /trigger only use the main scoreboard...