implement '.auto' for drop configurations in decaying blocks.

[tillpp]

https://github.com/PixelGuys/Cubyz/pull/2382#discussion_r2599288858

For this, callback.init might need more context

[IntegratedQuantum]

@Argmaster what do you think about adding extra state to the Callback.init function so it knows what block (or item) it belongs to?

[tillpp]

Since https://github.com/PixelGuys/Cubyz/pull/2381 also uses callbacks but for items i would suggest having variadic inits, such that block callbacks can have the block info, and item callbacks item infos

[Argmaster]

Edit: I assume we are considering change from

pub fn init(zon: ZonElement) ?*@This() {

To

pub fn init(zon: ZonElement, owner: *something) ?*@This() {

Since use case is this simple, I don't think we have a reason to produce more complicated solution. Callbacks are inherently bound to the context of their owner, they can't be exchanged between different owners (an owner would be a block, an item etc.) so I don't think it reduces the usefulness of the solution. This is a reasonable extension of passing zon object to init. There should be no separate info object. It should be just an reference to incomplete (as in not fully initialized) owner object. Tbd how exactly the state of the object should be defined. You cannot guarantee the order of the callbacks, maybe you can guarantee that callbacks are initialized last. This is quite important, because callbacks can do basically anything if they have a pointer to the object. Implementation should be flexible enough to handle typical path of evolution - use without an owner and use with modded owner (eg. Custom item type). I am not sure if implementation can be done though comp time generics or anytype pointers or union enums.

[tillpp]

There should be no separate info object. It should be just an reference to incomplete (as in not fully initialized) owner object.

I am not advocating for a separate info object. when i said block info, i meant either the incomplete the block object or just the BlockID

Tbd how exactly the state of the object should be defined. You cannot guarantee the order of the callbacks, maybe you can guarantee that callbacks are initialized last. This is quite important, because callbacks can do basically anything if they have a pointer to the object.

I think callbacks are currently initialized last.

[IntegratedQuantum]

Implementation should be flexible enough to handle typical path of evolution - use without an owner and use with modded owner (eg. Custom item type). I am not sure if implementation can be done though comp time generics or anytype pointers or union enums.

What I would suggest is just use the generic type, i.e. just the block index (which we desparately should make into its own type), or the item index. It might also make sense to make them optional in the future, however for now I'd suggest to keep it non-optional until we have a use-case for it.

And custom item types, if we choose to open this can of worms, can probably have custom callback creation functions as well.