Paper: "Collision Rule" team options violate vanilla behavior

[CeIebrimbor]

Latest version of Paper and specifically related to the Collision Team option settings.

The collision rule setting creates the team to accomplish the collision rule and does just that. But, the "scoreboard teams option" for said team keeps getting reset with the server and it's problematic for 1 specific team option. I have an anti-cheat with floating player entities and the "seeFriendlyInvisibles" settings for teams defaults to "true" when this team is generated or regenerated after each reset. This is not vanilla behavior and (1) Ruins PvP/Survival invis potions when the entire server is on the same team and (2) makes the floating players visible 24/7 in my case.

I personally solved this by running a scheduled task after every server restart to set my collide team's "seeFriendlyInvisibles" to false, but I think this is worth a report and perm fix or config option.

All the other options default to vanilla behavior (friendlyfire, Nametagvisibility, etc) but each time the server resets, it takes off my manually set option for seeing friendly invisibles.

Request is to have that set to mimic vanilla behavior (false) or add configurable collide team options in the paper.yml. Another path is to make it not reset the options, but I figured you would want to make the default = vanilla gameplay.

Thank you :)

[zachbr]

The entire thing is a massive workaround, but you setting additional properties on the collideRule team is NOT recommended or supported.

It is intentionally created and deleted per-run.

What you should do instead is to create your own separate team with the options you want, then move them over to that team. As the collideRule team only exists to set the basic collide rule for players who would normally NOT be on a team.

If they're already on a team, they will not be added to the collide rule team, and their collision setting will already be handled.

[AlfieC]

I personally disagree with @Zbob750 - any Paper side patches should make an effort to replicate as much vanilla behavior as possible. Therefore I believe that seeFriendlyInvisibles should be set to false. Or, add each player to their own collide-rule team.

[zachbr]

The only thing that team does is set players not to collide with each other, it does not touch any other gamrule. I'm still confused as to how that breaks vanilla in anyway

Feel free to consult the source code.

[AlfieC]

Pretty sure that default Craftbukkit behavior sets seeFriendlyInvisibles to true when creating a new team.

[zachbr]

Then this issue is invalid. Will check later.

EDIT: read as vanilla, not CB.
Will fix to match whatever Vanilla does.

editedit: hah you did say that, caught your edit! :)

[CeIebrimbor]

Idk why the default is seeing friendly invisibles, but the issue it is that Paper keeps resetting it and the default ruins vanilla behavior. I had in the past made my own team and added players manually but Paper build in is far cleaner :)

I'd be ok if Paper didn't reset the team at each restart. That way I set the option once and it's good.

[CeIebrimbor]

Just wanted to throw this out there. While the team is vanilla, seeing all invisible players on the entire because of Paper is not fun...

[zachbr]

Will have to find where CB is doing that and make it not. Because we don't touch that ._.

[AlfieC]

@Zbob750 edited like 10 seconds after ;)

Default NMS teams I believe are seeFriendlyInvisibles = true but Craftbukkit teams are not (as far as I know).

EDIT: disregard that last message. I think that plugin authors and people who work with NMS code will be familiar with this behavior as standard and that the quick fix will be to just set seeFriendlyInvisibles as false in this one instance.

[zachbr]

Craftbukkit teams are unrelated, entirely different system. NMS behavior does appear to be to have that default to true. So Paper is absolutely following vanilla behavior.

Will have to make up my mind as to whether I allow people to override and make the team persistent, though I don't really want to.

[AlfieC]

Making the team persistent wouldn't really change much, to be honest. We can even make it a config sub-option to decide if operators WANT to be able to see friendly invisibles.

[zachbr]

Why on earth would we do that. At that point you'd just be adding toggles for ever game rule, except they'd be specific to that one team.

The entire point was simplicity, that because of the way Mojang screwed up and made collisions client side and in order to fix it, we'd have to send a scoreboard team and keep players on that. We wanted to make a blanket "DEFAULT" team that the server would automatically throw people on that was entirely vanilla save for this one thing.

If you make your own team manually, it will still adhere to Paper's collide setting, the only reason this team exists is to initialize that setting for players that don't have a team. Advanced configuration should just be left to creating your own team.

[CeIebrimbor]

I don't want customization. If I want that I'll go back to handjamming my own custom team setup. It got the job done. :p

Just bringing up the fact the Paper's team makes invisibility shot. If it's a no to providing a tweak, whatever the reason may be, I'll go do my own thing and you should remove the feature that manipulates gameplay outside of cancelling collisions.

I know this all goes without saying. Just putting it out there when I hear things like I'll think about it or when my report is labeled "opinion".

[AlfieC]

@Zbob750 but, without your collide rule; players cannot see invisibles. That's because players aren't on any team - so are on their own team and such HAVE no friendlies to see. That's why seeFriendlyInvisibles should be false - this replicates vanilla behavior even though the default is true.

[zachbr]

That is a good point. I will change the flag for this team, apply it globally, and block further customization entirely.

[CeIebrimbor]

This is why Paper is awesome ...Stuff like this can be talked about.

[zachbr]

@CeIebrimbor testing locally now, sorry I just wasn't quite understanding what you meant. @AlfieC spelled it out nice and clear (to me) and I immediately got it.

[CeIebrimbor]

Literacy is not my first language.

[AlfieC]

@Zbob750 why do you need to block further customization? And of what? The seeFriendlyInvisibles, or the player collisions?

edit: clarified

[zachbr]

Setting further (or any) options on the team.
It prevents people from thinking they can treat the collideRule team as normal, persistent, team.
It isn't persistent, so that the config variable can be used to enable or disable it more easily, or they can change out jars without Paper leaving behind a team.

Edit: actually specify.

The only reason this 'team' exists is because Mojang forced it to. In an ideal world, it wouldn't exist and this would be a simple return line on the server. So I'd like to try and keep it focused around a "server-side setting" rather than a true function team.

[zachbr]

Forgot to tag the commit with the issue name.
Should be fixed in 14c974629c1ed1e0faaa3490996a930a63f2a842
Builds 865+