Block Entity Behavior

Immortius

Lead Software Architect
Contributor
Architecture
GUI
So, now that we established that keeping state of the network in memory is beneficial, and also that we should keep only information for loaded chunks, you can see that I might be interested in receiving information when a component is activated (chunk is loaded, block with component is placed, or component is added to existing block entity) to add it to network, or deactivated to remove it from network, but wouldn't want to know, when a transient block entity is recreated, because someone looked at it, or it was interacted in any other way, or similarly destroyed at the end of the tick. If the activated/deactivated is not called for recreated/destroyed transient block entities, then OnActivated, OnDeactivated and the BlockType events called during chunk load/unload would be the only ones I'd have to use to track the loaded chunk's networks.

Alternatively, with your current design I'd have to listen to following events:
- OnAdded/OnRemoved - to track new blocks and destroyed (replaced) blocks, or when component is added/removed by a system,
- OnChunkGenerated/OnChunkLoaded/OnChunkUnloaded to iterate through all active entities for any that I have to add/remove from network,
- BlockType events to check for any transient block entities that should be/are part of the loaded network.

I don't mind doing it the way I've described, but as you can see, it's not going to be pretty (iterate through all entities in the chunk). I'm also not sure, if you even have methods to iterate through all active entities in a chunk?
Ok, I can see where you are coming from. For this discussion I'm going to jettison the label of transient block entities and just refer to blocks with and without entities to start with.

Firstly, I think we should lay it in stone that there will be entities for BlockTypes (and/or families?), and that when a chunk is created or loaded lists of entity-less blocks of each type that don't have entities are gather and a BlocksActivated event is sent (also BlocksGenerated on creation?). Similarly on unloaded a BeforeBlocksDeactivated event. This cleans up the iteration over all blocks - you can subscribe to those events for the components you are interested in for the bulk of blocks. Blocks with entities go through the standard OnActivated/OnDeactivated cycle which is fine in of itself.

Then for the creation/destruction of temporary entities for entity-less blocks, I'm coming around to thinking no events should be sent at all (you probably suggested this in the past). If the temporary entities are changed, events will be sent for those changes as per any entity - in particular this would include the addition and removal of @ForcePersistWhilePlaced annotated components. This also allows for the natural changing of those entities when the block type is changed - the entity for the current block will silently be summoned into existence, altered to match the prefab of the new block, and then silently disappear again.

This means you would only subscribe to:

OnBlocksActivated for your Signalling component
OnBlocksDeactivated for your Signalling component
OnActivated for your Signalling component + the block component
OnDeactivated for you Signalling component + the block component

for addition and removal from the network. Maybe OnBlocksGenerated/OnAdded to do some additional setup when they first appear, but I don't think it is necessary in this case.

Does that seem about right, or have I missed something again?

I am also perfectly open to having OnLoaded/OnUnloaded events for entities, but those in of themself don't actually help much with your situation.
 

Immortius

Lead Software Architect
Contributor
Architecture
GUI
Status Report:
  • Block Type Entities are in, but not yet used for anything
  • The behavior of temporary blocks/active blocks now meets that described. Several systems have been updated to work with this (block damage, block items, chests)
  • Beginning work on the events surrounding chunk generation/loading/unloading. These should be done shortly.
Those three items combined will suffice to allow mods to depend on these behaviors. There are a couple of areas that will need further work (in particular, making sure changes to the world from background threads interact with the block entities correctly). And then I'll move on to unloading/reloading entities with the chunks they exist within.
 
Top