Feat(API): Mutable Location in PlayerTeleportToPlotEvent

[PierreSchwang]

Overview

In case of some more abstract plot layouts (e.g. floating balloons in the sky), the event now provides the ability to set the location for any teleport programmatically.

Example:

@Subscribe
public void scootRightOver(PlayerTeleportToPlotEvent event) {
    if (event.getCause() == TeleportCause.COMMAND_HOME) {
        event.setLocation(event.getLocation().add(-15, 0, 0));
    }
}

I did not deprecate the constructor nor the event dispatcher method itself. Events should not be called by end-users either way. If no location is passed, weird behavior can occur when trying to mutate the original location (which is null in case of those deprecated methods)

Submitter Checklist

Beta Give feedback

1. Make sure you are opening from a topic branch (/feature/fix/docs/ branch (right side)) and not your main branch.
2. Ensure that the pull request title represents the desired changelog entry.
3. New public fields and methods are annotated with @since TODO.
4. I read and followed the contribution guidelines.

[dordsor21]

I wonder if two events for teleport would be better. If the event is cancelled it would be good to not search for a location and possibly load chunks needlessly. Perhaps add a new "PlayerTeleportToPlotLocationChosenEvent" :D

[PierreSchwang]

I wonder if two events for teleport would be better. If the event is cancelled it would be good to not search for a location and possibly load chunks needlessly. Perhaps add a new "PlayerTeleportToPlotLocationChosenEvent" :D

I may have an idea to mitigate that issue. Tbh, I'm not that big of a fan for an additional event (especially with that very java-ish name :D)

[PierreSchwang]

I wonder if two events for teleport would be better. If the event is cancelled it would be good to not search for a location and possibly load chunks needlessly. Perhaps add a new "PlayerTeleportToPlotLocationChosenEvent" :D

Should be better now I'd say - usage would be now:

@Subscribe
public void yeet(PlayerTeleportToPlotEvent event) {
    event.setLocationTransformer(origin -> origin.add(-15, 0, 0));
}

Therefore, only if the event is not cancelled, the transformer is called and no unnecessary chunk loads would be performed.

Obviously, a new Location instance may be returned instead of calling methods on the origin Location

[SirYwell]

Looks good. The only thing we could potentially change is to make it non-null and use UnaryOperator.identity() as default value, but I don't have a strong opinion on that.