Carpet

Carpet

2M Downloads

'__on_player_breaks_block()' event running after updates to the surrounding blocks happen.

TCasseBloc opened this issue ยท 5 comments

commented

I don't know if this is WAI, but I'm trying to code a spawn protection app for a carpet server, but with that behavior it's pretty much impossible to do a perfect system without hardcoding all the possible things that could break after the block is broken (and there's a ton of them, without even counting all the things you can do with a debug stick).

Try to put a block with a button on top and load that script :
__on_player_breaks_block(p, b) ->
(
set(pos(b), b)
)

=> The button pops into an item

While programming the app I noted that the item drops from the block itself are already dropped when the event is triggered and runs, but all the items dropped from a chest's contents (for example) aren't spawned yet, I need to schedule the item removal to the end of the tick.

Side note :
I also discovered that the block argument that is given to the event doesn't seem to kept nbt data.

__on_player_breaks_block(p, b) ->
(
print(block_data(b));
print(block_data(pos(b)));
print(block_data(block(b)))
)

All of them return null whatever the block or block NBT data is.

commented

I guess it js WAI cos it triggers after block js broken server side, but I agree that it woule be nice to have something like that.

Side note: Have you tried doing the same with on_player_clicks_block to see if it somehow resets the breaking animatoon?
I mean it wouldnt work if the button is on an instabreakable block (eg. Slime, scaffolding) but maybe it will otherwise?

commented

I guess it could be a solution, but it's meant to be foolproof, and being limited on that is meh. I can't think of a clean way to make an option for it to run before or after, but the NBT not being remembered is a major bug IMO. Maybe I should open another issue on that.

commented

I can try to move it little bit earlier - as soon as server determines that it is positive about breaking the block.

commented

Would be nice to have the option between both, though the usecases for after updating the surrondings are very limited from what I can think of.
I'll make another issue for the NBT conservation bug though.

commented