Archiviert
13
0
Dieses Repository wurde am 2024-12-25 archiviert. Du kannst Dateien ansehen und es klonen, aber nicht pushen oder Issues/Pull-Requests öffnen.
Paper-Old/patches/server/0723-Route-sign-run_command-click-events-through-normal-c.patch
kennytv 0aa0a1d973 Updated Upstream (CraftBukkit)
Upstream has released updates that appear to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing

CraftBukkit Changes:
b5d7883a SPIGOT-6634: Override needed method
99561c21 SPIGOT-6624: Explosions do not destroy blocks out of vanilla heights in custom dimensions
2021-07-09 16:20:40 +02:00

41 Zeilen
2.8 KiB
Diff

From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: mdcfe <1917406+mdcfe@users.noreply.github.com>
Date: Wed, 7 Jul 2021 12:29:48 +0100
Subject: [PATCH] Route sign run_command click events through normal chat logic
This patch changes sign command logic so that `run_command` click events are routed through the standard chat/command
logic used for inbound chat messages.
This fixes numerous issues related to sign click commands:
- Signs with a `run_command` value of "/<plugin command>" would fail and show the "Unknown command" warning. This
prevents usage of commands like `//wand` from WorldEdit in sign click events entirely and requires users to drop
the leading slash from other plugins' commands. This patch now executes the plugin commands as would be expected,
adding a leading slash if necessary.
- Signs with a `run_command` value that doesn't match an existing command could fail silently. This patch causes
these to *always* show "Unknown command" instead.
- Plugins listening to `PlayerCommandPreprocessEvent` would not be able to intercept any command executions from
sign click events. This patch allows plugins to intercept player commands when fired by a click event, in the same
manner as commands executed by the player typing or clicking on a chat message.
- Commands executed from signs would not be logged to the console. This patch fixes this.
This patch also prepends a leading slash if the `run_command` value lacks one, which matches vanilla behaviour (old
code would strip this slash away) while also ensuring `PlayerCommandPreprocessEvent#getMessage` remains consistent
with other command executions from chat (which always include the leading slash).
diff --git a/src/main/java/net/minecraft/world/level/block/entity/SignBlockEntity.java b/src/main/java/net/minecraft/world/level/block/entity/SignBlockEntity.java
index 9b5d11ece006d7aa893360a84ba652c666517ac1..171fea79d3a7c282e473b0fbb46254e3cd9c7aa9 100644
--- a/src/main/java/net/minecraft/world/level/block/entity/SignBlockEntity.java
+++ b/src/main/java/net/minecraft/world/level/block/entity/SignBlockEntity.java
@@ -227,7 +227,10 @@ public class SignBlockEntity extends BlockEntity implements CommandSource { // C
ClickEvent chatclickable = chatmodifier.getClickEvent();
if (chatclickable != null && chatclickable.getAction() == ClickEvent.Action.RUN_COMMAND) {
- player.getServer().getCommands().performCommand(this.createCommandSourceStack(player), chatclickable.getValue());
+ // Paper start - route through standard chat/command logic
+ final String command = chatclickable.getValue().startsWith("/") ? chatclickable.getValue() : "/" + chatclickable.getValue();
+ player.connection.chat(command, false);
+ // Paper end
}
}