Skip to content

Remove spectator players' cameras when teleporting #13478

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.

Sign up for GitHub

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

Open
lucyydotp wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Remove spectator players' cameras when teleporting #13478

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
4cd15c0
Remove spectator players' cameras when teleporting
lucyydotp Dec 31, 2025
14a87a5
Remove unneeded boundary comments, check for any non-self camera
lucyydotp Dec 31, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 17 additions & 1 deletion paper-server/src/main/java/org/bukkit/craftbukkit/entity/CraftPlayer.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1317,7 +1317,23 @@ protected boolean teleport0(Location location, org.bukkit.event.player.PlayerTel
return false;
}

return super.teleport0(location, cause, flags);
// Paper start - stop spectating other entities on teleport
// return super.teleport0(location, cause, flags);
Comment thread
lucyydotp marked this conversation as resolved.
Outdated
// Attempt to set the camera first
Entity camera = this.getHandle().getCamera();
this.getHandle().setCamera(null);
Copy link
Copy Markdown
Member

@Owen1212055 Owen1212055 Jan 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like in most cases (except one) where camera is reset it uses setCamera(self), so you may want to setCamera(this.getHandle())

if (camera != this.getHandle() && camera == this.getHandle().getCamera()) {
Copy link
Copy Markdown
Contributor

@masmc05 masmc05 Dec 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If an event changes the camera to a different new entity the teleport will still be broken, not sure but I think for any spectated entity you should cancel the teleport

Copy link
Copy Markdown
Member

@Doc94 Doc94 Dec 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think this can just be replaced with the this.getHandle().setCamera(this.getHandle());
i test for example the cancel teleport event and is not broken if you update the camera.

Copy link
Copy Markdown
Author

@lucyydotp lucyydotp Dec 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, I'll change that to check for any entity.

i think this can just be replaced with the this.getHandle().setCamera(this.getHandle()); i test for example the cancel teleport event and is not broken if you update the camera.

Would that not still change the camera even if the teleport is cancelled?

Copy link
Copy Markdown
Author

@lucyydotp lucyydotp Dec 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, how can the event change the camera? PlayerStopSpectatingEntityEvent is immutable, except for being cancellable. I'll update the check regardless but I don't think it will meaningfully change the behaviour

Copy link
Copy Markdown
Member

@Doc94 Doc94 Dec 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, I'll change that to check for any entity.

i think this can just be replaced with the this.getHandle().setCamera(this.getHandle()); i test for example the cancel teleport event and is not broken if you update the camera.

Would that not still change the camera even if the teleport is cancelled?

In teory but maybe the cancel state already manage that, like say you can test that behaviour but i dont find issue in cancel with the setCamera called

Copy link
Copy Markdown
Member

@Doc94 Doc94 Dec 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ref: Doc94@0661918

Copy link
Copy Markdown
Author

@lucyydotp lucyydotp Dec 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ref: Doc94@0661918

This breaks for me:

  • Cancelling PlayerStopSpectatingEntityEvent lets the broken teleport happen
  • Cancelling PlayerTeleportEvent kicks me off the entity I'm spectating without teleporting me anywhere

Copy link
Copy Markdown
Member

@Doc94 Doc94 Dec 31, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ref: Doc94@0661918

This breaks for me:

  • Cancelling PlayerStopSpectatingEntityEvent lets the broken teleport happen
  • Cancelling PlayerTeleportEvent kicks me off the entity I'm spectating without teleporting me anywhere

that two then also happen using teleport command and mess with events too no?

for the PlayerTeleportEvent make sense because first dismount/cancel-spect and then teleport then i feel its expected
for PlayerStopSpectatingEntityEvent then can be good check if this and then teleport (like if the camera really change later or make the camera return a bool)

Copy link
Copy Markdown
Author

@lucyydotp lucyydotp Dec 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh that's a very good point actually, I hadn't considered that. I don't think that behaviour makes much sense regardless of where it's coming from - potentially another paper bug? ServerPlayer#teleportTo has a setCamera param which does the same as this PR but doesn't check for event cancellation, would it be worth me patching that too while I'm there?

Copy link
Copy Markdown
Member

@Doc94 Doc94 Dec 31, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm im calling the expert in teleportations thing here... @Owen1212055
but i think just fix the api method with the camera can be ok?

// If the camera hasn't changed, it was likely cancelled by an event, so stop the teleport
return false;
}
Comment on lines +1322 to +1325
Copy link
Copy Markdown
Member

@Owen1212055 Owen1212055 Jan 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This kind of prompts additional conversation, but we may want to instead just have some kind of boolean on the set camera to ignore the canceling of those events. As there is a lot of places where this can occur and I don't really think we handle this logic at all (and instead just allow them to be teleported back a tick later or whatever)


boolean teleported = super.teleport0(location, cause, flags);
if (!teleported) {
// If the teleport doesn't go through, restore the original camera
this.getHandle().setCamera(camera);
}
return teleported;
// Paper end - stop spectating other entities on teleport
}

@Override
Expand Down
Loading