Compass TP should not take priority over creating Lodestone Compasses
ehx-v1 opened this issue · 2 comments
The Problem
WorldEdit has a feature where using a Compass teleports you a certain distance in the direction you're looking, presumably similar to the /thru
command. At the time of this feature's introduction, this was unproblematic. However, 1.16 introduced a right-click functionality for compasses by adding the Lodestone block which, when right-clicked with a compass, turns that compass into a Lodestone Compass that points to it. Currently, when right-clicking a Lodestone with a compass, the teleport functionality is performed instead, making it impossible (for admins) to create Lodestone Compasses when WorldEdit is installed.
A Solution
When a compass right-click is performed, first check if a Lodestone is being right-clicked. If so, allow the Vanilla functionality to go through. Otherwise, run WorldEdit's teleport functionality as before.
Alternatives
Remap the teleport functionality to a different tool that continues not to have a right-click functionality (breaks pre-existing user workflows and might run into the same issue with future Minecraft updates)
Anything Else?
While this is an issue with a functionality WorldEdit has rather than one it doesn't have, the problem lies within the design of an intended behavior being outdated rather than problems in the code causing unintended behaviors, so I felt like it's closer to a feature request than a bug.
None of the solutions involving changing the mechanic itself are probably a good idea, given how ubiquitous the worldedit compass is, and ignoring the functionality for that one block would lead to confusion when people try to travel through a lodestone.
What everyone has been doing, and what I feel does make the most sense, is for the admins to just unbind the tool and rebind it again afterwards, as it only takes a few seconds (or just changing it to something else for themselves). Unless it’s some odd use case where you’re making these near constantly, it feels like a much better solution than making the tool override interactions in all situations except one