#How to extend the behavior of vanilla items with `use` override?

66 messages · Page 1 of 1 (latest)

kindred ermine
#

Maybe mixin to the original brickItem class? (The vanilla class)

worn lantern
#

As opposed to defining the functionality on the item, you could use fabric apis callback to implement the functionality

#

There are ways to work around that, but the callback is probably more suitable than some of the complex mixin techniques you could apply

#

It runs before the items onUse

#

And if you return anything other than pass, the default on use doesn't run

worn lantern
#

That sounds right 🙂

worn lantern
#

If you say so

#

Do note that that means that anyone using the callback will override your mixin

#

And

#

Is BrickItem it's own class?

#

Is BrickItem it's own class in vanilla?

#

Then it would be quite bad practice to replace it with your own. Do with that as you will

#

If they return ActionResult.PASS, then your mixin will run

#

If else, no

#

Not really

#

Most fabric devs would call this your fault. But as said above, good luck in your modding

#

If you use the callback, it's up to you

#

If you replace the class

#

It's up to mixin shenanigans

#

Unless they use the callback

#

Then they just win

#

The callback provides an easy compatible way to do it

#

If you don't like the look of the random lambda or something

#

Say that

#

There are solutions for most of the icks about the callback

#

It's better than the forge solution

worn lantern
#

Reflectively iterating through a list of classes

#

And checking if each registered class is currently eligible to receive this event

worn lantern
#

Ultimately

#

You can choose performance or compat

#

And unless your mod is the literal best ever

#

Most pack devs will throw it out at the first sign that you did something in an incompatible way

#

Which if this was in a high performance area

#

It wouldn't be

#

Sorry

#

Fabric caches handlers and has all sorts of optimizations that they make to make it not as slow

#

And the rest is the responsibility of jit

#

As it would be in mixin anyway

#

Not really

#

Unless someone does something like replace brick with a different class

#

Which is highly not recommended

#

Idk. If you are going to mixin, mixin. I really like mixins over callbacks, but I would probably sacrifice a little perf here for some compat

#

Depends on what you did

#

Replacing a class is much more invasive than a bad inject

#

I should clarify

#

Both mixins will apply

#

* most of the time

#

It just may result in ub

#

It's not jvm

#

Mixin priority

#

And then, failing that

#

Sub injector priority

#

Mod loading order

worn lantern
#

And then

#

Injector order

#

Idk. As said above, do as you please. Just don't tell them I let you

#

And that's not an assumption we really like

#

Technically

#

On prism launcher

#

With no mods but your own

#

There is another dev touching the code

#

Have fun