EssentialsX

EssentialsX

2M Downloads

[1.14.4] NickChangeEvent returns incorrect player object

SwankyNoodle opened this issue ยท 2 comments

commented

Information

Full output of /ess version:

[16:06:12 INFO]: Server version: 1.14.4-R0.1-SNAPSHOT git-Paper-243 (MC: 1.14.4)
[16:06:12 INFO]: EssentialsX version: 2.17.1.0
[16:06:12 INFO]: EssentialsXProtect version: 2.17.1.0

Server log: https://gist.github.com/SwankyNoodle/5c30d437307d79e950a94b601f398fcc#file-latest_log

EssentialsX config: https://gist.github.com/SwankyNoodle/5c30d437307d79e950a94b601f398fcc#file-essentials_config

Details

Description
When implementing the NickChangeEvent event, the player returned through e.getAffected().getBase(); is not the player that triggered the event (the affected player), but the one that issued the command that initially triggered the event.

Steps to reproduce
Create a method that implements the NickChangeEvent event in a test plugin with the player affected being returned.
An example of such a function is:

@EventHandler
   	public void GetPlayerExample(final NickChangeEvent e) {
    	Player p = e.getAffected().getBase();
    	p.sendMessage(p.getName().toString());
    }

Then trigger the event by updating the nickname of another player (not the one issuing the command)

Expected behavior
e.getAffected().getBase() should return the player who triggered the event, not the one who issued the command.

commented

Confirmed, event parameters are passed in the wrong order here:

private void setNickname(final Server server, final CommandSource sender, final User target, final String nickname) {
final User controller = sender.isPlayer() ? ess.getUser(sender.getPlayer()) : null;
final NickChangeEvent nickEvent = new NickChangeEvent(controller, target, nickname);
server.getPluginManager().callEvent(nickEvent);

Correct parameter order:

public NickChangeEvent(IUser affected, IUser controller, String value) {
super(affected, controller);

This will likely not be fixed until a major update as the change will break existing implementations that listen for this event.

commented

a11552f adds documentation to the methods indicating that they are swapped around. We can't properly address this until a breaking API revision though.