Add PlayerLandEvent

[StillLutto]

Description

This is a very simple event. This event is triggered whenever a player lands on a block. The event is mostly useful for when you want to do a specific action whenever a player lands on a specific block/location.

Event Details

Event Name: PlayerLandEvent
Trigger: When a player lands on the ground
Purpose: To allow players to do specific actions when a player lands on a specific block

Key Components

Player: The player that landed.
From: The location the player landed from.
To: The location the player landed to.
Main Supporting Block: The main block supporting the player, the block that the player landed on.

[Owen1212055]

What is up with setting the player's ground value here? As this is technically changing behavior?

[StillLutto]

The reason I set the ground value here is because that method runs checkSupportingBlock() which updates Entity#mainSupportingBlockPos. The reason I'm not just taking advantage of this.player.setOnGroundWithKnownMovement() which happens just a few lines below is because I previously made this event cancellable, But after further testing, it had pretty buggy behaviour... I'm going to quickly just move this below the this.player.setOnGroundWithKnownMovement() in the next commit.

[notTamion]

use fully qualified imports when using a class not very often.

[StillLutto]

Fair, will change.

[NonSwag]

Change my mind, but isn't this just the player toggle flight event with extra conditions
Wouldn't exposing the main supporting block method from NMS be smarter?

[StillLutto]

@NonSwag Whilst first looking how to do this in my own plugin, I saw that the best to check when a player lands, is to use a PlayerMoveEvent. The onGround boolean is, from what I understand, pretty unreliable. Thus, you will have to use a bit of NMS there to make it work. Furthermore, you will probably also need the mainSupportingBlock, which is added nms, and if you want the from and to location... Well, you get the point. This event is basically here to avoid this overhead. Now I'm going to be honest, I don't know if your method works, but if it does, all this nms will still be needed. It's definitely not that big of a problem, but the main idea is to avoid this. So make your own informed decision off of this.

[Brokkonaut]

isOnGround is exactly as reliable as your new event, because that is everything the server knows about the players on ground state. And adding api to get the mainSupportingBlock for the player should be easy and unproblematic.

[notTamion]

there is already an pr open which exposes that iirc

[lynxplay]

mainSupportingBlock iirc was dropped because of how funky movement is as, at the time PlayerMoveEvent e.g. is called, the supporting block is temporarily AIR until the server recomputes it right after.

[notTamion]

yeah. if someone finds a solution for it in #9298 then that won‘t be a problem anymore

[StillLutto]

If you think this doesn't need to be added, you can close this post. I think onGround is not set right when 'PlayerMoveEvent` gets called, thus some nms there is still needed. Anyway, feel free to close this now.

[NonSwag]

isOnGround is sent with the movement packet so in theory it could be added to the movement event
It is unreliable but still a part of the protocol so having it added would be a benefit
For example anti cheats could make use of it instead of using nms
Also Player#isOnGround is not required to be called which is not even up to date within the event
Maybe an annotation to warn about it's unreliability and not deprecating it would be appropriate
Same with the isOnGround method

[StillLutto]

Again, feel free to close this if you think it's not worth adding