[Suggestion] Shouldn't Block Behaviors receive block ticks too?

[BearWrestler]

I was looking for a way to receive a call when a BlockPlant is ticked, but there doesn't seem to be a clean way to do it.

1. I could subclass BlockPlant, and set my mod to load before the official Survival mod to register "BlockPlant" before it does, but it's not great:

• Annoying and confusing for mod users because it causes an error in the log when the official mod tries to load its own BlockPlant, when everything actually works as intended.
• Impossible to resolve conflict with anyone mod subclassing BlockPlant like me, or mandatory update if the base game introducing subclasses of BlockPlant which I'd need to subclass too, etc.
• Requires splitting my mod into two: one that loads super early to register my block subclass before official Survival does, and one that loads late to have access to all the assets.

2. I could monkey-patch the method to have a Pre or Post hook.

3. Adding a block entity to every BlockPlant would presumably work too, but would be a huge waste of memory. IIUC it's one instance per in-world block. But even then I'm not sure, because block entities seem to register directly for game ticks, not for block ticks.

[The suggestion] So I'm wondering why the game doesn't add methods to tick BlockBehaviors (perhaps with an explicit subscribe to avoid wasting calls) whenever block type they're attached to is ticked.

Actually, you might want to get rid of the non-composable Block classes altogether, and use collections of behaviors or an unlimited number of Block classes under the same id instead.

(BTW If I missed another, non-monkey-patching way of intercepting block ticks for BlockPlant, please point it out.)

---

Sub-suggestion: to make solution #1 above less painful, it would be nice to have a way to either:

- Unsubscribe a block type, so you can just remove it from existence, or reuse the ID to subscribe your own block type.

- Expand ModSystem.ExecuteOrder() so a mod can receive multiple callbacks, each at a different moment of the loading process (i.e. each callback has a different ExecuteOrder)

- Allow multiple ModSystem classes per mod (it could be a SubModSystem) that can each have their own ExecuteOrder().

---

Thanks!

Edited March 3, 2025 by BearWrestler