Solved Freezing The Player

Hello!

I've tried to freeze the player using potion effects but I can get them to work. Heres my code;

player.addPotionEffect(new PotionEffect(PotionEffectType.JUMP, 9999*9999, -1));
player.addPotionEffect(new PotionEffect(PotionEffectType.SLOW, 9999*9999, -1));

I've applied an amplifier of -1 hoping this would stop the player from moving and jumping. Anyone got any ideas on why this doesn't work?

 

Rather than adding a potion try using an event listener like PlayerMoveEvent. If they move while you're "Freezing" them could teleport them back to where they were before the moved.

 

Set it high instead of low.

 

I have a plugin to freeze players but i do it by teleporting them back to the same place when they try to move. In a listener class, put the following:

Code:java

@EventHandler()
public void onPlayerMove(PlayerMoveEvent event) {
    Player player = event.getPlayer();
    Location location = player.getLocation();
    player.teleport(location);
}
 

Hope that helps. PM me for any more help!

 

You might also try listening for the playermoveevent and doing setCancelled(true);

 

That's a god awful idea.

I'm dead serious. Never cancel onPlayerMove.

Create a List<UUID> or List<String> object that holds UUIDs/Player Names, and if onPlayerMoveEvent, the player that moved's UUID or name matches one in the List object, teleport the player to event.getFrom().

 

Wow thanks for the responses! I have tried teleporting the player but it seams rather laggy, as you know I have also tried giving the players potion effects but I fear that players will find a way to move; spamming jump and holding forward as an example. Ultimately I think I'm just going to have to spawn glass blocks around the players and then remove them when the game starts

 

Yes, that'd be the best method for it if you can do it.
There's some really big threads on bukkit about this, and the less laggy and still functional solution seemed to be:

Give the player maximum slowness and jump height.
Cancel their sprint event. (Otherwise they can move a little while sprint-jumping)
Cancel when they try to drink milk. (otherwise the potion effects can be removed)

 

And I'm serious: never teleport the player inside a move event - it just fires another move event and potentially gets the player kicked ("moving too quickly"). If you need to modify the player's destination, use event.setTo().

Either way though, it'll look bad on the client; you'll get jitters because the client doesn't know that the server has modified the movement right away. The best way is to do as Bobit suggested.

 

While we're on the subject, I'll ask this question since I'm going to need it answered eventually:

How would you prevent the player from doing anything except looking around? (No commands, charging a bow, breaking blocks, or anything at all)

 

Bobit You'd need to cancel the relevant events.

 

AdamQpzm
There's too many of them! D:
Yeah, I guess so. That sounds really, really laggy though, doesn't it?
Also, there is no bowChargeEvent, only bowShootEvent.

 

Bobit PlayerInteractEvent has got you covered for that. As for the lag, I wouldn't imagine so. The events are called regardless of whether or not you're listening to them or not. As long as you don't deliberately try to be wasteful with them, it should be fine.

 

AdamQpzm
Do you know which events, like playerMoveEvent, if cancelled, will just be called again infinitely?

 

Bobit Afaik, none of them. I don't believe PlayerMoveEvent does this if you cancel it, only if you move them.

 

Why not?
Clearly it's ugly client-side. Many people have reported this. Are there other events that cancelling them would have a similar effect?

 

Bobit For a start it looks horrible on the client's side. And it also fires for turning so simply cancelling it will prevent them from even doing that much, which most people don't actually want, especially since it's not a smooth cancellation.

To really see what I mean, make a quick test plugin when you cancel any and all movement, join your test server, and move your mouse in one direction really quickly. I pretty much guarantee you won't like it. Extra points for super high sensitivity.

 

AdamQpzm
I read that before. Are there any events that are known to be just as ugly when cancelled?

 

It's very easy to distinguish between turning and moving, given that the event gives you both the player's from and to positions.

But there's no "clean" way of preventing movement with the PlayerMoveEvent without causing client-side jitters - by the time the server gets the packet (PlayerPositionAndLook) and has notified plugins, the client has already updated its idea of the player's position. Cancelling the event (or using the setTo() method) effectively forces the sending of a new packet to the client to force another position update.

Bobit that's about the only case where cancelling an event is quite so obviously jarring. There are a few more minor cases, e.g. cancelling a mouse wheel event (PlayerItemHeldEvent) will cause the server to send an extra packet, and you'll see the selected item in the hotbar jump around a bit.

 

Bobit Hmm. Inventory events have never really played too nicely with cancellation, but they're not so bad when you think of PlayerMoveEvent, and updateInventory() is useful. I can't think of any other event you'd want to watch out for really, but I'm sure there might be something.

Last second thought: I remember that PlayerDeathEvent can result in a weird glitch where the player is alive but they look dead if you cancel it. I'm not sure if it's fixed or not, but I don't suppose it would matter if you intend to cancel the damage event.

desht I know, that's why I said that 'simply' cancelling the event

 

The Non lagy way of doing it would be something lile:

Code:java

if (MathUtils.distance(event.getFrom(), event.getTo()) <= 0.0D) {
            return;
        }
        event.getFrom().setPitch(event.getTo().getPitch());
        event.getFrom().setYaw(event.getTo().getYaw());
 
        event.setTo(event.getFrom());

Off couse MathUtils.distance is calculating the distance only.

 

If this is for a hunger games server, that makes sense. But for anything else, you'll endup deleting glass that was placed by other players!

 

I think the barrier blocks coming in 1.8 will make all this very much easier. Should just be a matter of surrounding or encasing the player in a barrier to prevent any kind of movement.

 

Well, yeah, but there's still the problem of potentially removing blocks such as levers or carpets. The way I found is still best in most cases, despite the possible lag.

 

DevRosemberg I'm pretty sure that applying two simple potion effects would be less laggy than that, although I'm not saying it'd be noticeable.

 

Two things I don't understand about this:

1. It's not two simple potion effects, you also have to cancel drinking milk and toggling sprint.
2. It would be pretty significant for players that are trying to move if they had a low ping.

 

I would not rely too much on potion effects or Minecraft blocks for a public server, unless it is proven that Minecraft really prevents things (which is very unlikely). Cheaters just can walk off the spot, unless you have another plugin enforcing the moving speeds. For freezing "legit" players, "Minecraft game dynamics" might be pretty ok.

The cleanest way might be to store the freezing location and monitor the player move event, and to allow turning while within margin. For players who go outside of the margin you use setTo with the yaw and pitch of the getTo Location but coordinates of the freezing location, in order to allow at least jitterish turning. In addion you might schedule a checking task, which uses teleporting in case the player manages to get somewhere (currently they might exploit the first move after login for teleport/vclip, unless they fixed that on server side). Still a slight problem can be if the player is in not on ground.

 

Won't that still cause significant lag?

 

Of course. And it is not the "cleanest way". My point is if you want to freeze cheaters too, the potion effects probably will not have too much of an effect.

For a mixture you could actually store the freezing location and apply some potion effects or whatever, to slow them down - when they are outside of a certain margin around the freezing location, you teleport them back (setTo for moving events). That way they would need a while to get set-back, and you would have them confined more reliably. You could also leave out the milk drinking checking, if you just re-apply the potion effect on setting back, but naturally you have a lot of options to alter things slightly here.

If you just want to have a smooth user experience without dealing with cheaters abusing it, then leave out the setting back...

 

So which would be less laggy:
Teleporting them back every tick...
Or checking if they're outside the margin, and if so teleporting them back?