Paper: Add method Player#setAllowClipping(boolean) and Player#getAllowClipping()

[Blazzike]

Describe the solution you'd like
For the method Player#setAllowClipping(boolean) to be added to set if checking for block collisions should be enabled.

Describe alternatives you've considered
Making the user spectator then cancelling the gamemode update packet. But spectator isn't a solution... at all.

[MicleBrick]

Why clipping and not collisions

[aikar]

Because clipping and collisions are 2 very different things.

[Blazzike]

What I'd like to do is allow players to walk through blocks without the server saying "That shouldn't be possible". This is so we can send the packet to open a door/gate but have it closed to the server, to allow the player to walk through as usual with no world modification.

[aikar]

I think you'll only be able to do that by sending the spectator gamemode to client.

[Blazzike]

electroniccat informed me that a Player instance in NMS has a "noclip" boolean, which disables these checks. I think I might be able to do it by updating their gamemode to spectator then cancelling the packet to the player but spectator is slightly more than just collisions (flight).

[MicleBrick]

Nobody knows if he's a cat or a boy

[electronicboy]

There is a boolean in the server for it, but given that the client also attempts to check stuff like collisions, there is a good chance that the client will only have anything to gain from disabling such a state on the server when the client is in a specific mode, e.g. spectator (which, was the only way that I could see that that field would be set by the server)

[Blazzike]

Hey electronicboy. Please take a look at my use case: https://github.com/PaperMC/Paper/issues/1330#issuecomment-415988505.

To the client, the gate/door will be open.

[BillyGalbreath]

If you enable the noclip field on a Player they fall through the ground into the void..

[MicleBrick]

not if you disable gravity

[BillyGalbreath]

not if you disable gravity

Then what happens when a player jumps? Remember, they don't have flight controls because they are not in spectate mode. ;)

[MicleBrick]

Set them to flying

[BillyGalbreath]

Set them to flying

Then why not just set them into spectate mode?

[MicleBrick]

Then they can tp to people, be invisible, do lots of other things

[BillyGalbreath]

Then try it and see what you think. The field _is_ public, afterall.

((CraftPlayer) player).getHandle().noclip = true;

Just be sure you keep setting it every. single. tick. Because the server itself is also setting this field every. single. tick.

Edit:

Actually, I just tried it so I could make a video of how wonky this idea is, and I learned that setting noclip to true does absolutely nothing. The client still has it's own noclip field which it knows is set to false unless is spectator gamemode. So, this idea isn't just wonky, it's impossible.

[Blazzike]

Right. Because the client won't fall through the floor as it has its own clip detection. Which is why it would be great to have a method to modify the tick based on that then otherwise spectator. I could have the plugin change it back after every tick but... really? Is that my best option?

[BillyGalbreath]

Right. Because the client won't fall through the floor as it has its own clip detection. Which is why it would be great to have a method to modify the tick based on that then otherwise spectator. I could have the plugin change it back after every tick but... really? Is that my best option?

See my edit above. Setting the noclip flag on the server does nothing. What you are asking for is impossible. We could set it all day long, but the client will not let a player walk through walls or the floor because its own noclip field is set to false. The only way we have to change that field on the client is by entering spectator mode.

[Blazzike]

Thanks for your input, but I don't think I explained myself well enough. So I'll try again.

What we're trying to do is have the player open a gate but on the server cancel the open gate but not send the packet back to the client to to correct the opening.

So for the client: All that has happened is the client has opened the gate.
For the server: The world has been left unmodified, the gate is not open.

However, if the client tries to step through the gate, the server says "Uh... No, you can't walk through a solid block. I'll move you back to where you should be." and the client is left in a glitchy state of trying to pass through what it thinks is an open gate.

So what we want is the following: The client opens the gate but the world is unmodified, the client can walk through the gate like normal.

Obviously, this would apply to gates, doors and trap doors. Any input is appreciated! :D - and sorry for the confusion.

[BillyGalbreath]

Have you tried setting the noclip field to true in a 1 tick repeating task? I mean, it might not even work.

[Mystiflow]

I'm pretty sure the client controls all collisions through blocks, and therefore if you tried sending a fake send block packet (for updating client GUI) with the open gate data, that would update the status of gate on client and allow you to walk through the open gate which is not what you desire.
Anyone can correct me if I'm wrong though.

and the client is left in a glitchy state of trying to pass through what it thinks is an open gate.
PlayerMoveEvent?

[Blazzike]

I haven't @BillyGalbreath I'm sure it would work, not sure how to get the timing exactly right on that but it would be nice to have a more... intergrated solution.

@Mystiflow - Sadly, but also glady not. The server has its own clipping detection. Probably to prevent modified clients but also just as a backup I guess. :P The server's clipping detection obviously is done through setting the player's location so it results in a somewhat buggy state.

[electronicboy]

This would likely need to be implemented in some form of enum from what I can see, ON, SERVER, OFF; where SERVER would represent that the server is in control, I'm somewhat unsure on SERVER, but this is an API that would last a good while, and we can't be sure that it's not going to change down the line; I am somewhat iffy on this being added, but I can see use cases for it, especially if the client allows there to remain some level of sanity

[Mystiflow]

@Blazzike ah I see. In that case I suggest using a custom Paper fork.

Perhaps this could work?

• Run a code usage search for noclip var and see where it does the detections for closed gate clipping
• Make a flag to allow the clip detection to perform for open gates too.
• In the tick() method, edit the updating of the noclip var to also check for your flag.

This is just a theory I haven't looked in the nms code yet.

[zachbr]

I'm pretty iffy on adding an API that is based entirely around the client and server getting out of sync on the player's abilities. Especially something kind of hacky like this.

[Blazzike]

@electronicboy Yeah, that could work.
@Mystiflow I'm sure that would work too, but I'm not that invested in this feature.
@zachbr True, but so is Player#sendBlockChange (or whatever the method is).

[Mystiflow]

@zachbr could always deprecate the API methods and state the cautions of using them in the javadocs (subject to change, possible sync issues)

[zachbr]

I don't consider adding a hacky API just to mark it as deprecated and document it as "this can change, not supported, might break, probably won't sync blah blah blah" a good idea.

That sort thing belongs in NMS. Short of anyone else on the team fighting strongly for this API, I'd like to see this ticket closed as wontfix.

[MicleBrick]

I suggest using @mikroskeem 's Orion and mixins rather than a paper fork tho, less work to maintain

[zachbr]

Thanks for trying here, you found something missing and started a discussion.
As it stands, this is just not suitable as an API with its current constraints.