When a faction tag is changed through the administrative set tag command, FactionRenameEvent#getFaction() reports the faction of the administrator executing the command instead of the faction actually being renamed.
This makes the event misleading for plugins that rely on it to identify which faction changed.
Current behavior
The admin command resolves the target faction separately:
Faction faction = context.get("faction");
but fires the event with only the sender:
FactionRenameEvent renameEvent = new FactionRenameEvent(sender, tag);
The event constructor then derives the faction from the sender:
public FactionRenameEvent(FPlayer sender, String newTag) {
super(sender.faction(), sender);
tag = newTag;
}
So, if an administrator in faction A renames faction B to C:
event.getFaction() returns faction A
event.getFPlayer() correctly returns the administrator
event.getFactionTag() correctly returns C
The command then applies the rename to faction B.
Expected behavior
For an administrative rename of faction B to C:
event.getFaction() should return faction B
event.getFPlayer() should return the administrator who initiated the change
event.getFactionTag() should return C
This keeps the event consistent with the faction that will actually be modified.
Suggested fix
Allow FactionRenameEvent to receive the faction being renamed explicitly, and use that constructor from the administrative command.
For example:
public FactionRenameEvent(Faction faction, FPlayer sender, String newTag) {
super(faction, sender);
tag = newTag;
}
The existing constructor could remain for compatibility and delegate to the new one:
public FactionRenameEvent(FPlayer sender, String newTag) {
this(sender.faction(), sender, newTag);
}
Then the administrative command can fire:
new FactionRenameEvent(faction, sender, tag);
This preserves the current behavior for normal self-renames while making administrative renames report the correct target faction.
When a faction tag is changed through the administrative
set tagcommand,FactionRenameEvent#getFaction()reports the faction of the administrator executing the command instead of the faction actually being renamed.This makes the event misleading for plugins that rely on it to identify which faction changed.
Current behavior
The admin command resolves the target faction separately:
but fires the event with only the sender:
The event constructor then derives the faction from the sender:
So, if an administrator in faction
Arenames factionBtoC:event.getFaction()returns factionAevent.getFPlayer()correctly returns the administratorevent.getFactionTag()correctly returnsCThe command then applies the rename to faction
B.Expected behavior
For an administrative rename of faction
BtoC:event.getFaction()should return factionBevent.getFPlayer()should return the administrator who initiated the changeevent.getFactionTag()should returnCThis keeps the event consistent with the faction that will actually be modified.
Suggested fix
Allow
FactionRenameEventto receive the faction being renamed explicitly, and use that constructor from the administrative command.For example:
The existing constructor could remain for compatibility and delegate to the new one:
Then the administrative command can fire:
This preserves the current behavior for normal self-renames while making administrative renames report the correct target faction.