Search results

Do what NowNewStart? I think, similar to the recent block entity discussion, we really need to spend a bit of time working out what exactly the requirements are for this and what use cases need to be covered before implementing something. I'm not keen on the bucket of options approach. That is...

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...

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?)...

OnActivate/OnDeactivate would be called when they blind in and out of existence. I consider this desirable, because otherwise systems that depend on that behavior won't be able to work. I'm only willing to subvert the entity system so much, and fundamentally you have entities coming in and out...

Agreed. This is what I expected, but thought I'ld check. :) True. Correct. OnLoad and OnUnload are chunk events so wouldn't be sent to the blocks anyway. OnAdded and OnRemoved would not be sent either as the entity system would be tricked out of it. Sorry, I don't think I explained...

Oh, another thing I missed - how does this work with "detatched" blocks? For instance, when a player picks up a chest block, at the moment the chest block's entity ceases to be a block entity and is attached to the held chest item entity - so that it still has the same inventory when later...

They're the same from the point of view of the entity system - since in both cases the entity is being created. However one way of dealing with this is to pseudo-store/restore ON_INTERACTION blocks - then you would only get OnAdded/OnRemoved at the beginning and end of the block's life cycle -...

Ah, I see. I'll clarify that - I specifically meant the unloading more than the saving. In theory the entity system could be backed by an in-memory database that automatically saves to disk,which would not require an explicit autosave. In practice we probably will end up with an autosave though...

Sure. Basically OnAddedEvent + OnActivatedEvent would be sent whenever an ON_INTERACTION block entity is created, and OnDeactivatedEvent + OnDestroyedEvent would be sent whenever it is cleaned up again. For WHILE_PLACED, they bracket the block being placed. This falls out of the ON_INTERACTION...

If another system is checking for "air" then I would say it is wrong - it should be checking either a property of the block type or its entity/components. For instance, it should check for non-solid blocks. We need to do some work in this space - either changing the base properties of blocks...

One thing I would like to try in the future is having no blocks for liquids, and having liquids as an extra layer over the top of blocks instead. This would require the chunk mesh builder to understand liquids, but opens things up for layering liquids over other blocks (like underwater plants...

I think it would be useful to have a discussion on the Block Entity behavior - what features are available and how the system should behave when different things occur like blocks changing. Once that is determined we can work to ensure the system behaves that way. @Marcin, as you have been...

We're also certainly not working on it full time.

This weekend spent some time tracking down bugs in multiplayer - both with the recent functionality and some longer term issues as well. I regret not writing more unit tests, though I've put some more in now. I've also started setting up console command support for multiplayer. Along the way I...

Doors are also an example using a single entity to control both blocks.

Well, it probably will take some time - years most likely. That is the way of things with purely hobby projects like this - we put in time where we can. The reason it is pre-alpha is because we recognize there is a lot that still needs to be done - alpha often signifies that all the core...

You can do pretty much that - you make them invisible and let their entity render them. I mentioned a few posts up, but I guess it can be easy to miss. I had forgotten about that technique in my initial post - it is a last resort to an extent though. It also wouldn't work for the use case...

Keep in mind that it can depend on the texturing - I haven't looked into ConnectToAdjacentBlockFamily's implementation in detail though, so you are quite likely correct.

Every rotation is a separate block. Remember, the only information we store per voxel is the block id - we're effectively packing rotation/etc information into that block id by having each variation a separate block. This allows us to avoid wasting memory with rotation information for every...

Technically this is already possible - what you do is make the block invisible, and then use the entity to render it with a mesh component. This should be used sparingly though. It is not feasible to have special renderers for blocks otherwise because we don't render individual blocks - we...