(Open Source) Optimised Move - 7 new events - More optimised version of PlayerMoveEvent

[Cole]

​

 

[Ghast]

THANK YOU!

 

[Killstreak702]

How the fuck is this "optimized" if it's just listening on PlayerMoveEvent? All it does is call events for certain conditions. This has to be the most useless API ever. Using this will just increase server load and the amount of events called and won't do anything else.

 

[Cole]

How the fuck is this "optimized" if it's just listening on PlayerMoveEvent? All it does is call events for certain conditions. This has to be the most useless API ever. Using this will just increase server load and the amount of events called and won't do anything else.

It's way better then checking something on PlayerMoveEvent

Example: Someone moves to a different claim from PlayerMoveEvent and it checks that every time on aim
Using PlayerBlockChangeEvent: You can check it only on block change

 

[Ghast]

How the fuck is this "optimized" if it's just listening on PlayerMoveEvent? All it does is call events for certain conditions. This has to be the most useless API ever. Using this will just increase server load and the amount of events called and won't do anything else.

I have to agree on the missuse of the term “Optimized”. The point of this api is to have more detailed events for anticheats etc...

 

[Killstreak702]

It's way better then checking something on PlayerMoveEvent

Example: Someone moves to a different claim from PlayerMoveEvent and it checks that every time on aim
Using PlayerBlockChangeEvent: You can check it only on block change

Oh boy, here we go...

Let's say I have this code:

@EventHandler
private fun procMove(e: PlayerMoveEvent) {
  if (e.to.blockY > e.from.blockY) {
    e.player.sendMessage("ur now at ${e.to.blockY} yeet")
  }
}

We're checking if a player moves upwards to a different block.

Now, here's your method that handles PlayerMoveEvent:

@EventHandler
    public void onMove(org.bukkit.event.player.PlayerMoveEvent e) {
        Location from = e.getFrom();
        Location to = e.getTo();
        Player player = e.getPlayer();

        if (from.getYaw() != to.getYaw()) {
            Bukkit.getServer().getPluginManager().callEvent(new PlayerYawChangeEvent(player, from, to));
            Bukkit.getServer().getPluginManager().callEvent(new PlayerAimChangeEvent(player, from, to));
        }

        if (from.getPitch() != to.getPitch()) {
            Bukkit.getServer().getPluginManager().callEvent(new PlayerPitchChangeEvent(player, from, to));
            Bukkit.getServer().getPluginManager().callEvent(new PlayerAimChangeEvent(player, from, to));
        }

        if (from.getX() != to.getX()) {
            Bukkit.getServer().getPluginManager().callEvent(new PlayerXChangeEvent(player, from, to));
            Bukkit.getServer().getPluginManager().callEvent(new PlayerBlockChangeEvent(player, from, to));
        }

        if (from.getY() != to.getY()) {
            Bukkit.getServer().getPluginManager().callEvent(new PlayerYChangeEvent(player, from, to));
            Bukkit.getServer().getPluginManager().callEvent(new PlayerBlockChangeEvent(player, from, to));
        }

        if (from.getZ() != to.getZ()) {
            Bukkit.getServer().getPluginManager().callEvent(new PlayerZChangeEvent(player, from, to));
            Bukkit.getServer().getPluginManager().callEvent(new PlayerBlockChangeEvent(player, from, to));
        }
}

Now as you can see, we're firing 10 events per PlayerMoveEvent call.

If I had multiple events of my event with different computations, it would still be more efficient to do the same computation multiple times for each of my events than to use 5 if statements and fire 10 events. Even if we only had a specific event (say for moving up in Y) it'd still be more efficient to do the computation ourselves in PlayerMoveEvent. Keep in mind that Bukkit also has to actually handle your 10 events and fire them all at once, for each PlayerMoveEvent. If we had 100 players on, I'm sure there'd be hundreds of these being fired in half a second.

When an if statement is used in this case, the CPU simply puts the first value into one register, the second into another, and puts the result in a third - basically just comparing bits when you make the process sound simple - which is what the CPU does. Keep in mind that registers are about 100x faster than RAM, and I'm pretty sure they cache values so it can do comparisons extremely fast.

So in this case, it'd be easier to use your event if you had multiple events for the same thing - but we know that using one PlayerMoveEvent and doing the same computation would always be more efficient compared to firing 10 events on one PlayerMoveEvent.

TLDR - it's more simple to use this if you have lots of events, but otherwise it is more inefficient[DOUBLEPOST=1558865020][/DOUBLEPOST]

I have to agree on the missuse of the term “Optimized”. The point of this api is to have more detailed events for anticheats etc...

It's good to have more detailed events. I think a much better way of achieving this would be to use Kotlin to add extension methods to PlayerMoveEvent itself, functions like: hasRotationChanged, hasPositionChanged, hasXChanged, etc.

 

[Cole]

Oh boy, here we go...

Let's say I have this code:

@EventHandler
private fun procMove(e: PlayerMoveEvent) {
  if (e.to.blockY > e.from.blockY) {
    e.player.sendMessage("ur now at ${e.to.blockY} yeet")
  }
}

We're checking if a player moves upwards to a different block.

Now, here's your method that handles PlayerMoveEvent:

@EventHandler
    public void onMove(org.bukkit.event.player.PlayerMoveEvent e) {
        Location from = e.getFrom();
        Location to = e.getTo();
        Player player = e.getPlayer();

        if (from.getYaw() != to.getYaw()) {
            Bukkit.getServer().getPluginManager().callEvent(new PlayerYawChangeEvent(player, from, to));
            Bukkit.getServer().getPluginManager().callEvent(new PlayerAimChangeEvent(player, from, to));
        }

        if (from.getPitch() != to.getPitch()) {
            Bukkit.getServer().getPluginManager().callEvent(new PlayerPitchChangeEvent(player, from, to));
            Bukkit.getServer().getPluginManager().callEvent(new PlayerAimChangeEvent(player, from, to));
        }

        if (from.getX() != to.getX()) {
            Bukkit.getServer().getPluginManager().callEvent(new PlayerXChangeEvent(player, from, to));
            Bukkit.getServer().getPluginManager().callEvent(new PlayerBlockChangeEvent(player, from, to));
        }

        if (from.getY() != to.getY()) {
            Bukkit.getServer().getPluginManager().callEvent(new PlayerYChangeEvent(player, from, to));
            Bukkit.getServer().getPluginManager().callEvent(new PlayerBlockChangeEvent(player, from, to));
        }

        if (from.getZ() != to.getZ()) {
            Bukkit.getServer().getPluginManager().callEvent(new PlayerZChangeEvent(player, from, to));
            Bukkit.getServer().getPluginManager().callEvent(new PlayerBlockChangeEvent(player, from, to));
        }
}

Now as you can see, we're firing 10 events per PlayerMoveEvent call.

If I had multiple events of my event with different computations, it would still be more efficient to do the same computation multiple times for each of my events than to use 5 if statements and fire 10 events. Even if we only had a specific event (say for moving up in Y) it'd still be more efficient to do the computation ourselves in PlayerMoveEvent. Keep in mind that Bukkit also has to actually handle your 10 events and fire them all at once, for each PlayerMoveEvent. If we had 100 players on, I'm sure there'd be hundreds of these being fired in half a second.

When an if statement is used in this case, the CPU simply puts the first value into one register, the second into another, and puts the result in a third - basically just comparing bits when you make the process sound simple - which is what the CPU does. Keep in mind that registers are about 100x faster than RAM, and I'm pretty sure they cache values so it can do comparisons extremely fast.

So in this case, it'd be easier to use your event if you had multiple events for the same thing - but we know that using one PlayerMoveEvent and doing the same computation would always be more efficient compared to firing 10 events on one PlayerMoveEvent.

TLDR - it's more simple to use this if you have lots of events, but otherwise it is more inefficient[DOUBLEPOST=1558865020][/DOUBLEPOST]
It's good to have more detailed events. I think a much better way of achieving this would be to use Kotlin to add extension methods to PlayerMoveEvent itself, functions like: hasRotationChanged, hasPositionChanged, hasXChanged, etc.

This makes sense, I'm looking at improving this a lot in general.

 

[Killstreak702]

This makes sense, I'm looking at improving this a lot in general.

I personally would just add extension functions using Kotlin, that's probably the easiest and best way to go that doesn't require poking into Spigot itself

Kotlin extension functions in a nutshell: