Test Pattern
- seeit360
- seeit360
- America/Los_Angeles
- Yes
- No
MCPE-167099MCPE-168449MCPE-169561MCPE-182653MCPE-182675
Adding custom blocks is becoming a mainstream feature of Minecraft. Here is an omission in the block spec that allows for waterlogging a custom block. The developer has no way to set the "transparent" property in the metadata using a component. Here is a typical full block metadata from Mojang:
{ "id": 205, "displayName": "Purpur Slab", "name": "purpur_slab", "hardness": 2, "stackSize": 64, "diggable": true, "boundingBox": "block", "material": "rock", "variations": [ { "metadata": 0, "displayName": "Purpur Slab", "description": "Lower half" }, { "metadata": 8, "displayName": "Purpur Slab", "description": "Upper half" } ], "harvestTools": { "257": true, "270": true, "274": true, "278": true, "285": true }, "drops": [ { "drop": { "id": 44, "metadata": 0 } } ], "transparent": true, "emitLight": 0, "filterLight": 0, "resistance": 6 },and here is a block you can waterlog:
{ "id": 205, "displayName": "Purpur Slab", "name": "purpur_slab", "hardness": 2, "stackSize": 64, "diggable": true, "boundingBox": "block", "material": "rock", "variations": [ { "metadata": 0, "displayName": "Purpur Slab", "description": "Lower half" }, { "metadata": 8, "displayName": "Purpur Slab", "description": "Upper half" } ], "harvestTools": { "257": true, "270": true, "274": true, "278": true, "285": true }, "drops": [ { "drop": { "id": 44, "metadata": 0 } } ], "transparent": true, "emitLight": 0, "filterLight": 0, "resistance": 6 },If we can query 'is_in_water' (example)
{ "condition":"q.is_in_water", "set_block_property":{ "phantom:waterlogged": true } }, { "condition":"!q.is_in_water", "set_block_property":{ "phantom:waterlogged": false } }...we should be able to do something with that easily in our permutations. I'm filing this as a bug because Minecraft is not just a game that takes place in air. 1/3 of the game is underwater. And you cannot place
anunderwater block without an air pocket surrounding it.
Where is"minecraft:transperancy:{}," on custom blocks so they can waterlog?Adding custom blocks is becoming a mainstream feature of Minecraft. Here is an omission in the block spec that allows for waterlogging a custom block. The developer has no way to set the "transparent" property in the metadata using a component. Here is a typical full block metadata from Mojang:
{ "id": 205, "displayName": "Purpur Slab", "name": "purpur_slab", "hardness": 2, "stackSize": 64, "diggable": true, "boundingBox": "block", "material": "rock", "variations": [ { "metadata": 0, "displayName": "Purpur Slab", "description": "Lower half" }, { "metadata": 8, "displayName": "Purpur Slab", "description": "Upper half" } ], "harvestTools": { "257": true, "270": true, "274": true, "278": true, "285": true }, "drops": [ { "drop": { "id": 44, "metadata": 0 } } ], "transparent": true, "emitLight": 0, "filterLight": 0, "resistance": 6 },and here is a block you can waterlog:
{ "id": 205, "displayName": "Purpur Slab", "name": "purpur_slab", "hardness": 2, "stackSize": 64, "diggable": true, "boundingBox": "block", "material": "rock", "variations": [ { "metadata": 0, "displayName": "Purpur Slab", "description": "Lower half" }, { "metadata": 8, "displayName": "Purpur Slab", "description": "Upper half" } ], "harvestTools": { "257": true, "270": true, "274": true, "278": true, "285": true }, "drops": [ { "drop": { "id": 44, "metadata": 0 } } ], "transparent": true, "emitLight": 0, "filterLight": 0, "resistance": 6 },If we can query 'is_in_water' (example)
{ "condition":"q.is_in_water", "set_block_property":{ "phantom:waterlogged": true } }, { "condition":"!q.is_in_water", "set_block_property":{ "phantom:waterlogged": false } }...we should be able to do something with that easily in our permutations. I'm filing this as a bug because Minecraft is not just a game that takes place in air. 1/3 of the game is underwater. And you cannot place ANY custom underwater block without an air pocket surrounding it. unless you add server scripting dependencies and make some absolutely horrible looking code. Get this fixed before you take it out of experimental. Thanks you for your considerations.
In summary, where is the missing spec "minecraft:transparent:{}," on custom blocks so they can waterlog?
Adding custom blocks is becoming a mainstream feature of Minecraft. Here is an omission in the block spec that allows for waterlogging a custom block. The developer has no way to set the "transparent" property in the metadata using a component. Here is a typical full block metadata from Mojang:
{ "id": 205, "displayName": "Purpur Slab", "name": "purpur_slab", "hardness":2, "stackSize": 64, "diggable": true, "boundingBox": "block", "material": "rock", "variations": [ { "metadata": 0, "displayName": "Purpur Slab","description": "Lower half"}, {"metadata": 8,"displayName": "Purpur Slab","description":"Upper half"} ], "harvestTools":{"257":true,"270": true, "274": true, "278": true, "285": true }, "drops": [ { "drop": { "id": 44, "metadata": 0 } } ], "transparent": true, "emitLight": 0, "filterLight": 0, "resistance": 6 },and here is a block you can waterlog:
{ "id": 205, "displayName": "Purpur Slab", "name": "purpur_slab", "hardness": 2, "stackSize": 64, "diggable": true, "boundingBox": "block", "material": "rock", "variations": [ { "metadata": 0, "displayName": "Purpur Slab", "description": "Lower half" }, { "metadata": 8, "displayName": "Purpur Slab", "description": "Upper half" } ], "harvestTools": { "257": true, "270": true, "274": true, "278": true, "285": true }, "drops": [ { "drop": { "id": 44, "metadata": 0 } } ], "transparent": true, "emitLight": 0, "filterLight": 0, "resistance": 6 },If we can query 'is_in_water' (example)
{ "condition":"q.is_in_water", "set_block_property":{ "phantom:waterlogged": true } }, { "condition":"!q.is_in_water", "set_block_property":{ "phantom:waterlogged": false } }...we should be able to do something with that easily in our permutations. I'm filing this as a bug because Minecraft is not just a game that takes place in air. 1/3 of the game is underwater. And you cannot place ANY custom underwater block without an air pocket surrounding it. unless you add server scripting dependencies and make some absolutely horrible looking code. Get this fixed before you take it out of experimental. Thanks you for your considerations.
In summary, where is the missing spec "minecraft:transparent:{}," on custom blocks so they can waterlog?
Adding custom blocks is becoming a mainstream feature of Minecraft. Here is an omission in the block spec that allows for waterlogging a custom block. The developer has no way to set the "transparent" property in the metadata using a component. Here is a typical full block metadata from Mojang:
{ "id": 252, "displayName": "Concrete Powder", "name": "concrete_powder", "hardness": 0.5, "stackSize": 64, "diggable": true, "boundingBox": "block", "material": "dirt", "variations": [ { "metadata": 0, "displayName": "White Concrete Powder" }, (...) { "metadata": 15, "displayName": "Black Concrete Powder" } ], "drops": [ { "drop": 252 } ], "transparent": false, "emitLight": 0, "filterLight": 15, "resistance": 0.5 },and here is a block you can waterlog:
{ "id": 205, "displayName": "Purpur Slab", "name": "purpur_slab", "hardness": 2, "stackSize": 64, "diggable": true, "boundingBox": "block", "material": "rock", "variations": [ { "metadata": 0, "displayName": "Purpur Slab", "description": "Lower half" }, { "metadata": 8, "displayName": "Purpur Slab", "description": "Upper half" } ], "harvestTools": { "257": true, "270": true, "274": true, "278": true, "285": true }, "drops": [ { "drop": { "id": 44, "metadata": 0 } } ], "transparent": true, "emitLight": 0, "filterLight": 0, "resistance": 6 },If we can query 'is_in_water' (example)
{ "condition":"q.is_in_water", "set_block_property":{ "phantom:waterlogged": true } }, { "condition":"!q.is_in_water", "set_block_property":{ "phantom:waterlogged": false } }...we should be able to do something with that easily in our permutations. I'm filing this as a bug because Minecraft is not just a game that takes place in air. 1/3 of the game is underwater. And you cannot place ANY custom underwater block without an air pocket surrounding it. unless you add server scripting dependencies and make some absolutely horrible looking code. Get this fixed before you take it out of experimental. Thanks you for your considerations.
In summary, where is the missing spec "minecraft:transparent:{}," on custom blocks so they can waterlog?
To recreate: (allay runtime)
"on_interact": { "filters": { // is a player sneaking? working 1.19.63, broken 1.19.70 "all_of": [ {"test":"is_family", "subject":"other", "operator":"equals", "value":"player"}, {"test":"is_sneaking", "subject":"other", "operator":"equals", "value":true} ] }, "event": "demo:sneak_mode", "target": "self" }, "swing": true, "interact_text": "give", "give":trueexpected result and (pre- 1.19.70 update) result: demo:sneak_mode event fires, interactive text appears for game controllers "
player is sneaking"current result: demo:sneak_mode only fires if player is empty handed. After rigorous testing today, I found out the MOLANG query.is_sneaking is returning a value of 0.0 when player is sneaking, but has item in hand. query.is_sneaking returns 1.0 ONLY if player sneaking AND main_hand is empty.
Only main_hand was checked in my testing. is_sneaking Filters in other components were not examined by me. Again, this was using an allay runtime on an entitly
To recreate: (allay runtime)
"on_interact": { "filters": { // is a player sneaking? working 1.19.63, broken 1.19.70 "all_of": [ {"test":"is_family", "subject":"other", "operator":"equals", "value":"player"}, {"test":"is_sneaking", "subject":"other", "operator":"equals", "value":true} ] }, "event": "demo:sneak_mode", "target": "self" }, "swing": true, "interact_text": "give", "give":trueexpected result and (pre- 1.19.70 update) result: demo:sneak_mode event fires, interactive text appears for game controllers "give"
current result: demo:sneak_mode only fires if player is empty handed. After rigorous testing today, I found out the MOLANG query.is_sneaking is returning a value of 0.0 when player is sneaking, but has item in hand. query.is_sneaking returns 1.0 ONLY if player sneaking AND main_hand is empty.
Only main_hand was checked in my testing. is_sneaking Filters in other components were not examined by me. Again, this was using an allay runtime on an entitly
Snowmen point North exclusively while riding
congaline.psd
Expected behavior: splash potion ("oozing", "weaving", "wind_charged", "infested") would not affect entity, as potions are magic.
Actual result: entity gets effect and starts throwing off particles.
Tests: "minecraft:damage_sensor" does not recognize "oozing", "weaving", "wind_charged", or "infested" as damage causes individually.
added new component:
"minecraft:spell_effects": { "remove_effects": ["wind_charged", "weaving", "infested", "oozing"] }entity still takes magic effect from splash potion.
I'll try some "damage_sensor" filters under the "entity_attack" cause and enable the "spell_effects" component from a component group dynamically, as it does not work passively.
"minecraft:damage_sensor": { "cause": "magic", "damage": false }...should block these effects
.Expected behavior: splash potion ("oozing", "weaving", "wind_charged", "infested") would not affect entity, as potions are magic.
Actual result: entity gets effect and starts throwing off particles.
Tests: "minecraft:damage_sensor" does not recognize "oozing", "weaving", "wind_charged", or "infested" as damage causes individually.
added new component:
"minecraft:spell_effects": { "remove_effects": ["wind_charged", "weaving", "infested", "oozing"] }entity still takes magic effect from splash potion.
I'll try some "damage_sensor" filters under the "entity_attack" cause and enable the "spell_effects" component from a component group dynamically, as it does not work passively.
"minecraft:damage_sensor": { "cause": "magic", "damage": false }...should block these effects natively without this tedious work around process.
Expected behavior: splash potion ("oozing", "weaving", "wind_charged", "infested") would not affect entity, as potions are magic.
Actual result: entity gets effect and starts throwing off particles.
Tests: "minecraft:damage_sensor" does not recognize "oozing", "weaving", "wind_charged", or "infested" as damage causes individually.
added new component:
"minecraft:spell_effects": { "remove_effects": ["wind_charged", "weaving", "infested", "oozing"] }entity still takes magic effect from splash potion.
I'll try some "damage_sensor" filters under the "entity_attack" cause and enable the "spell_effects" component from a component group dynamically, as it does not work passively.
"minecraft:damage_sensor": { "cause": "magic", "damage": false }...should block these NEW effects natively without this tedious work around process.
Expected behavior: splash potion ("oozing", "weaving", "wind_charged", "infested") would not affect entity, as potions are magic.
Actual result: entity gets effect and starts throwing off particles.
Tests: "minecraft:damage_sensor" does not recognize "oozing", "weaving", "wind_charged", or "infested" as damage causes individually.
added new component:
"minecraft:spell_effects": { "remove_effects": ["wind_charged", "weaving", "infested", "oozing"] }entity still takes magic effect from splash potion.
I'll try some "damage_sensor" filters under the "entity_attack" cause and enable the "spell_effects" component from a component group dynamically, as it does not work passively. That said...
"minecraft:damage_sensor": { "cause": "magic", "damage": false }...should block these NEW effects natively without this tedious work around process.
upon trying to overwrite the "minecraft:wind_charge_projectile" to add the following attributes to the projectile component (noted in code):
{ "format_version": "1.21.0", "minecraft:entity": { "description": { "identifier": "minecraft:wind_charge_projectile", "is_spawnable": false, "is_summonable": false }, "components": { "minecraft:wind_burst": { "radius": 1.2, "particle_effect": "wind_burst", "sound_effect": "wind_charge.burst", "knockback_scaling": 1.1 }, "minecraft:collision_box": { "width": 0.3125, "height": 0.3125 }, "minecraft:projectile": { "on_hit": { "impact_damage": { "damage": 1, "knockback": true }, "remove_on_hit": {} }, "power": 1.0, "gravity": 0.00, "inertia": 1.0, "liquid_inertia": 1.0, "uncertainty_base": 1.0, "uncertainty_multiplier": 0.0, "reflect_on_hurt": true, "multiple_targets": false, // phantom frame golem edit // taken from blaze "anchor": 2, "offset": [ 0, 0.5, 0 ], // ----------------------- "ignored_entities": [ "ender_crystal", "wind_charge_projectile", "breeze_wind_charge_projectile" ] }, "minecraft:physics": { }, "minecraft:pushable": { "is_pushable": false, "is_pushable_by_piston": true }, "minecraft:conditional_bandwidth_optimization": { "default_values": { "max_optimized_distance": 80.0, "max_dropped_ticks": 7, "use_motion_prediction_hints": true } }, "minecraft:type_family": { "family": ["wind_charge", "wind_charge_projectile"] } } } }I was met with the following error.
[Actor][error]-1.21 | actor_definitions | C:/Users/seeit/AppData/Local/Packages/Microsoft.MinecraftUWP_8wekyb3d8bbwe/LocalState/games/com.mojang/development_behavior_packs/Phantom_Frames_BP_DEV | minecraft:wind_charge_projectile | minecraft:entity | components | minecraft:wind_burst is not available in non-vanilla content
[Actor][error]-1.21 | actor_definitions | C:/Users/seeit/AppData/Local/Packages/Microsoft.MinecraftUWP_8wekyb3d8bbwe/LocalState/games/com.mojang/development_behavior_packs/Phantom_Frames_BP_DEV | minecraft:wind_charge_projectile | minecraft:entity | ERROR: Entity 'minecraft:wind_charge_projectile' failed to load from JSON
which means I cannot correct the positioning of my add-on entity shooting out the wind charge from its feet. Mojang will have to fix it.
The new block definitions/aliases for coral and dead corals are thrown as errors in 1.21.0 when used in Add-on component "minecraft:inside_block_notifier": Errors are as follows:
{{[Json][error]-1.21 | actor_definitions | C:/Users/seeit/AppData/Local/Packages/Microsoft.MinecraftUWP_8wekyb3d8bbwe/LocalState/games/com.mojang/development_behavior_packs/Stained_Frames_BP | stained:frame | minecraft:entity | components | minecraft:inside_block_notifier | block_list | 'minecraft:brain_coral_block' is not a valid block type, and is not being added to InsideBlockNotifierComponent's watch list.
[Json][error]-1.21 | actor_definitions | C:/Users/seeit/AppData/Local/Packages/Microsoft.MinecraftUWP_8wekyb3d8bbwe/LocalState/games/com.mojang/development_behavior_packs/Stained_Frames_BP | stained:frame | minecraft:entity | components | minecraft:inside_block_notifier | block_list | 'minecraft:bubble_coral_block' is not a valid block type, and is not being added to InsideBlockNotifierComponent's watch list.
[Json][error]-1.21 | actor_definitions | C:/Users/seeit/AppData/Local/Packages/Microsoft.MinecraftUWP_8wekyb3d8bbwe/LocalState/games/com.mojang/development_behavior_packs/Stained_Frames_BP | stained:frame | minecraft:entity | components | minecraft:inside_block_notifier | block_list | 'minecraft:fire_coral_block' is not a valid block type, and is not being added to InsideBlockNotifierComponent's watch list.
[Json][error]-1.21 | actor_definitions | C:/Users/seeit/AppData/Local/Packages/Microsoft.MinecraftUWP_8wekyb3d8bbwe/LocalState/games/com.mojang/development_behavior_packs/Stained_Frames_BP | stained:frame | minecraft:entity | components | minecraft:inside_block_notifier | block_list | 'minecraft:dead_brain_coral_block' is not a valid block type, and is not being added to InsideBlockNotifierComponent's watch list.
[Json][error]-1.21 | actor_definitions | C:/Users/seeit/AppData/Local/Packages/Microsoft.MinecraftUWP_8wekyb3d8bbwe/LocalState/games/com.mojang/development_behavior_packs/Stained_Frames_BP | stained:frame | minecraft:entity | components | minecraft:inside_block_notifier | block_list | 'minecraft:dead_bubble_coral_block' is not a valid block type, and is not being added to InsideBlockNotifierComponent's watch list.
[Json][error]-1.21 | actor_definitions | C:/Users/seeit/AppData/Local/Packages/Microsoft.MinecraftUWP_8wekyb3d8bbwe/LocalState/games/com.mojang/development_behavior_packs/Stained_Frames_BP | stained:frame | minecraft:entity | components | minecraft:inside_block_notifier | block_list | 'minecraft:dead_fire_coral_block' is not a valid block type, and is not being added to InsideBlockNotifierComponent's watch list.}}
The new block definitions/aliases for coral and dead corals are thrown as errors in 1.21.0 when used in Add-on component "minecraft:inside_block_notifier": Here is a sampling - Errors are as follows:
[Json][error]-1.21 | actor_definitions | C:/Users/seeit/AppData/Local/Packages/Microsoft.MinecraftUWP_8wekyb3d8bbwe/LocalState/games/com.mojang/development_behavior_packs/Stained_Frames_BP | stained:frame | minecraft:entity | components | minecraft:inside_block_notifier | block_list | 'minecraft:brain_coral_block' is not a valid block type, and is not being added to InsideBlockNotifierComponent's watch list.
[Json][error]-1.21 | actor_definitions | C:/Users/seeit/AppData/Local/Packages/Microsoft.MinecraftUWP_8wekyb3d8bbwe/LocalState/games/com.mojang/development_behavior_packs/Stained_Frames_BP | stained:frame | minecraft:entity | components | minecraft:inside_block_notifier | block_list | 'minecraft:bubble_coral_block' is not a valid block type, and is not being added to InsideBlockNotifierComponent's watch list.
[Json][error]-1.21 | actor_definitions | C:/Users/seeit/AppData/Local/Packages/Microsoft.MinecraftUWP_8wekyb3d8bbwe/LocalState/games/com.mojang/development_behavior_packs/Stained_Frames_BP | stained:frame | minecraft:entity | components | minecraft:inside_block_notifier | block_list | 'minecraft:fire_coral_block' is not a valid block type, and is not being added to InsideBlockNotifierComponent's watch list.
[Json][error]-1.21 | actor_definitions | C:/Users/seeit/AppData/Local/Packages/Microsoft.MinecraftUWP_8wekyb3d8bbwe/LocalState/games/com.mojang/development_behavior_packs/Stained_Frames_BP | stained:frame | minecraft:entity | components | minecraft:inside_block_notifier | block_list | 'minecraft:dead_brain_coral_block' is not a valid block type, and is not being added to InsideBlockNotifierComponent's watch list.
[Json][error]-1.21 | actor_definitions | C:/Users/seeit/AppData/Local/Packages/Microsoft.MinecraftUWP_8wekyb3d8bbwe/LocalState/games/com.mojang/development_behavior_packs/Stained_Frames_BP | stained:frame | minecraft:entity | components | minecraft:inside_block_notifier | block_list | 'minecraft:dead_bubble_coral_block' is not a valid block type, and is not being added to InsideBlockNotifierComponent's watch list.
[Json][error]-1.21 | actor_definitions | C:/Users/seeit/AppData/Local/Packages/Microsoft.MinecraftUWP_8wekyb3d8bbwe/LocalState/games/com.mojang/development_behavior_packs/Stained_Frames_BP | stained:frame | minecraft:entity | components | minecraft:inside_block_notifier | block_list | 'minecraft:dead_fire_coral_block' is not a valid block type, and is not being added to InsideBlockNotifierComponent's watch list.
To recreate: any entity, add "minecraft:inside_block_notifier" formated for the new named coral blocks, throw errors.
The new block definitions/aliases for coral and dead corals are thrown as errors in 1.21.0 when used in Add-on component "minecraft:inside_block_notifier": Here is a sampling - Errors are as follows:
[Json][error]-1.21 | actor_definitions | C:/Users/seeit/AppData/Local/Packages/Microsoft.MinecraftUWP_8wekyb3d8bbwe/LocalState/games/com.mojang/development_behavior_packs/Stained_Frames_BP | stained:frame | minecraft:entity | components | minecraft:inside_block_notifier | block_list | 'minecraft:brain_coral_block' is not a valid block type, and is not being added to InsideBlockNotifierComponent's watch list.
[Json][error]-1.21 | actor_definitions | C:/Users/seeit/AppData/Local/Packages/Microsoft.MinecraftUWP_8wekyb3d8bbwe/LocalState/games/com.mojang/development_behavior_packs/Stained_Frames_BP | stained:frame | minecraft:entity | components | minecraft:inside_block_notifier | block_list | 'minecraft:bubble_coral_block' is not a valid block type, and is not being added to InsideBlockNotifierComponent's watch list.
[Json][error]-1.21 | actor_definitions | C:/Users/seeit/AppData/Local/Packages/Microsoft.MinecraftUWP_8wekyb3d8bbwe/LocalState/games/com.mojang/development_behavior_packs/Stained_Frames_BP | stained:frame | minecraft:entity | components | minecraft:inside_block_notifier | block_list | 'minecraft:fire_coral_block' is not a valid block type, and is not being added to InsideBlockNotifierComponent's watch list.
[Json][error]-1.21 | actor_definitions | C:/Users/seeit/AppData/Local/Packages/Microsoft.MinecraftUWP_8wekyb3d8bbwe/LocalState/games/com.mojang/development_behavior_packs/Stained_Frames_BP | stained:frame | minecraft:entity | components | minecraft:inside_block_notifier | block_list | 'minecraft:dead_brain_coral_block' is not a valid block type, and is not being added to InsideBlockNotifierComponent's watch list.
[Json][error]-1.21 | actor_definitions | C:/Users/seeit/AppData/Local/Packages/Microsoft.MinecraftUWP_8wekyb3d8bbwe/LocalState/games/com.mojang/development_behavior_packs/Stained_Frames_BP | stained:frame | minecraft:entity | components | minecraft:inside_block_notifier | block_list | 'minecraft:dead_bubble_coral_block' is not a valid block type, and is not being added to InsideBlockNotifierComponent's watch list.
[Json][error]-1.21 | actor_definitions | C:/Users/seeit/AppData/Local/Packages/Microsoft.MinecraftUWP_8wekyb3d8bbwe/LocalState/games/com.mojang/development_behavior_packs/Stained_Frames_BP | stained:frame | minecraft:entity | components | minecraft:inside_block_notifier | block_list | 'minecraft:dead_fire_coral_block' is not a valid block type, and is not being added to InsideBlockNotifierComponent's watch list.
To recreate: any entity, add "minecraft:inside_block_notifier" to components, formatted for the new named coral blocks, throw errors.
warning!! Do Not bulk make items that can overwrite into the ghost bell slot!!! Otherwise, all crafting will stop working. It will look like you are making items and you will consume resources, but no resulting craftable item will be made or visible
This Issue is related to https://bugs.mojang.com/browse/MCPE-52853 but increases the severity to extreme danger as the corruption from ghost bell can stop ALL crafting if bell slot is written into via a crafting table recipe, like what happens when you bulk craft.
This am, emptied entire inventory screen, then made a copy of the world where bug occurred, and one stack of previous made bulk item paper showed up in first slot of hotbar in empty inventory screen. Crafting is again available.
I'm on Xbox One with a default vanilla installation of Minecraft. It's the only game this machine has ever had on it. I've never had a texture pack. It's as pure a default game as you will ever get. This render bug happens if you are near a minecart, you don't need to be riding in it to trigger the visual bug. My observation is the cart model jumps upwards by one block then returns to the rail once the player looks below the midline. There was a different bug that acted similarly that this one replaced. The previous bug was while riding a minecart, if you looked above the midline, the coordinates stopped updating. If you fired an arrow while experiencing the old bug, the arrow flew from the last updated coordinate position. Once the old bug was "fixed" this bug took it's place. Another observation is since this bugs appearance, mobs in the distance appear to teleport on their desired path versus smooth walking as was previous behavior. I believe they are all related.
I'm seeing rails disappear on honey and slime blocks. They are still there because they reappear by moving around and repositioning the player pov. it's a visual bug I'd assume.
On 2 year old world, on Xbox One, I've gone to unexplored chunks and have discovered geodes(with all associated blocks), tuft, dripstone, pointed dripstone. In explored chunks, all new mobs appear. The best tip I have for finding unexplored chunks is fly over an ocean at night. You can see the glow of lichen under the water in new 1.17 chunks. I have searched over 50 sunken ships in new chunks and have not found moss. I have not seen anyone who has posted a video with a found moss block. My concern is older worlds are still getting the old chest contents.
Update: Found Moss Block in bedrock edition. The ship was upright on the bottom of the ocean and complete with masts. It had 3 loot chests, the 3rd chest contained 3 moss blocks. My suggestion is remain persistent, load up on night vision and water breathing potions and keep hunting. Moss blocks are in the update. Just very rare.
I have to agree with the other comments. A button is a redstone component. If consistency and game mechanics matter, you cannot allow spiders to spawn on buttons.
Exact same issue on Xbox One. I'm surprised mojang released this 1.19 version as the stable release. The lag happens every 5 to 16 seconds randomly, the best indication is the game will go silent, all mobs and Redstone freezes, chests don't open, then about 1-2 seconds later, in a burst of actions, the game will catch up with the actions made during the buffer overrun.
Sometimes, blocks are lost, sometimes the player takes fall damage while pilaring up, sometimes blocs on the ground will not be picked up.
I too have a 3 year old world and 1.18 had similar issues just not this bad.
We want to see if the caller, (@s) has an item in inventory, in this case, lime concrete so the game can do something with it.
This works with the example given:
/execute at @s[hasitem= {item=concrete, data=5}] run say lime concretethis doesn't,
/testfor @s[hasitem= {item=concrete, data=5}]If the player has lime concrete, the say command runs. If not, it says "no items matched selector
this is how Mojang put the "/testfor" into the @s target using "hasitem={}", as a selector, so it could easily get the data id. testfor only works when the data id = 0.
I just ran into the same problem. I have an entity that you can give any item to (allay runtime). The allay has give and take on the same left trigger, one when the player has empty hands (take) and one when the player is holding something (give). (which by the way is logically backwards syntax as the allay is the subject of the interaction, but that's another ticket...)
So, I'd like to filter when the entity is empty handed and only allow "give", when the entity is NOT equipped. I'd like to do something different with the left trigger on interact if the entity is equipped already. Short of naming every possible item the entity can receive to check that, in fact, the entity is equipped, which my entity, like the allay, is doing, it makes sense that I could do the opposite in a simple interact filter. I'd want to check for something like "not" in the filter. or null, or empty. Maybe there is a way to do this, but I cant find it. I can do this with any other language. We do it with the query functions. !query.is_baby is valid testing for adult in certain circumstances. What we need is something like this:
"test":"has_equipment",
"domain": "hand",
"subject": "self",
"operator": "<>" (or "!=" or "not" )
"value": ""
This of course means the entity is equipped, and we don't care with what precisely the entity is holding. But the behavior entity won't allow you to filter for empty hands without providing some "namespace:item_name" which has to be an oversight, or its my error and I'm just missing it in the docs.
I would not mind making a reasonable filter using, say, categories, like where I could encompass the entirety of the library or potential equip-able objects but no such library of categories exist, that I can find other than this... https://learn.microsoft.com/en-us/minecraft/creator/reference/content/recipereference/examples/recipetaglist
Anyway, I wanted to clarify the issue, and perhaps suggest this improvement, or I humbly accept that I am missing it.
I'd be happy to send you my add-on so you can observe the issue of waterlogging a block that obviously isn't solid. Sincerely. But this is an add-on I'm developing for commercial sale, and I would need an NDA or some kind of agreement beforehand. I hope you understand. I'd love to help you any way I can. Maybe I can isolate just the block bit of the code in its own addon file when I have time. I'd also like to add I could be horribly wrong about it being a bug, but I have poured over every bit of documentation over the past 2 months and cannot find anything that addresses this issue other than custom java blocks get transparent settings allowing them to waterlog, no problem, and custom bedrock blocks are missing that feature entirely.
There you go. the waterlog failure.
To repeat, open a minecraft test world and activate the add-on.
Take the frame block out of the inventory items or give yourself "seeit360:frame_block" in a command
Create or visit any body of water
place the block in water, and even though the block can detect its in water (by filling the space it leaves as it is interacted with, (with water or air), the block will never waterlog itself. I suspect its that custom blocks have no way to set a waterlogged state, or are missing the transparent feature that java blocks and vanilla Mojang blocks have. I understand there is server side scripting you can add, but it should be a component of all blocks by default.
Thank you for your consideration. I hope this helps the community.
Just a reminder to all that follow in the future and why you should upvote this bug: there CURRENTLY only 4 render methods available to CUSTOM blocks; opaque, double_sided, blend, alpha_test None of these choices are like "entity" and all are not able to waterlog.
There is another related issue with crouching and I'll make a bug report in detail for developers... But it may be related and needs to be linked for any hotfix. MOLANG query.is_sneaking only returns true when players main_hand is EMPTY. If player has anything in hand, query.is_sneaking returns 0.0. I'm really surprised this made it into a release folks.
There is obviously something going on with blocks and entities with an inventory and sneaking. I have an add-on that can demonstrate it clearly, but out of non disclosure stuff, I would only privately send it to the moderator "GoldenHelmet" to review, and not put it here publicly. I don't know if that is acceptable.
Sneaking was nerfed on multiple entities in 1.19.70. hopefully the 1.19.71 hotfix addresses it
I've put another 12 hours into this... as a developer, I understand it could just be me or my code. It isn't. It's not the allay runtime either. after removing the runtime in testing, the problem of not being able to detect when a player is_sneaking with filters or queries if holding an item is a bug.
update: it absolutely could be the allay runtime... I've observed the allay is now showing an open dialog when targeting it and sneaking in an empty experimental world. Issue still exists in 1.19.71
1.19.63 did not show this behavior.
It appeared immediately after 1.19.70 was released. I know many are having issues with sneaking and targeting but I'm confident whatever hotfix comes out will address this issue. I'm sure the developers working on the issue are aware this update was a bit premature and not fully baked. I feel your pain folks.
Your "tag:<namespace>:<name of item>" conundrum is interesting, only I cannot find the API spec indicating you can have more than one colon in recipes ingredients names. Where did you find this usage example?
Please reopen. Problem still exists in 1.19.71. Perhaps that in experimental, when you spawn an allay give them an item and target them while sneaking, you get "open" inventory tip when a controller is connected to PC? This behavior did not exist in 1.19.63. As far as sending you my plug-in, I have moved on, and recoded my add-on to not use is_sneaking. But the bug is legitimate and has been refiled as the allay show inventory "open" dialog. Thank you for your consideration.
I have a 15 second (50mb) video if you want to increase the upload size over 10 MB
nah, Its not my bug. I'm just a reporter trying to help. If someone else wants to do all that effort to upload a video to a private youtube channel just to link it so mojang does not have to bear the storage cost for a 50mb file of the error in *their* product, go for it. I'm moving on. I'm a developer and have my own projects to work on, Just here as a courtesy
understood. but I don't have the bandwidth (time) to create use cases at this point. I've made a simpler example of the allay "open while sneaking" behavior and refiled it here -> MCPE-168748
Have a great day friend.
Nice to see two of my favorite youtubers (FNT and GH) are on this... So If I had a guess, it's an incompatible default behavior combination, in the "minecraft: inventory" component on entities with inventories. MOJANG: Check to see if the flags have been set like this in your runtimes by mistake:
if this is the default setting in MOJANG's code, you'd block interactions because "open" overrides everything, but the inventory is private so nothing can be done by the owner. That's where I'd start to eliminate that component as one of the causes.
Just ran some testing and all crouching interactions to the allay runtime have been removed by devs changing this:
to this:
So technically, I suppose, it's fixed? Just remove all `is_sneaking` interactions... is, well, an interesting tactic. I would have looked for a way to actually fix it, but I guess hiding it so no one can use that interaction on this runtime could be considered a repair. If the door doesn't work, just duct tape it shut. See? fixed.
Anyway, take care. Sincerely. It's a thankless job. I'll see you on discord.gg/Minecraft
Speed of moving item(s) into the inventory does not matter. Focus is stolen, in multiple container grid locations, and defaults cursor back to slot one in the target container. This behavior is also observed when using a mouse to transfer item(s) into any small chest container UI.
Addendum:
To recreate:
1) Set down chest, barrel, enderchest or shulker box (small chest inventory UI)
2) using a controller, rapidly try to fill the small chest inventory from player inventory using double click method (individual items or item stacks does not matter)
Expected result:
Each item or stack in player inventory enters the target container inventory in sequence, while players cursor follows player's chosen selection in player inventory.
Current result:
upon moving item or stack into the 3rd or forth container slot, player cursor focus will jump to slot one in container inventory and player will mis-click, sending whatever is in container slot one back into player inventory. Highly frustrating and easily recreated.
Additional: this focus stealing also happens if trying to double click items from container back into player inventory - container slot 1 will steal focus after the 3rd or 4th group/item moved.
I have only observed this behavior using a controller. Release 1.19.73 does not exhibit this behavior.
Possible reasons for such behavior.
seeing how focus always jumps to container slot 1 in my experiments, I'd say it's enumeration + a binding error. Thanks for all your hard work dev teams.
Note from todays(4/19/23) Beta:
MCPE-153909)Without context the filter is??
or is it
So the shortened code looks like
and
Did I get that correct?
still not fully implemented? Lets get on this one... I've tested every potion(drinkable, splash and lingering) as well as every suspicious_stew, ...they work (except for filters in the API noted below).
all of the following FLOWERS resolve to "poppy" (data 0)?
to recreate: copy one of the following 'replaceitem' commands and paste in chat, and then place any 1 tall flower in the players (@s) inventory slot 0. no matter what the flower is, any command listed below will erase it.
inconsistencies: recipes - "red_flower" works in an ingredient array using "data"
{ "format_version": "1.12", "minecraft:recipe_shapeless": { "description": { "identifier": "minecraft:blue_dye_from_cornflower" }, "tags": [ "crafting_table" ], "group": "blue_dye", "ingredients": [ { "item": "minecraft:red_flower", "data": 9 } ], "result": { "item": "minecraft:dye", "data": 18 } } }inconsistencies: "red_flower:<int> works in loot table array using "item" (wandering_trader_trades.json)
inconsistancies:
there is currently no way to use either a command (shown above) or a filter (shown below) in add-on entity to identify alt states of items, or at least it isn't in any documentation publicly available.
UPDATE 6/1/24: there is a filters only solution I found, based on that all minecraft namespace items do not need the 'minecraft:' namespace
Nevermind: my UI interface had not considered the crafter when I wrote it. Please close - this is my issue - not yours - apologies
The snow golems "seat" has been rotated, he points in the correct direction
Here is a snippet of the family types. Skeletons pull in just fine.
I'll send it to Golden Helmet (Mod) via private. If I expose the unreleased addon to the public domain, I lose my copyright. I assure you, this is a legitimate issue and its perplexing (but not game breaking).
Needs reopen - While beta 1.21 was addressed, the 1.21.0 stable release today still is using an item grip, not a tool grip like the stick and blaze rod.
here is side by side comparison of my 3rd party item frame entities which allow me to force the grip on any item or block
Twitter post @TestPattern360
Thanks GH .I'm guessing Spell effect will need to be added to the entity to remove any of these status effects, so I suppose I'll use the entity sensor to trigger the component group removing the Spell effect. Even as a closed report, I'll update this so future devs with a similar assumption will have a solution.
1.21 released without repair to the wind charge projectile errors. Maybe the hotfix ? Golden Helmet nailed the issue with the projectile. That is the issue.
As a developer courtesy... I've got a technique posted on twitter to remove/hide the new 1.21 status effects from a 3rd party entity. Twitter Link @TestPattern360 Cheers!