Skip to content
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

AccurateBlockPlacement now support FacingBlocks #228

Closed
wants to merge 19 commits into from

Conversation

aria1th
Copy link

@aria1th aria1th commented Aug 19, 2021

tested with fence gate, lentern, end portal frame, stairs, hoppers, chest(somehow buggy), barrel, redstone components, bed, bee hive, grindstone.

@DragonEggBedrockBreaking
Copy link
Contributor

Fixes #169 #206

its not coded in tweakeroo / litematica, so we can't define its defaultstate (FACE) property.
@aria1th
Copy link
Author

aria1th commented Aug 20, 2021

Let's see what's still not supported..
Bell is not supported.
Levers / Buttons are not supported since it needs 'face' too, its problematic because it needs actual hit vector.
Signs, yes, needs hit vector.
Rails does not have facing, and can be updated when nearby blocks are placed.

Grindstone, however, it can be placed 'facing' correctly but it does not refelect its 'attached side' so I removed all wallmountedblocks, to prevent ghost block and errors.

Doorblock needs 'hinge' too, but usually it does nothing so its remaining.

@aria1th
Copy link
Author

aria1th commented Aug 20, 2021

Chest is not supported: its rotation can work correctly, but its double/single behavior is locational. Should be fixed when its solved.

@aria1th
Copy link
Author

aria1th commented Aug 21, 2021

Fixed ChestBlock behavior, it mimics vanilla.

Copy link
Collaborator

@altrisi altrisi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small review, not really code review, mostly code style (not tested).

Also some changes to style could be reverted (like lines 25-26 being changed), and there's places where code look better with spaces after the commas.

Comment on lines 32 to 41
private static Boolean HasDirectionProperty(BlockState state) {
//malilib code
for (Property<?> prop : state.getProperties()) {
if (prop instanceof DirectionProperty) {
return true;
}
}
return false;
}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd remove this and instead save the result of getFirstDirectionProperty in a field (since it will be needed later anyway) and check != null

Comment on lines 52 to 59
private static Boolean IsBlockAttachableChest(Block originBlock, Direction Facing, BlockPos checkPos, World world) {
BlockState checkState = world.getBlockState(checkPos);
if (checkState == null) {
return false;
}
if (originBlock.getName().equals(checkState.getBlock().getName())) {
return checkState.get(ChestBlock.FACING).equals(Facing) && checkState.get(ChestBlock.CHEST_TYPE) == ChestType.SINGLE;
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
private static Boolean IsBlockAttachableChest(Block originBlock, Direction Facing, BlockPos checkPos, World world) {
BlockState checkState = world.getBlockState(checkPos);
if (checkState == null) {
return false;
}
if (originBlock.getName().equals(checkState.getBlock().getName())) {
return checkState.get(ChestBlock.FACING).equals(Facing) && checkState.get(ChestBlock.CHEST_TYPE) == ChestType.SINGLE;
}
private static boolean isBlockAttachableChest(Block originBlock, Direction facing, BlockPos checkPos, World world) {
BlockState checkState = world.getBlockState(checkPos);
if (checkState == null) {
return false;
}
if (originBlock.getName().equals(checkState.getBlock().getName())) {
return checkState.get(ChestBlock.FACING).equals(facing) && checkState.get(ChestBlock.CHEST_TYPE) == ChestType.SINGLE;
}

Also isn't there a better way than checking the name of the block? I think there must be some other method to checking the state equals.

Vec3d vec3d = context.getHitPos();
BlockPos pos = context.getBlockPos();
double hitX = vec3d.x - pos.getX();
if (hitX<2) // vanilla
BlockState state = block.getDefaultState();
if (hitX < 2 || !(block instanceof AbstractRailBlock) && !HasDirectionProperty(state)) // vanilla
Copy link
Collaborator

@altrisi altrisi Sep 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here this could be something like

DirectionProperty directionProperty = getFirstDirectionProperty(state);
if (... && directionProperty != null)

and then keep the directionProperty for use later.

Comment on lines 95 to 96
int FacingId = code % 16;
facing = Direction.byId(FacingId);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
int FacingId = code % 16;
facing = Direction.byId(FacingId);
int facingId = code % 16;
facing = Direction.byId(facingId);

Comment on lines 131 to 163
if (facing == Direction.SOUTH) {
if (IsBlockAttachableChest(block, facing, pos.west(), world)) {
return state.with(ChestBlock.CHEST_TYPE, ChestType.LEFT);
}
if (IsBlockAttachableChest(block, facing, pos.east(), world)) {
return state.with(ChestBlock.CHEST_TYPE, ChestType.RIGHT);
}
} else if (facing == Direction.WEST) //-z +z
{
if (IsBlockAttachableChest(block, facing, pos.north(), world)) {
return state.with(ChestBlock.CHEST_TYPE, ChestType.LEFT);
}
if (IsBlockAttachableChest(block, facing, pos.south(), world)) {
return state.with(ChestBlock.CHEST_TYPE, ChestType.RIGHT);
}
} else if (facing == Direction.NORTH) //+x -x
{
if (IsBlockAttachableChest(block, facing, pos.east(), world)) {
return state.with(ChestBlock.CHEST_TYPE, ChestType.LEFT);
}
if (IsBlockAttachableChest(block, facing, pos.west(), world)) {
return state.with(ChestBlock.CHEST_TYPE, ChestType.RIGHT);
}
} else if (facing == Direction.EAST) //+z -z
{
if (IsBlockAttachableChest(block, facing, pos.south(), world)) {
return state.with(ChestBlock.CHEST_TYPE, ChestType.LEFT);
}
if (IsBlockAttachableChest(block, facing, pos.north(), world)) {
return state.with(ChestBlock.CHEST_TYPE, ChestType.RIGHT);
}
}
return state.with(ChestBlock.CHEST_TYPE, ChestType.SINGLE);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this the only way of doing this?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess it can use .Direction.rotateYClockwise() and rotateYCounterclockwise() instead of repeated facing checks, I'll try it

@senseiwells
Copy link

Should probably fix this

@aria1th
Copy link
Author

aria1th commented Sep 22, 2021

I'll work on that

@aria1th
Copy link
Author

aria1th commented Sep 22, 2021

Fixed bed bug, will not rotate when its impossible to place. but I found new bug related to this,yes, doors. will fix it soon.

@aria1th
Copy link
Author

aria1th commented Sep 22, 2021

Fixed bed and door block bug.

Comment on lines +25 to +33
#release-curse-versions = 1.16.4,1.16.5
# Whether or not to build another branch on release
release-extra-branch = true
#release-extra-branch = true
# The name of the second branch to release
release-extra-branch-name = 1.17
#release-extra-branch-name = 1.17
# The "name" or id of the Curseforge version for the secondary branch
# This is needed because CF uses too vague names for snapshots
# Can also be the version ID directly coming from https://minecraft.curseforge.com/api/game/versions?token=[API_TOKEN]
release-extra-curse-version = 1.17.1
#release-extra-curse-version = 1.17.1
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why comment those?

aria1th added a commit to aria1th/carpet-extra that referenced this pull request Jun 28, 2022
@altrisi
Copy link
Collaborator

altrisi commented Jul 27, 2022

Closing in favour of #267.

@altrisi altrisi closed this Jul 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants