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

Teleport limiting #51

Open
Phoenix616 opened this issue Jun 1, 2019 · 8 comments
Open

Teleport limiting #51

Phoenix616 opened this issue Jun 1, 2019 · 8 comments

Comments

@Phoenix616
Copy link

Currently there is no limit to the amount of blocks a player can teleport by send the TELEPORT plugin message to the server nor is there a check if the player could actually reach the point. (e.g. you can teleport to places you couldn't walk normally or even teleport through walls)

A simple start for limiting this would be to add a config option for the maximum distance a player can teleport (ideally that would be communicated to the mod too), a more advanced one would be to check for walls in the path or even calculate if the player could walk there (via a pathfinder).

@Techjar
Copy link
Collaborator

Techjar commented Jun 1, 2019

We'll fix it when someone actually exploits it on a major server.

@Techjar
Copy link
Collaborator

Techjar commented Jun 1, 2019

It's not an easy thing to fix. A simple distance check wouldn't really solve anything, and path checks are not only complicated, but would conflict with how teleport works on the client-side, resulting in rubber-banding.

@Phoenix616
Copy link
Author

with how teleport works on the client-side, resulting in rubber-banding.

That makes it sound like the client will just teleport the viewpoint without waiting for the server's response on whether or not the teleport completed properly? If so then that would need to be changed to wait for the teleport packet to actually reach the client again before teleporting it. I guess that could lead to some very small delay in teleporting (depending on your ping) but I feel like that would not as big of an issue and easily masked even by a very short transition animation.

@Techjar
Copy link
Collaborator

Techjar commented Jun 1, 2019

What I mean is teleports that are possible on the client won't be seen as possible on the server. The rules are totally different. There really is no good way to fix this.

@Phoenix616
Copy link
Author

Phoenix616 commented Jun 1, 2019

All hitboxes of blocks can be calculated serverside and teleport targets adjusted accordingly if that would be the goal. Also if the client waits on the server to teleport then teleporting the player to a different location than the one he wanted to shouldn't be as big of an issue as long as the resulting location is still in line with the one targeted originally.

Of course ideally the server would provide the player with some kind of indicator whether or not a teleport is valid or not before hand or simply not allow teleporting to invalid locations. (Could also be a player choice to allow approximative teleports or simple not teleport to invalid ones)

@Techjar
Copy link
Collaborator

Techjar commented Jun 1, 2019

I guess you're just not understanding what I'm getting at. :/

@Phoenix616
Copy link
Author

I do: You think that it would be an issue that the player doesn't teleport to exactly where he wanted to on the client.

What I'm saying is that this is something that could be properly calculated by the server (so that it too knows which teleports seem possible on the client and which not) or to add a mechanic that blocks impossible teleports in a way that aren't too much of an annoyance to the players e.g. by indicating impossible teleports beforehand or by only teleporting to the best possible location along the sight-line (should be enough to avoid any motion sickness that would arise due to teleporting to an unexpected location)

@Techjar
Copy link
Collaborator

Techjar commented Jun 1, 2019

I give up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants