Quark

Quark

143M Downloads

[1.15] Mod compatibility: Sign editing triggers even if the modded sign handles onBlockActivated for something else

gigaherz opened this issue · 3 comments

commented

Context:
I'm the developer of a little mod called Sign Button, which adds duplicates of the vanilla signs, crafted along a redstone torch, which act as both a sign and a button. Meaning once they are placed, they behave as a button (right-click presses the button). However when Quark is installed alongside my mod, if a sign-button is clicked, both the sign editing behaviour, and Quark's editing feature activate at the same time.

Suggested change:
My hope is that Quark would only activate the editing if the sign doesn't fully eat the click, which given the vanilla code means it would not trigger if onBlockActivated returned SUCCESS, but it would activate on CONSUME(client) or PASS(server).

This wasn't possible before 1.15, since onBlockActivated returned a boolean, but starting with 1.15, this method returns an ActionResultType, making this request at least feasible.

Alternative:
Alternatively, if this is not an option, it would be nice if there was some API to opt-out of sign editing on modded signs that already provide the feature themselves by some other means.

(EDIT: oops I accidentally part of a phrase)

commented

I don't believe I can make that happen easily because PlayerInteractEvent.RightClickBlock is fired before onBlockActivated. For now I hardcoded so it doesn't trigger for signbutton, but I can look at a more robust solution if needed.

commented

Ah that's annoying. I guess I can live with the special casing, since it has the same end result for me.
Can I suggest an IMC endpoint? From my end, that would look something like,

InterModComms.sendMessage("quark", "excludeFromSignEditing", () -> BIRCH_SIGN_BUTTON);
commented