mc.onPlaceBlock(player, block) => block is the block being placed on instead of the block attempting to be placed.

[Colton1070]

Exceptions module

ScriptEngine

Operating System

Windows 11

LiteLoader version

2.6.2

BDS version

1.19.21.01(ProtocolVersion 545)

What happened?

mc.listen("onPlaceBlock", (player, block) => {}); When logging the placed block (block.name/block.type), it does not log the block that was attempted to be placed. Instead it logs the block that was attempted to be placed on. For example, placing a chest on a grass block logs minecraft:grass.

Is this intended behavior? Using "afterPlaceBlock" correctly logs the right block, however the block that is placed cannot be intercepted - or at least it didn't let me intercept it to prevent it from being placed (docs might be erroneous saying that it can be). I'd assume that any interceptions should be done via onPlaceBlock anyways because that makes more sense.

I want to intercept blocks of a certain type from being placed (chests, signs) for a plugin I am developing. Thanks for the hard work and look forward to getting an answer.

Steps to reproduce?

1. Write an event to listen to "onPlaceBlock".

   mc.listen("onPlaceBlock", (player, block) => {
   log('onPlaceBlock Triggered:');
   log(block.name);
   log(block.type);
   });

2. Attempt to place any item (I tested chest and wooden planks).
3. The block that you are placing on will be logged instead of the block you attempted to place.

Relevant log output

No response

Plugin list

23:53:56 INFO [Server] Plugin List [7]
23:53:56 INFO [Server] - LLMoney [v2.5.1] (LLMoney.dll)
23:53:56 INFO [Server]   EconomyCore for LiteLoaderBDS
23:53:56 INFO [Server] - ScriptEngine-Lua [v2.6.2] (LiteLoader.Lua.dll)
23:53:56 INFO [Server]   Lua ScriptEngine for LiteLoaderBDS
23:53:56 INFO [Server] - PermissionAPI [v2.6.0] (PermissionAPI.dll)
23:53:56 INFO [Server]   Builtin & Powerful permission API for LiteLoaderBDS
23:53:56 INFO [Server] - ScriptEngine-QuickJs [v2.6.2] (LiteLoader.Js.dll)
23:53:56 INFO [Server]   Javascript ScriptEngine for LiteLoaderBDS
23:53:56 INFO [Server] - LockContainer [v0.0.1] (LockContainers.js)
23:53:56 INFO [Server]   Allow players to lock containers!
23:53:56 INFO [Server] - LLDeathHead [v0.0.1] (LLDeathHead.js)
23:53:56 INFO [Server]   When players are killed, their head is dropped as an item on the ground.
23:53:56 INFO [Server] - ScriptEngine-NodeJs [v2.6.2] (LiteLoader.NodeJs.dll)
23:53:56 INFO [Server]   Node.js ScriptEngine for LiteLoaderBDS

[Yushu2606]

It looks like it was designed that way

[Jasonzyt]

Duplicate of #548

[Colton1070]

If that's the case could there be an additional property returned as a convenience for using player.getHand() during the onPlaceBlock event for this purpose?

So instead of:

mc.listen("onPlaceBlock", (player, block) => {
    log('onPlaceBlock Triggered:');
    log(block.name); //minecraft:grass
    log(player.getHand().type); //minecraft:chest
});

It could be:

mc.listen("onPlaceBlock", (player, block, item) => {
    log('onPlaceBlock Triggered:');
    log(block.name); //minecraft:grass
    log(item.name); //minecraft:chest
});

Or I could make a docs pull request to make it more obvious in case such a convenience change is seen as unnecessary,

[timiya233]

emmm Maybe you should use "afterPlaceBlock" This monitor records the blocks placed But this monitor can't be intercepted