We've split up the commands, scripting and mods, and add ons category! Please be sure you get your thread in the right place.

← Commands
16
Follow

/blockstate command

I don't know if I badly searched for this but I'm a bit astonished that nobody suggested this yet.

We really need a command that can alterate dynamically the block state of blocks. We can currently change the nbt of entity blocks with the data command, but blockstate have never been a thing.
It can be helpful for many thing, like creating our own more restrictive debug stick, or dry a full area from waterlogged blocks.

Some blocks have huge possible set of states, for example stairs, which have 2^13 possible states, it is barely impossible to rely on the current fill command to change a single state for them, would need more than 8k fill commands for a single stair's ID. This kind of command would help a lot in many context (including the fact jigsaw / structure blocks automatically turn the waterlogged state of some blocks to true if the structure is placed in water).

Example of syntax :

/blockstate <x> <y> <z> <dx> <dy> <dz> <block_ID/block_tag> set <blockstate> <value>
/blockstate ~ ~ ~ ~20 ~10 ~20 #stairs set waterlogged false
Avatar
Registered User shared this idea

5 Comments

Please sign in to leave a comment.

Date Votes
Sorted by oldest
  • 0
    Registered User commented
    Comment actions Permalink

    This already exists in the form of an enchanted stick named "debug stick".

  • 3
    Registered User commented
    Comment actions Permalink

    The problem is also that using /setblock or /fill to change the block state always resets all NBT tags of that block. This is for example a problem if you want to ignite a campfire because it deletes all items, that are being cooked. You can summon a small fireball instead in this case though. /blockstate would allow you to change block states while keeping NBT tags of the block.

  • 1
    Registered User commented
    Comment actions Permalink

    This would be very helpful, recently I was working on a datapack for find the button, and to support resetting, the state of every button has to be remembered and then it compares the remembered data to call the correct /setblock command, this results in having 61 mcfunction files 1 file to check the type, 12 to check the facing and 48 to check the face. This is to optimize so that we aren't calling 144 commands at once instead it's only calling 19 commands at once.

    Here are the two syntaxes I could think of being useful, the first being to set the state of one block, the block can be validate using execute so no need to include id or tag. The second one acts like the fill command and will modify an area, the id and tag are optional but if provided I'd imagine that it would only modify those that match the id or tag.

    /state set <x> <y> <z> <state> <value>
    /state fill <x> <y> <z> <dx> <dy> <dz> <state> <value> [id/tag]

    The responses I imagine would be something along the lines of

    /state set ~ ~ ~ waterlogged false
    Error: "Could not modify the block"
    Success: "Modified the block at 0, 0, 0"
    /state fill ~ ~ ~ ~10 ~ ~20 waterlogged false #minecraft:stairs
    Error: "No blocks were modified"
    Success: "Successfully modified 2 blocks"
  • 1
    Registered User commented
    Comment actions Permalink

    Another usefull thing would be:

    /blockstate get <x> <y> <z> [state]

    This returns the current blockstate of the block at position x y z. If the optional state parameter is provided, return only the value for that specific blockstate. Otherwise, return all blockstates (if any) of the block.

  • 0
    Registered User commented
    Comment actions Permalink

    I have an idea for a similar kind of command, but instead of changing or retrieving a certain property of a block, I'd make it to save the entire block state, including name and properties into NBT and back with a syntax similar to this:

    /blockstate (get|set) <x> <y> <z> (block ...|entity ...|storage ...) <path>

    So if you wanted to alter a certain part of the block state, you'd do something like this:

    /blockstate get ~ ~ ~ storage example:storage mystate
    /data modify storage example:storage mystate facing set value "north"
    /blockstate set ~ ~ ~ storage example:storage mystate

    The added benefit would be to use this inside of falling blocks and block displays or the other way around:

    /blockstate get ~ ~ ~ storage example:storage mystate
    /execute align xyz summon block_display run data modify entity @s block_state set from storage example:storage mystate
    /setblock ~ ~ ~ air

    In this example, you replace a block with a block display of itself. A similar thing could be done for falling blocks.