SmokeyStack
- SmokeyStack
- JIRAUSER686456
- America/New_York
- Yes
- No
MCPE-180112
When loading a world with custom blocks, the game fails to register the blocks. The following gets produced in the content log
19:15:43[Json][error]-block_definitions | C:/Users/USERNAME/AppData/Local/Packages/Microsoft.MinecraftWindowsBeta_8wekyb3d8bbwe/LocalState/games/com.mojang/development_behavior_packs/smokey_bedrock_bp | blocks/ancient_vase.json | upgrade blocks/ancient_vase.json | Final json version '1.19.80' failed to upgrade from document version '1.19.70'
19:15:43[Json][error]
block_definitions | C:/Users/USERNAME/AppData/Local/Packages/Microsoft.MinecraftWindowsBeta_8wekyb3d8bbwe/LocalState/games/com.mojang/development_behavior_packs/smokey_bedrock_bp | blocks/ancient_vase.json | upgrade blocks/ancient_vase.json |> minecraft:block -> components: undefined schemaHow to reproduce:
- Download the mojira.mcpack attached
- Import into Minecraft Preview 1.20.0.24
- Enable Holiday Creator Features
Expected Behaviour:
- The block can be given via commands
Actual Behaviour:
- The block doesn't exist and a content log is produced instead
When loading a world with custom blocks, the game fails to register the blocks. The following gets produced in the content log
19:15:43[Json][error]-block_definitions | C:/Users/USERNAME/AppData/Local/Packages/Microsoft.MinecraftWindowsBeta_8wekyb3d8bbwe/LocalState/games/com.mojang/development_behavior_packs/smokey_bedrock_bp | blocks/ancient_vase.json | upgrade blocks/ancient_vase.json | Final json version '1.19.80' failed to upgrade from document version '1.19.70' 19:15:43[Json][error]block_definitions | C:/Users/USERNAME/AppData/Local/Packages/Microsoft.MinecraftWindowsBeta_8wekyb3d8bbwe/LocalState/games/com.mojang/development_behavior_packs/smokey_bedrock_bp | blocks/ancient_vase.json | upgrade blocks/ancient_vase.json | > minecraft:block -> components: undefined schema
How to reproduce:
- Download the mojira.mcpack attached
- Import into Minecraft Preview 1.20.0.24
- Enable Holiday Creator Features
Expected Behaviour:
- The block can be given via commands
Actual Behaviour:
- The block doesn't exist and a content log is produced instead
With the introduction of Custom Components in 1.20.80.20 Preview, creators are allowed to define their own custom component. However, this doesn't work. This is due to the fact that the json file duplicates each string.
```json
"minecraft:custom_components": [
"changelog:yolo"
]
```
Turns into
```json
"minecraft:custom_components": [
"changelog:yolo",
"changelog:yolo"
]
```
This causes the feature to not work. The attached json and script file can be used to recreate this bug.With the introduction of Custom Components in 1.20.80.20 Preview, creators are allowed to define their own custom component. However, this doesn't work. This is due to the fact that the json file duplicates each string.
"minecraft:custom_components": [ "changelog:yolo" ]Turns into
"minecraft:custom_components": [ "changelog:yolo", "changelog:yolo" ]This causes the feature to not work. The attached json and script file can be used to recreate this bug.
With the introduction of Custom Components in 1.20.80.20 Preview, creators are allowed to define their own custom component. However, this doesn't work. This is due to the fact that the json file duplicates each string.
"minecraft:custom_components": [ "changelog:yolo" ]Turns into
"minecraft:custom_components": [ "changelog:yolo", "changelog:yolo" ]This causes the feature to not work. The attached json and script file can be used to recreate this bug.
Edit: Uploaded a `.mcpack` to easily reproduce this bug.
- Download `mojira.mcpack`
- Import to the Preview 1.20.80.20
- Turn on the content log in the settings -> creator section
- Apply this pack to a new world
- Enable the "Beta APIs" experimental toggle.
You will get a content log error saying the "changelog:yolo" component is defined more than once
With the introduction of Custom Components in 1.20.80.20 Preview, creators are allowed to define their own custom component. However, this doesn't work. This is due to the fact that the json file duplicates each string.
"minecraft:custom_components": [ "changelog:yolo" ]Turns into
"minecraft:custom_components": [ "changelog:yolo", "changelog:yolo" ]This causes the feature to not work. The attached json and script file can be used to recreate this bug.
Edit: Uploaded a `.mcpack` to easily reproduce this bug.
- Download `mojira.mcpack`
- Import to the Preview 1.20.80.20
- Turn on the content log in the settings -> creator section
- Apply this pack to a new world
- Enable the "Beta APIs" experimental toggle.
You will get a content log error saying the "changelog:yolo" component is defined more than once. Additionally, stepping on the custom block does not produce the "Hi from Custom Block" message. The rest of the script works as indicated by the script engine saying "Hi" every 2 secs
In 1.20.80 previews, a new API was added as a wrapper of the structure command to be used in the Script API. However, the rotation configs have a disparity. Attached is a video demonstrating a structure being loaded in all 3 ways(structure block, /structure command, and the new Structure API) in order and all 4 rotations.
Reproduce:
- Download the attached world into Minecraft Preview 1.20.80.21
- Inside this world there is 3 layers labeled with diamond, emerald, and gold blocks
- The diamond block uses the structure block to import the structure, the emerald uses the structure command, the gold uses the scriptevent to communicate with the ScriptAPI
Expectations:
All structures are rotated the same
Observed:
The ScriptAPI rotates differently compared to the other two
According to the [official docs|https://learn.microsoft.com/en-us/minecraft/creator/reference/content/itemreference/examples/itemcomponents/minecraft_damage?view=minecraft-bedrock-stable
,] the "minecraft:damage" component supports an integer type. However, upon further testing, it seems that it uses the following formula:
value = value % 256rather than using the actual value.
Reproduce:
- Download the attached pack below
- Import the pack into Preview 1.20.80.23
- Give yourself the following items:
- mojira:damage_255
- mojira:damage_256
- mojira:damage_257
- Open your inventory and hover over the items
Expected Result:
- mojira:damage_255 should have a "+255 attack damage" tooltip
- mojira:damage_256 should have a "+256 attack damage" tooltip
- mojira:damage_257 should have a "+257 attack damage" tooltip
Actual Result:
- mojira:damage_255 has a "+255 attack damage" tooltip
- mojira:damage_256 has no "attack damage" tooltip
- mojira:damage_257 has a "+1 attack damage" tooltip
mojira.mcpack
According to the [official docs|https://learn.microsoft.com/en-us/minecraft/creator/reference/content/itemreference/examples/itemcomponents/minecraft_damage?view=minecraft-bedrock-stable] the "minecraft:damage" component supports an integer type. However, upon further testing, it seems that it uses the following formula:
rather than using the actual value.
Reproduce:
- Download the attached pack below
- Import the pack into Preview 1.20.80.23
- Give yourself the following items:
- mojira:damage_255
- mojira:damage_256
- mojira:damage_257
- Open your inventory and hover over the items
Expected Result:
- mojira:damage_255 should have a "+255 attack damage" tooltip
- mojira:damage_256 should have a "+256 attack damage" tooltip
- mojira:damage_257 should have a "+257 attack damage" tooltip
Actual Result:
- mojira:damage_
255 has a "+255 attack damage" tooltip- mojira:damage_
256 has no "attack damage" tooltip- mojira:damage_
257 has a "+1attack damage" tooltipUpdate: A Mojira moderator has told me to merge
MCPE-180074into this report. I have updated the description, attachements, and title to reflect this mergeAccording to the [official docs|https://learn.microsoft.com/en-us/minecraft/creator/reference/content/itemreference/examples/itemcomponents/minecraft_damage?view=minecraft-bedrock-stable] the "minecraft:damage" component supports an integer type. However, upon further testing, it seems that it uses the following formula:
value = value % 256rather than using the actual value.
More so, the component seems to be using a signed 16-bit integer which causes unexpected/unwanted behaviour. This causes certain ranges of values to appear as negative which causes the Bedrock Engine to think the value is a negative number, even if the value is a positive number. This occurs due to the 2's complements for 16-bit integer. The negative ranges formula is, inclusive beginning and exclusive ending where x can be any arbitrary number.
[256*(256x+128), 256*(256(x+1)))As an example, if x is 0, the range for negative values are [32768, 65536) which the below reproduction method below supports
Reproduce:
- Download the attached pack below
- Import the pack into Preview 1.20.80.23
- Give yourself the following items:
- mojira:damage_255
- mojira:damage_256
- mojira:damage_257
- mojira:damage_32767
- mojira:damage_32768
- mojira:damage_32769
- mojira:damage_65536
- Open your inventory and hover over the items
Expected Result:
- mojira:damage_255 should have a "+255 attack damage" tooltip
- mojira:damage_256 should have a "+256 attack damage" tooltip
- mojira:damage_257 should have a "+257 attack damage" tooltip
- mojira:damage_32767 should have a "+255 attack damage" tooltip
- mojira:damage_32768 should have no "attack damage" tooltip
- mojira:damage_32769 should have a "+1 attack damage" tooltip
- mojira:damage_65536 should have no "attack damage" tooltip
Actual Result:
- mojira:damage_255 has a "+255 attack damage" tooltip
- mojira:damage_256 has no "attack damage" tooltip
- mojira:damage_257 has a "+1 attack damage" tooltip
- mojira:damage_32767 has a "+255 attack damage" tooltip. The item does parse correctly.
- mojira:damage_32768 throws a content log error. The item does not parse correctly thus rendering the item broken.
- mojira:damage_32769 throws a content log error. The item does not parse correctly thus rendering the item broken.
- mojira:damage_65536 has no "attack damage" tooltip. The item does parse correctly.
"minecraft:damage" component valueuses a modulus formula"minecraft:damage" component value has unexpected integer behaviour
Update: A Mojira moderator has told me to merge
MCPE-180074into this report. I have updated the description, attachements, and title to reflect this mergeAccording to the official docs the "minecraft:damage" component supports an integer type. However, upon further testing, it seems that it uses the following formula:
value = value % 256rather than using the actual value.
More so, the component seems to be using a signed 16-bit integer which causes unexpected/unwanted behaviour. This causes certain ranges of values to appear as negative which causes the Bedrock Engine to think the value is a negative number, even if the value is a positive number. This occurs due to the 2's complements for 16-bit integer. The negative ranges formula is, inclusive beginning and exclusive ending where x can be any arbitrary number.
[256*(256x+128), 256*(256(x+1)))As an example, if x is 0, the range for negative values are [32768, 65536) which the below reproduction method below supports
Reproduce:
- Download the attached pack below
- Import the pack into Preview 1.2
0.80.23- Give yourself the following items:
- mojira:damage_255
- mojira:damage_256
- mojira:damage_257
- mojira:damage_32767
- mojira:damage_32768
- mojira:damage_32769
- mojira:damage_65536
- Open your inventory and hover over the items
Expected Result:
- mojira:damage_255 should have a "+255 attack damage" tooltip
- mojira:damage_256 should have a "+256 attack damage" tooltip
- mojira:damage_257 should have a "+257 attack damage" tooltip
- mojira:damage_32767 should have a "+255 attack damage" tooltip
- mojira:damage_32768 should have no "attack damage" tooltip
- mojira:damage_32769 should have a "+1 attack damage" tooltip
- mojira:damage_65536 should have no "attack damage" tooltip
Actual Result:
- mojira:damage_255 has a "+255 attack damage" tooltip
- mojira:damage_256 has no "attack damage" tooltip
- mojira:damage_257 has a "+1 attack damage" tooltip
- mojira:damage_32767 has a "+255 attack damage" tooltip. The item does parse correctly.
- mojira:damage_32768 throws a content log error. The item does not parse correctly thus rendering the item broken.
- mojira:damage_32769 throws a content log error. The item does not parse correctly thus rendering the item broken.
- mojira:damage_65536 has no "attack damage" tooltip. The item does parse correctly.
Update: A Mojira moderator has told me to merge
MCPE-180074into this report. I have updated the description, attachements, and title to reflect this mergeAccording to the official docs the "minecraft:damage" component supports an integer type. However, upon further testing, it seems that it uses the following formula:
value = value % 256rather than using the actual value.
More so, the component seems to be using a signed 16-bit integer which causes unexpected/unwanted behaviour. This causes certain ranges of values to appear as negative which causes the Bedrock Engine to think the value is a negative number, even if the value is a positive number. This occurs due to the 2's complements for 16-bit integer. The negative ranges formula is, inclusive beginning and exclusive ending where x can be any arbitrary number.
[256*(256x+128), 256*(256(x+1)))As an example, if x is 0, the range for negative values are [32768, 65536) which the below reproduction method below supports
Reproduce:
- Download the attached pack below(As of 27/08/2024, I have attached an updated version to keep the item format and min engine version to 1.21.30)
- Import the pack into Preview 1.21.30.24
- Give yourself the following items:
- mojira:damage_255
- mojira:damage_256
- mojira:damage_257
- mojira:damage_32767
- mojira:damage_32768
- mojira:damage_32769
- mojira:damage_65536
- Open your inventory and hover over the items
Expected Result:
- mojira:damage_255 should have a "+255 attack damage" tooltip
- mojira:damage_256 should have a "+256 attack damage" tooltip
- mojira:damage_257 should have a "+257 attack damage" tooltip
- mojira:damage_32767 should have a "+255 attack damage" tooltip
- mojira:damage_32768 should have no "attack damage" tooltip
- mojira:damage_32769 should have a "+1 attack damage" tooltip
- mojira:damage_65536 should have no "attack damage" tooltip
Actual Result:
- mojira:damage_255 has a "+255 attack damage" tooltip
- mojira:damage_256 has no "attack damage" tooltip
- mojira:damage_257 has a "+1 attack damage" tooltip
- mojira:damage_32767 has a "+255 attack damage" tooltip. The item does parse correctly.
- mojira:damage_32768 throws a content log error. The item does not parse correctly thus rendering the item broken.
- mojira:damage_32769 throws a content log error. The item does not parse correctly thus rendering the item broken.
- mojira:damage_65536 has no "attack damage" tooltip. The item does parse correctly.
According to the [official docs|https://learn.microsoft.com/en-us/minecraft/creator/reference/content/itemreference/examples/itemcomponents/minecraft_damage?view=minecraft-bedrock-stable] the "minecraft:damage" component supports an integer type. However, upon further testing, it seems to be using a signed 16-bit integer. This causes certain ranges of values to appear as negative which causes the Bedrock Engine to think the value is a negative number, even if the value is a positive number.
This occurs due to the 2's complements for 16-bit integer. The negative ranges forumal is, inclusive beginning and exclusive ending where x can be any arbitrary number.
[256*(256x+128), 256*(256(x+1)))As an example, if x is 1, the range is [
Reproduce:
- Download the attached pack below
- Import the pack into Preview 1.20.80.23
- Enable the Content Log GUI by going to Settings > Creator > Enable Content Log GUI
- Give yourself the following items:
- mojira:damage_32767
- mojira:damage_32768
- mojira:damage_32769
- mojira:damage_65536
- Open your inventory and hover over the items
Expected Result:
- mojira:damage_32767 should have a "+255 attack damage" tooltip due to a related bug(MCPE-180073)
- mojira:damage_32768 should have no "attack damage" tooltip due to a related bug(MCPE-180073)
- mojira:damage_32769 should have a "+1 attack damage" tooltip due to a related bug(MCPE-180073)
- mojira:damage_32769 should have no "attack damage" tooltip due to a related bug(MCPE-180073)
Actual Result:
- mojira:damage_32767 has a "+255 attack damage" tooltip. The item does parse correctly.
- mojira:damage_32768 throws a content log error. The item does not parse correctly thus rendering the item broken.
- mojira:damage_32769 throws a content log error. The item does not parse correctly thus rendering the item broken.
- mojira:damage_65536 has no "attack damage" tooltip. The item does parse correctly.
- For the items that do not parse correctly, a message in the Content Log should appear matching the screenshot attached below
According to the [official docs|https://learn.microsoft.com/en-us/minecraft/creator/reference/content/itemreference/examples/itemcomponents/minecraft_damage?view=minecraft-bedrock-stable] the "minecraft:damage" component supports an integer type. However, upon further testing, it seems to be using a signed 16-bit integer. This causes certain ranges of values to appear as negative which causes the Bedrock Engine to think the value is a negative number, even if the value is a positive number.
This occurs due to the 2's complements for 16-bit integer. The negative ranges forumal is, inclusive beginning and exclusive ending where x can be any arbitrary number.
[256*(256x+128), 256*(256(x+1)))As an example, if x is 1, the range is [
Reproduce:
- Download the attached pack below
- Import the pack into Preview 1.20.80.23
- Enable the Content Log GUI by going to Settings > Creator > Enable Content Log GUI
- Give yourself the following items:
- mojira:damage_32767
- mojira:damage_32768
- mojira:damage_32769
- mojira:damage_65536
- Open your inventory and hover over the items
Expected Result:
- mojira:damage_32767 should have a "+255 attack damage" tooltip due to a related bug(MCPE-180073)
- mojira:damage_32768 should have no "attack damage" tooltip due to a related bug(MCPE-180073)
- mojira:damage_32769 should have a "+1 attack damage" tooltip due to a related bug(MCPE-180073)
- mojira:damage_32769 should have no "attack damage" tooltip due to a related bug(MCPE-180073)
Actual Result:
- mojira:damage_32767 has a "+255 attack damage" tooltip. The item does parse correctly.
- mojira:damage_32768 throws a content log error. The item does not parse correctly thus rendering the item broken.
- mojira:damage_32769 throws a content log error. The item does not parse correctly thus rendering the item broken.
- mojira:damage_65536 has no "attack damage" tooltip. The item does parse correctly.
- For the items that do not parse correctly, a message in the Content Log should appear matching the screenshot attached below
According to the [official docs|https://learn.microsoft.com/en-us/minecraft/creator/reference/content/itemreference/examples/itemcomponents/minecraft_damage?view=minecraft-bedrock-stable] the "minecraft:damage" component supports an integer type. However, upon further testing, it seems to be using a signed 16-bit integer. This causes certain ranges of values to appear as negative which causes the Bedrock Engine to think the value is a negative number, even if the value is a positive number.
This occurs due to the 2's complements for 16-bit integer. The negative ranges forumal is, inclusive beginning and exclusive ending where x can be any arbitrary number.
[256*(256x+128), 256*(256(x+1)))As an example, if x is 0, the range for negative values are [32768, 65536) which the below reproduction method below supports
Reproduce:
- Download the attached pack below
- Import the pack into Preview 1.20.80.23
- Enable the Content Log GUI by going to Settings > Creator > Enable Content Log GUI
- Give yourself the following items:
- mojira:damage_32767
- mojira:damage_32768
- mojira:damage_32769
- mojira:damage_65536
- Open your inventory and hover over the items
Expected Result:
- mojira:damage_32767 should have a "+255 attack damage" tooltip due to a related bug(MCPE-180073)
- mojira:damage_32768 should have no "attack damage" tooltip due to a related bug(MCPE-180073)
- mojira:damage_32769 should have a "+1 attack damage" tooltip due to a related bug(MCPE-180073)
- mojira:damage_32769 should have no "attack damage" tooltip due to a related bug(MCPE-180073)
Actual Result:
- mojira:damage_32767 has a "+255 attack damage" tooltip. The item does parse correctly.
- mojira:damage_32768 throws a content log error. The item does not parse correctly thus rendering the item broken.
- mojira:damage_32769 throws a content log error. The item does not parse correctly thus rendering the item broken.
- mojira:damage_65536 has no "attack damage" tooltip. The item does parse correctly.
- For the items that do not parse correctly, a message in the Content Log should appear matching the screenshot attached below
According to the [official docs|https://learn.microsoft.com/en-us/minecraft/creator/reference/content/itemreference/examples/itemcomponents/minecraft_damage?view=minecraft-bedrock-stable] the "minecraft:damage" component supports an integer type. However, upon further testing, it seems to be using a signed 16-bit integer. This causes certain ranges of values to appear as negative which causes the Bedrock Engine to think the value is a negative number, even if the value is a positive number.
This occurs due to the 2's complements for 16-bit integer. The negative ranges for
umalis, inclusive beginning and exclusive ending where x can be any arbitrary number.[256*(256x+128), 256*(256(x+1)))As an example, if x is 0, the range for negative values are [32768, 65536) which the below reproduction method below supports
Reproduce:
- Download the attached pack below
- Import the pack into Preview 1.20.80.23
- Enable the Content Log GUI by going to Settings > Creator > Enable Content Log GUI
- Give yourself the following items:
- mojira:damage_32767
- mojira:damage_32768
- mojira:damage_32769
- mojira:damage_65536
- Open your inventory and hover over the items
Expected Result:
- mojira:damage_32767 should have a "+255 attack damage" tooltip due to a related bug(MCPE-180073)
- mojira:damage_32768 should have no "attack damage" tooltip due to a related bug(MCPE-180073)
- mojira:damage_32769 should have a "+1 attack damage" tooltip due to a related bug(MCPE-180073)
- mojira:damage_32769 should have no "attack damage" tooltip due to a related bug(MCPE-180073)
Actual Result:
- mojira:damage_32767 has a "+255 attack damage" tooltip. The item does parse correctly.
- mojira:damage_32768 throws a content log error. The item does not parse correctly thus rendering the item broken.
- mojira:damage_32769 throws a content log error. The item does not parse correctly thus rendering the item broken.
- mojira:damage_65536 has no "attack damage" tooltip. The item does parse correctly.
- For the items that do not parse correctly, a message in the Content Log should appear matching the screenshot attached below
According to the [official docs|https://learn.microsoft.com/en-us/minecraft/creator/reference/content/itemreference/examples/itemcomponents/minecraft_damage?view=minecraft-bedrock-stable] the "minecraft:damage" component supports an integer type. However, upon further testing, it seems to be using a signed 16-bit integer. This causes certain ranges of values to appear as negative which causes the Bedrock Engine to think the value is a negative number, even if the value is a positive number.
This occurs due to the 2's complements for 16-bit integer. The negative ranges formula is, inclusive beginning and exclusive ending where x can be any arbitrary number.
[256*(256x+128), 256*(256(x+1)))As an example, if x is 0, the range for negative values are [32768, 65536) which the below reproduction method below supports
Reproduce:
- Download the attached pack below
- Import the pack into Preview 1.20.80.23
- Enable the Content Log GUI by going to Settings > Creator > Enable Content Log GUI
- Give yourself the following items:
- mojira:damage_32767
- mojira:damage_32768
- mojira:damage_32769
- mojira:damage_65536
- Open your inventory and hover over the items
Expected Result:
- mojira:damage_32767 should have a "+255 attack damage" tooltip due to a related bug(MCPE-180073)
- mojira:damage_32768 should have no "attack damage" tooltip due to a related bug(MCPE-180073)
- mojira:damage_32769 should have a "+1 attack damage" tooltip due to a related bug(MCPE-180073)
- mojira:damage_32769 should have no "attack damage" tooltip due to a related bug(MCPE-180073)
Actual Result:
- mojira:damage_32767 has a "+255 attack damage" tooltip. The item does parse correctly.
- mojira:damage_32768 throws a content log error. The item does not parse correctly thus rendering the item broken.
- mojira:damage_32769 throws a content log error. The item does not parse correctly thus rendering the item broken.
- mojira:damage_65536 has no "attack damage" tooltip. The item does parse correctly.
- For the items that do not parse correctly, a message in the Content Log should appear matching the screenshot attached below
According to the official docs the "minecraft:durability" component supports an integer type for its "max_durability". However, upon further testing, it seems to be using a signed 16-bit integer. This causes certain ranges of values to appear as negative which causes the Bedrock Engine to think the value is a negative number, even if the value is a positive number.
This occurs due to the 2's complements for 16-bit integer. The negative ranges formula is, inclusive beginning and exclusive ending where x can be any arbitrary number.
[256*(256x+128), 256*(256(x+1)))As an example, if x is 0, the range for negative values are [32768, 65536) which the below reproduction method below supports
Steps to reproduce:
- Download and import the attached pack: mojira.mcpack
- Create/open a world with the add-on and the "Beta APIs" experimental toggle enabled
- Run
/give @s mojira:durability_32767 /give @s mojira:durability_32768 /give @s mojira:durability_32769 /give @s mojira:durability_65535 /give @s mojira:durability_65536 /give @s mojira:durability_65537- Run /scriptevent test:test. For ease of use, in the video attached, I have a command block that runs execute as @a run scriptevent test:test which achieves the same result
Expected Result:
- mojira:durability_32767 should have "32767" max durability
- mojira:durability_32768 should have "32768" max durability
- mojira:durability_32769 should have "32769" max durability
- mojira:durability_65535 should have "65535" max durability
- mojira:durability_65536 should have "65536" max durability
- mojira:durability_65537 should have "65537" max durability
Actual Result:
- mojira:durability_32767 has "32767" max durability
- mojira:durability_32768 has "-32768" max durability
- mojira:durability_32769 has "-32767" max durability
- mojira:durability_65535 has "-1" max durability
- mojira:durability_65536 has "0" max durability
- mojira:durability_65537 has "1" max durability
According to the official docs the "minecraft:durability" component supports an integer type for its "max_durability". However, upon further testing, it seems to be using a signed 16-bit integer. This causes certain ranges of values to appear as negative which causes the Bedrock Engine to think the value is a negative number, even if the value is a positive number.
This occurs due to the 2's complements for 16-bit integer. The negative ranges formula is, inclusive beginning and exclusive ending where x can be any arbitrary number.
[256*(256x+128), 256*(256(x+1)))As an example, if x is 0, the range for negative values are [32768, 65536) which the below reproduction method below supports
Steps to reproduce:
- Download and import the attached pack(As of 27/08/2024, I have attached an updated version to keep the item format and min engine version to 1.21.30)
- Create/open a world with the add-on
- Run
/give @s mojira:durability_32767 /give @s mojira:durability_32768 /give @s mojira:durability_32769 /give @s mojira:durability_65535 /give @s mojira:durability_65536 /give @s mojira:durability_65537
- Run /scriptevent test:test test. For ease of use, in the video attached, I have a command block that runs execute as @a run scriptevent test:test test which achieves the same result.
Expected Result:
- mojira:durability_32767 should have "32767" max durability
- mojira:durability_32768 should have "32768" max durability
- mojira:durability_32769 should have "32769" max durability
- mojira:durability_65535 should have "65535" max durability
- mojira:durability_65536 should have "65536" max durability
- mojira:durability_65537 should have "65537" max durability
Actual Result:
- mojira:durability_32767 has "32767" max durability
- mojira:durability_32768 has "-32768" max durability
- mojira:durability_32769 has "-32767" max durability
- mojira:durability_65535 has "-1" max durability
- mojira:durability_65536 has "0" max durability
- mojira:durability_65537 has "1" max durability
According to the [official docs|https://learn.microsoft.com/en-us/minecraft/creator/reference/content/itemreference/examples/itemcomponents/minecraft_enchantable?view=minecraft-bedrock-stable] the "minecraft:enchantable" component supports an integer type. However, upon further testing, it seems that it uses the following formula:
value = value % 256rather than using the actual value.
Reproduce:
- Download the attached pack below
- Import the pack into Preview 1.21.0.
20- Give yourself the following items:
- mojira:enchantable_0
- mojira:enchantable_1
- mojira:enchantable_255
- mojira:enchantable_256
- mojira:enchantable_257
- mojira:enchantable_511
- Open your inventory and hover over the items
Expected Result:
- mojira:enchantable_0 should not be enchantable
- mojira:enchantable_1 should be enchantable, low enchants
- mojira:enchantable_255 should be enchantable, high enchants
- mojira:enchantable_256 should be enchantable, high enchants
- mojira:enchantable_257 should be enchantable, high enchants
- mojira:enchantable_511 should be enchantable, high enchants
Actual Result:
- mojira:enchantable_0 is not enchantable
- mojira:enchantable_1 is enchantable, low enchants
- mojira:enchantable_255 is enchantable, high enchants
- mojira:enchantable_256 is not enchantable
- mojira:enchantable_257 is enchantable, low enchants
- mojira:enchantable_511 is enchantable, high enchants
According to the [official docs|https://learn.microsoft.com/en-us/minecraft/creator/reference/content/itemreference/examples/itemcomponents/minecraft_enchantable?view=minecraft-bedrock-stable] the "minecraft:enchantable" component supports an integer type. However, upon further testing, it seems that it uses the following formula:
value = value % 256rather than using the actual value.
Reproduce:
- Download the attached pack below(As of 27/08/2024, I have attached an updated version to keep the item format and min engine version to 1.21.30)
- Import the pack into Preview 1.21.30.34
- Give yourself the following items:
- mojira:enchantable_0
- mojira:enchantable_1
- mojira:enchantable_255
- mojira:enchantable_256
- mojira:enchantable_257
- mojira:enchantable_511
- Open your inventory and hover over the items
Expected Result:
- mojira:enchantable_0 should not be enchantable
- mojira:enchantable_1 should be enchantable, low enchants
- mojira:enchantable_255 should be enchantable, high enchants
- mojira:enchantable_256 should be enchantable, high enchants
- mojira:enchantable_257 should be enchantable, high enchants
- mojira:enchantable_511 should be enchantable, high enchants
Actual Result:
- mojira:enchantable_0 is not enchantable
- mojira:enchantable_1 is enchantable, low enchants
- mojira:enchantable_255 is enchantable, high enchants
- mojira:enchantable_256 is not enchantable
- mojira:enchantable_257 is enchantable, low enchants
- mojira:enchantable_511 is enchantable, high enchants
![[MCQA] v-weszaj](../../../data/avatars/users/18941.svg){kind=small}
SmokeyStack The world you've uploaded doesn't contain a behavior pack. Could you update it or attach the behavior pack separately?
I can confirm, that custom biomes no longer generate while the C&C toggle is turned on. I tested it out by making my biome generate everywhere(No C&C). But when I create a new world with C&C toggle turned on, it no longer generates.
I can confirm, after updating to 1.19.60, any world whose folder name contains a space, is uneditable.
Workaround: Open your `com.mojang` folder, delete any spaces in the folder's name. Restart Minecraft and you are now able to edit the world in-game.
(y)That was my mistake, I used the wrong extension. Uploaded the same pack with a .mcaddon extension instead.
Can confirm, fixed in Preview 1.20.0.25
Still an issue in version 1.17.31319, build number: 15452163, platform: win10. Something to note is the podiums have lost their little statue to indicate what upgrade it is. Occurs post beacon of the night
Preview 1.20.70.22 - Medium Shadow Quality doesn't seem to be affected. High or Ultra settings however causes the circles to appear once again
As of 1.20.80.20, this bug report is no longer relevant. Mojang has replaced the indicator with a slider instead which is separate from the Shadow Quality settings
As of 1.20.80.21, Mojang has decided to temporarily remove this feature, but should return in an upcoming preview
Custom biomes do not work since 1.18.0 per this bug report: MCPE-100700 . This is a duplicate report in my opinion
I have updated the bug report to include a world download and how to reproduce
@v-weszaj I have updated the report with a new world just in case and the add-on as a separate attachment
Fixed in 1.20.80.22 from my testing!
@GoldenHelmet The issue is the content log does not say it expects a value from [0, 255], all it says it needs to be a value >= 0 per the content log. If that is the case, then the content log error should be updated, if not, then it needs to stop using the modulus formula. Other components such as "minecraft:use_modifiers -> "movement_modifier" have content log errors that specifically states it has to be within [0,1] and doesn't parse the item correctly. It does not just say, "Value must be >= 0" and use a modulus formula.
>I don't understand why you would expect 32767 damage to be functional and yet convert to 255.
I don't expect it to convert to 255, I expect it to have a damage of 32767 but due to this bug, it converts to 255
Fixed in Preview 1.21.0.24 according to changelogs: https://feedback.minecraft.net/hc/en-us/articles/26354480452109-Minecraft-Beta-Preview-1-21-0-24
Can confirm. Via a QNA, a Mojangster stated that only the Trail Ruins and Trial Chambers use the new Jigsaw system that is accessible via the place command and other related APIs.