Single Status Update
See all updates by Spontaneous Explosions
-
I made a mock-up of what a MC Bedrock custom block resource-pack definition could be with many more options.
Spoiler{
"format_version": "1.15.0",
"minecraft:block": {
"description": {
"identifier": "namespace:block_name",
"register_to_creative_menu": true,
"creative_menu_tab": "construction"
},"minecraft:block_data": [
{
"data_value": 0,
"minecraft:block_model": {
"hitbox": "hitbox_model_file",
"collision": "collision_model_file",
"geometry": "block_geometry_file",
"inventory_model": "block_inventory_model_file",
"texture": "texture-id",
"carried_texture": "texture_id"
}}
],
"minecraft:sounds": {
"place": "sound",
"break": "sound",
"step": "sound"
},
"minecraft:placement_logic": "block",
"minecraft:waterlogged": true,
"minecraft:transparent" : true,
"minecraft:gravity": false,
"minecraft:bouncy": {
"value" : 0.5
},
"minecraft:climbable": false,
"minecraft:sticky": {
"value" : 0.3,
"stick_to_wall": false,
"restrict_jumping": false
},
"minecraft:fuel": {
"burn_time": 1
},
"minecraft:block_types" : ["double"],
"minecraft:loot": {
"table": "loot_table"
},
"minecraft:destroy_time": {
"value": 2.5
},
"minecraft:explosion_resistance": {
"value": 15
},
"minecraft:friction": {
"value": 0.1
},
"minecraft:map_color": {
"color": "#000000"
},
"minecraft:block_light_absorbtion": {
"value": 0
},
"minecraft:block_light_emmission": {
"emission": 0
}
]}
}Explanations of each parameter for those who would understand/care:
(I'll only explain the ones I made up, not the ones that are already defined in the current block documentation)
Spoiler"minecraft:block_data"
SpoilerThis array contains objects representing each numerical block data value you define.
This will only change the appearance of the block, not any of the behaviors.
"block_data" parameters:
"data_value" is the numerical value for each appearance. In game example would be planks. They have one block ID, "minecraft:planks"(Until the flattening on Bedrock). Planks with data 0 would be oak.
data_value : 0 is the default, if no placement_logic(see below) is defined
You can have as many block data values as you please.
"hitbox", "collistion", "geometry", and "inventory_model"
These options control the visual and physical model of your block.
Each one accepts a block geometry file as it's value.
You can have a separate model for the hitbox, collision, geometry(Equivalent of Java block model) and inventory model if you wish, but if you want all 4 to have the same model, you can use
"model":"model_file"
"texture" and "carried_texture" control the texture of the block for each data value.
texture is just the way it appears in the world.
carried texture controls how it will appear in your hand.
Block data could be accessed from the behavior pack block file, to determine what happens with certain block interactions.
"minecraft:sounds":
Spoiler"minecraft:sounds" simply controls the block sounds for different interactions.
The parameters are things like "place","break" and "step". the current documentation has a list of sound types somewhere.
if you want to use the same sound for everything, you could use "sounds": "sound"
"minecraft:placement_logic":
QuoteThis is where I feel like things get complicated.
placement logic defines...how the block is placed.
It refers to a separate file. This file would contain a bunch of tests. The tests would be thinsg like the direction the player is facing, what block they're currently selecting, whether or not you're pointing at the side of the block, ect...
With each test, you can define what happens if the test is true, or if it is false.
Test responses can only accept data values, the ones defined in your block file.
for example, if you had the block file defining a stair block, if ould contain the "block_data" array with each of the 24(I think) data values, each with it's own model.
Then you define a placement logic file that detects the players direction, and where on the block you're selecting(upper half, lower half) and set a data value accordingly.
"minecraft:waterlogged": Determines whether or not the block can be waterlogged
accepts boolean
"minecraft:transparent": Determines whether or not the block is considered transparent by the game
accepts boolean
"minecraft:gravity": Determines whether or not the block will fall, like sand
accepts boolean
"minecraft:bouncy": Determines the bounciness of a block
accepts a decimal value
"minecraft:climbable": determines whether or not the block can be climbed
accepts boolean
"minecraft:sticky":
Quotedetermines the stickiness of the block.
parameters:
"value" determines how sticky it is(how much is slows you down when walked on)
"stick_to_wall" determines whether or not the stickiness is applied to the sides of the block
"restrict_jumping": determines whether or you will stick to the block and not be able to jump(like honey blocks)
This value could be used by soul sand to control is slow walking.
you could set the sticky to 1, have it not stick to walls, and not restrict jumping.
Likewise, you could have all 3 true and get something like a honey block.
"minecraft:fuel": determines whether or not the block can be used as fuel.
accepts decimal value, determining how many items it can smelt.
"minecraft:block_types":
QuoteAn array containing all block types this block has.
Example of a block type would be block_entity.
If a block has a block_entity type, it's block model must be an entity geometry file instead of a block geometry file.
In turn, it would be able to have animations.
In game examples of this type would be chests and banners.
If you set the type to 'double' it expects at least 2 block_data values, one defining the bottom block, and one defining the top.(by putting "type": "top" inside a data_value object, foe example)
Block types, in addition to the block_data, would be the equivalent of block_states on Java(kinda)
So that's that.
Just something I though up.
I fully expect something similar to this system to come to bedrock in the near-ish future.
-
Recently Browsing 0 members
No registered users viewing this page.