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

PlaceBlock(placeAt) & block breaking support(1.16) #24

Closed
wants to merge 5 commits into from

Conversation

aria1th
Copy link
Contributor

@aria1th aria1th commented Dec 24, 2021

while (world.getBlockAt(bx,by,bz).getBlockId() == 'lectern'){
player.updateBreakingBlock(bx,by,bz);
sleep(50);}

example code for block breaking should be like that, client should 'update' or 'attack' block every 50ms. Unless client 'cancels' block breaking... I'm not sure if client would need to call cancel function.

placing block functions barely work, but I don't know if I should do complex inventory swap inside same class.

@senseiwells
Copy link
Owner

For the placing I would just try to place the item that is currently in the players hand. If the player is not holding a BlockItem then throw an error? This allows the user to code the swapping slots instead

@aria1th
Copy link
Contributor Author

aria1th commented Dec 24, 2021

hmm yeah that's way better, actually I was trying to implement piston rotating / anvil rotating things, it requires different handling by block types... but it's future problem

protocol still remains... soon
@senseiwells
Copy link
Owner

I don't think either interactionManager.interactBlock or interactionManager.updateBlockBreakingProgress are thread safe, they both access the player's inventory which is probably what is causing your concurrentModificationException

@aria1th
Copy link
Contributor Author

aria1th commented Dec 24, 2021

that might explain it, updateBlockBreakingProgress seems okay, but interactBlock weirdly access player inventory.... it crashes when player picks up item at empty slot, not sure why this is happening tho. it can be tweaked a bit to directly send packet hmm...

@senseiwells
Copy link
Owner

Just push it back to the main thread

client.execute(() -> {
    // code
});

@aria1th
Copy link
Contributor Author

aria1th commented Dec 24, 2021

yes it works, still some memory sum up but it does not exceed 4GB so it should be okay

@aria1th
Copy link
Contributor Author

aria1th commented Dec 26, 2021

Still, it causes some invalid Map operations, I just tweaked to use packet instead but it will result some failure (because its packet)
maybe function name should be changed to attemptInteractAt ?

@senseiwells
Copy link
Owner

What invalid Map operations?

@aria1th
Copy link
Contributor Author

aria1th commented Dec 26, 2021

same iteration problem, so now I tweaked all into packet handling at 1.18 branch... but seems item swap code is also packet dependent so its order messes up without sleep().

@senseiwells
Copy link
Owner

Would it be better for us to talk on discord? Github is kinda... slow xD

@senseiwells
Copy link
Owner

The updateSlotPacket is pointless, Minecraft ticks this, and if you change it, it will automatically send a packet for you. No need to do this manually.

You also do this:

ArucasMinecraftExtension.getClient().execute(() -> {
    interactionManager.clickSlot(screenHandler.syncId, numberValue1.value.intValue(), 0, SlotActionType.SWAP, player);
    interactionManager.clickSlot(screenHandler.syncId, numberValue2.value.intValue(), 0, SlotActionType.SWAP, player);
    interactionManager.clickSlot(screenHandler.syncId, numberValue1.value.intValue(), 0, SlotActionType.SWAP, player);
}

Also you don't need to do all those checks for the direction, you can just do, which you do already, so I'm not sure why you check the string xD

var direction = Direction.byName(direction);
if (direction == null) {
    // Throw error
}

I also wouldn't send the PlayerInteractBlockC2SPacket, you should keep to the interactionManager.interactBlock()... This will cause desyncs, you could also make this return a boolean, whether it was successful, but you'll probably need to use an AtomicReference and a latch because it's threaded though hmm

@aria1th aria1th closed this Dec 28, 2021
@aria1th aria1th deleted the patch-3 branch December 28, 2021 07:54
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.

None yet

2 participants