-
Notifications
You must be signed in to change notification settings - Fork 79
Remove block entity blocks from the octree and remove the unused invisible field. #1833
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
6d88532
cbc891a
d0de98c
bf2f67e
020cc9d
6333041
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -13,6 +13,7 @@ | |
| import se.llbit.nbt.CompoundTag; | ||
| import se.llbit.nbt.Tag; | ||
|
|
||
| import java.util.Collection; | ||
| import java.util.Random; | ||
|
|
||
| public abstract class Block extends Material { | ||
|
|
@@ -25,13 +26,6 @@ public abstract class Block extends Material { | |
| */ | ||
| public boolean localIntersect = false; | ||
|
|
||
| /** | ||
| * Invisible blocks are not rendered as regular voxels (they are not added to the voxel octree). | ||
| * This is used for blocks that are rendered as entities, and blocks that are not implemented | ||
| * yet. | ||
| */ | ||
| public boolean invisible = false; | ||
|
|
||
| public Block(String name, Texture texture) { | ||
| super(name, texture); | ||
| } | ||
|
|
@@ -97,31 +91,67 @@ public String toString() { | |
| return name; | ||
| } | ||
|
|
||
| /** | ||
| * Check if this block is a block entity, i.e. {@link #createBlockEntity(Vector3, CompoundTag)} should be invoked to | ||
| * create an entity from this block and its entity data tag. This is used for blocks that need to create a new entity | ||
| * that needs the block entity data, e.g. signs. | ||
| * <p> | ||
| * This is mutually exclusive with {@link #hasEntities()}, use that one if you don't need block entity data. | ||
| * | ||
| * @return True if this block is a block entity, false otherwise | ||
| */ | ||
| public boolean isBlockEntity() { | ||
| return false; | ||
| } | ||
|
|
||
| public Entity toBlockEntity(Vector3 position, CompoundTag entityTag) { | ||
| throw new Error("This block type can not be converted to a block entity: " | ||
| /** | ||
| * Create a block entity from this block and the given block entity tag at the specified position. | ||
| * | ||
| * @param position Position | ||
| * @param entityTag Block entity tag | ||
| * @return The block entity created from this block's data and the entity tag | ||
| * @throws UnsupportedOperationException If this block is not a block entity (i.e. {@link #isBlockEntity()} returns false | ||
| */ | ||
| public Entity createBlockEntity(Vector3 position, CompoundTag entityTag) { | ||
| throw new UnsupportedOperationException("This block type can not be converted to a block entity: " | ||
| + getClass().getSimpleName()); | ||
| } | ||
|
|
||
| public boolean isEntity() { | ||
| /** | ||
| * Check if this block has entities, i.e. {@link #createEntities(Vector3)} should be invoked to create entities from this | ||
| * block. A block can create multiple entities (e.g. the lectern may create a lectern and a book entity). | ||
| * <p> | ||
| * This is mutually exclusive with {@link #isBlockEntity()}, use that one if you need block entity data. | ||
| * | ||
| * @return True if this block has entities, false otherwise | ||
| */ | ||
| public boolean hasEntities() { | ||
| return false; | ||
| } | ||
|
|
||
| /** | ||
| * If this returns true, the block won't be removed from the octree even if this is an entity | ||
| * (i.e. {@link #isEntity()} returns true). This can be used for blocks that also contain | ||
| * entities, e.g. candle (where the candle flame is an entity). | ||
| * Create entities from this block at the specified position. | ||
| * <p> | ||
| * This may return multiple entities, e.g. the lectern has a lectern entity and an optional book entity. | ||
| * | ||
| * @param position Position | ||
| * @return The entities created from this block's data | ||
| * @throws UnsupportedOperationException If this block is not a block entity (i.e. {@link #hasEntities()} returns false | ||
| */ | ||
| public boolean isBlockWithEntity() { | ||
| return false; | ||
| public Collection<Entity> createEntities(Vector3 position) { | ||
| throw new UnsupportedOperationException("This block type can not be converted to entities: " | ||
| + getClass().getSimpleName()); | ||
| } | ||
|
|
||
| public Entity toEntity(Vector3 position) { | ||
| throw new Error("This block type can not be converted to an entity: " | ||
| + getClass().getSimpleName()); | ||
| /** | ||
| * Whether to remove this block from the octree if it contains entities (i.e. {@link #hasEntities()} or {@link #isBlockEntity()} | ||
| * return true). | ||
| * <p> | ||
| * Most blocks are replaced by their entities (eg. signs create a sign entity that does the rendering and the block itself | ||
| * does nothing, but some blocks use block model and entities, e.g. candle (where the candle flame is an entity but the candle is a block). | ||
| */ | ||
| public boolean isReplacedByEntities() { | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My understanding was that
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does it make any sense to just have this api Or have I just misunderstood the idea?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
It didn't do that yet (that's what this PR does) but it's indeed what I would have expected.
Maybe. The only reason it exists is because we need block entity data for some entities but not for other entities where that block entity data isn't even available.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It just feels a bit weird that the callee decides which method gets called by two booleans, obviously not blocking ^>^ It would then have to be
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I absolutely agree. The current interface let's the block decide what to implement bit the callee decides which method to call. That only works well because there is only one callee.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @NotStirred The problem is that we don't have the tile entity data when we instantiate the block. We load a chunk's tile entities after all blocks have been loaded and then either create block entities or create a new tag (and from that, a new block) with the tile entity data.
If we were to do this, we would need to load the tile entities first, put them into some A better way to think about |
||
| return true; | ||
| } | ||
|
|
||
| /** | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -28,6 +28,5 @@ private Air() { | |
| super("air", Texture.air); | ||
| solid = false; | ||
| opaque = false; | ||
| invisible = true; | ||
| } | ||
| } | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An additional thought, is it possible for a user to need both the entity tag and the ability to return multiple entities?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The closest we have is the decorated pot, which uses the block entity information to update the block tag (creating a new
Blockinstance) and then uses an entity to create the upper part (which is higher than 1x1x1 and thus can't be in the octree).