You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
implement '.auto' for drop configurations in decaying blocks. #2386
Since #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
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.
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.
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.
Activity
IntegratedQuantum commentedon Dec 8, 2025
@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 commentedon Dec 8, 2025
Since #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 commentedon Dec 9, 2025
Edit: I assume we are considering change from
To
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 commentedon Dec 9, 2025
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
I think callbacks are currently initialized last.
IntegratedQuantum commentedon Dec 11, 2025
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.
Add a creator parameter to callbacks init function. (#3216)