Rainvay
- ZCYF
- zcyf
- Europe/Stockholm
- Yes
- No
MCPE-169605
MC-261860MCPE-177349MCPE-180054
big cocoa fruit with HD texture
big cocoa fruit with HD texture
If using the HD texture pack, Cocoa fruit will be too big!
big cocoa fruit with HD texture
If there is one banner with the below patterns:
1.Per Bend Sinister
2.Per Bend
3.Per Bend Inverted
4.Per Bend Sinister Inverted
Then we put it on shield, then the patterns above will become upside-down.
Based on the information in the purple panel, we can know the pattern name texts can not match the actually patterns in banner, which means the mistake is in banner instead of shield.
This is because in versions earlier than 1.15, banner patterns used one correct atlas image "banner.tga", however in MCBE 1.15, some banner patterns were incorrectly named when they were splitted in "vanilla_1.15" folder.
In "vanilla_1.15" folder:
The pattern file named "banner_diagonal_left.tga" should be renamed "banner_diagonal_up_left.tga",
The pattern file named"banner_diagonal_up_left.tga" should be renamed "banner_diagonal_left.tga",The pattern file named "banner_diagonal_right.tga" should be renamed "banner_diagonal_up_right.tga",
The pattern file named "banner_diagonal_up_right.tga" should be renamed "banner_diagonal_right.tga".
I know the renamings will break some banner creations crafted in MCBE 1.15-now. I know the developers may have noticed this so they chose keeping the mistake and modified the crafting table recipes to match the mistake. Maybe developers will go on, rename the correct shield pattern files to keep the mistake.
But I really do not think this was a good idea. For texture pack creators, when they convert a Java resource pack into Bedrock, then they will roughly ignore the mistake and will not follow the "vanilla_1.15" to keep it, and this usually leads to bigger trouble.
Please bring back the correct image names, no keeping the mistake! We have to make a better choices, don't we?
If there is one banner with the below patterns:
1.Per Bend Sinister
2.Per Bend
3.Per Bend Inverted
4.Per Bend Sinister Inverted
Then we put it on shield, then the patterns above will become upside-down.
Based on the information in the purple panel, we can know the pattern name texts can not match the actually patterns in banner, which means the mistake is in banner instead of shield.
This is because in versions earlier than 1.15, banner patterns used one correct atlas image "banner.tga", however in MCBE 1.15, some banner patterns were incorrectly named when they were splitted in "vanilla_1.15" folder.
In "vanilla_1.15" folder:
The pattern file named "banner_diagonal_left.tga" should be renamed as "banner_diagonal_up_left.tga",
The pattern file named"banner_diagonal_up_left.tga" should be renamed as "banner_diagonal_left.tga",
The pattern file named "banner_diagonal_right.tga" should be renamed as "banner_diagonal_up_right.tga",
The pattern file named "banner_diagonal_up_right.tga" should be renamed as "banner_diagonal_right.tga".
I know the renamings will break some banner creations crafted in MCBE 1.15-now. I know the developers may have noticed this so they chose keeping the mistake and modified the crafting table recipes to match the mistake. Maybe developers will go on, rename the correct shield pattern files to keep the mistake.
But I really do not think this was a good idea. For texture pack creators, when they convert a Java resource pack into Bedrock, then they will roughly ignore the mistake and will not follow the "vanilla_1.15" to keep it, and this usually leads to bigger trouble.
Please bring back the correct image names, no keeping the mistake! We have to make a better choices, don't we?
When put sniffer egg into an item frame, the size is smaller.
Actually this is because the block images size is 40*32 but the carried texture is only 16*16, not only sniffer egg in vanilla, if one block have its exclusive carried textures, when block resolution is bigger than carried item, the size in item frame will be smaller, when carried item resolution is bigger than block, the size in item frame will be bigger.
If
developer only want to fix the sniffer egg bug, I suggestthat split the textures, make the block resolution equal to the item, like Java Edition.
But I hope developers can fix the essential issues (item frame display size of terrain atlas), becauseif an HD texture pack only includes the carried texture, when put the item into frame, the size will be super large. For example, the sceenshot below: the pack only includes HD candle items but candle blocks are missing.If one block have its exclusive carried textures, when block resolution is bigger than carried item in resource pack, the size in item frame will be smaller, when carried item resolution is bigger than block, the size in item frame will be bigger.
if an HD texture pack only includes the carried texture, when put the item into frame, the size will be super large. For example, the sceenshot below: the pack only includes HD candle items but candle blocks are missing.
WrongSniffer Egg size in item frameWrong item size when
Wrong item size whenWrong item size in item frame when block resolution is different from carried item in resource pack
20230415123810-1.png
Vanilla end rod particles render wrongly if the particles was occluded by other blend material things like water, slime outer, glass.
My screenshots are referring to the End Rod's particles are always fully visible even behind transparent objects, but not only the end rod particles but all particles using "particle_blend" material, including custom particles by resource pack. (opaque particles use "particle_alpha" material generally which have no bug)
The same problem occurs for all particles using "particle_blend" material.
Some plants in the distance will be rendered brighter after Texture Update
Some plants in the distance will be rendered brighter
Plants related to the bug: grass, fern, tall grass and large fern.
Reason:
After texture update, TGA images below were updated:
1.fern.tga
2.double_plant_fern_bottom.tga
3.double_plant_fern_top.tga
4.tallgrass.tga
5.double_plant_grass_bottom.tga
6.double_plant_grass_top.tga
However, there is a bug in there new TGA files: The transparent part of the images is white, which causes this bug when the images were blured in the distance rendering.
In the classic textures TGA files before texture update, the transparent part of the images is grey, just like the opaque area color.
Bedrock Edition textures updated in 1.10.0. I compared the files in MCBE 1.9 with now. The classic texture is from MCBE 1,9, developer set the grass block top texture as background of grass/fern/tall grass/large fern TGA images, this is for resolve the problem. However when developer make the new vanilla TGA files, they forgot this and make the TGA background white, then if in the distance, the texture will be blurred by shaders, then the brighter background will make the plants brighter, witch caused the bug. Do not use the spyglass to watch them because the textures would not be blurred in the case.
To fix the bug, we must update the 6 TGA files, I have fixed this by myself and I put the ZIP file in attachment.
Some plants in inventory use different green colors
Obviouslythe dye itemscolor use the old color system before 1.12.
The item textures should be updated to match the current colors.Compare the dye items with candle items especially cyan color and light blue color.
Obviously the dye items color use the old color system before 1.12.
The item textures should be updated to match the current colors.
Conduit particles display wrongly, the screenshot can be viewed in attachment.
Current MCBE conduit particles is using the outdated textures from MCJE snapshot 18w15a., we can recognize it as an exclusive feature in MCBE, however its textures can not match the JSON files.
In JSON flies of these particles, including:
- conduit.json
- conduit_absorb.json
- conduit_attack.json
the UV part was written as
...
"uv": {
"texture_width": 128,
"texture_height": 128,
"uv": [ "Math.round(variable.particle_random_2 * 11) * 8", 104 ],
"uv_size": [ 8, 8 ]
}...
the "uv" & "uv_size" means the particle uv size should be 8*8, but in particles.png, they were misplaced as:
In Java Edition snapshot 18w15a, they were placed correctly, as how the particle JSON files written:
Conduit particles display wrongly, the screenshot can be viewed in attachment.
Current MCBE conduit particles is using the outdated textures from MCJE snapshot 18w15a., we can recognize it as an exclusive feature in MCBE, however its textures can not match the JSON files.
In JSON flies of these particles, including:
- conduit.json
- conduit_absorb.json
- conduit_attack.json
the UV part was written as
...
"uv": {
"texture_width": 128,
"texture_height": 128,
"uv": [ "Math.round(variable.particle_random_2 * 11) * 8", 104 ],
"uv_size": [ 8, 8 ]
}...
the "uv" & "uv_size" means the particle uv size should be 8*8, but in particles.png, they were misplaced as:
In Java Edition snapshot 18w15a, they were placed correctly, as how the particle JSON files written:
Conduit particles display wrongly, the screenshot can be viewed in attachment.
Current MCBE conduit particles is using the outdated textures from MCJE snapshot 18w15a., we can recognize it as an exclusive feature in MCBE, however its textures can not match the JSON files.
In JSON flies of these particles, including:
- conduit.json
- conduit_absorb.json
- conduit_attack.json
the UV part was written as
...
"uv": {
"texture_width": 128,
"texture_height": 128,
"uv": [ "Math.round(variable.particle_random_2 * 11) * 8", 104 ],
"uv_size": [ 8, 8 ]
}...
the "uv" & "uv_size" means the particle uv size should be 8*8, but in particles.png, they were misplaced as:
In Java Edition snapshot 18w15a, they were placed correctly, as how the particle JSON files written:
Conduit particles display wrongly, the screenshot can be viewed in attachment.
Current MCBE conduit particles is using the outdated textures from MCJE snapshot 18w15a., we can recognize it as an exclusive feature in MCBE, however its textures can not match the JSON files.
In JSON flies of these particles, including:
- conduit.json
- conduit_absorb.json
- conduit_attack.json
the UV part was written as
...
"uv": {
"texture_width": 128,
"texture_height": 128,
"uv": [ "Math.round(variable.particle_random_2 * 11) * 8", 104 ],
"uv_size": [ 8, 8 ]
}...
the "uv" & "uv_size" means the particle uv size should be 8*8, but in particles.png, they were misplaced as:
In Java Edition snapshot 18w15a, they were placed correctly, as how the particle JSON files written:
Conduit particles display wrongly, the screenshot can be viewed in attachment.
Current MCBE conduit particles is using the outdated textures from MCJE snapshot 18w15a., we can recognize it as an exclusive feature in MCBE, however its textures can not match the JSON files.
In JSON f
lies of these particles, including:
- conduit.json
- conduit_absorb.json
- conduit_attack.json
the UV part was written as
...
"uv": {
"texture_width": 128,
"texture_height": 128,
"uv": [ "Math.round(variable.particle_random_2 * 11) * 8", 104 ],
"uv_size": [ 8, 8 ]
}...
the "uv" & "uv_size" means the particle uv size should be 8*8, but in particles.png, they were misplaced as:
In Java Edition snapshot 18w15a, they were placed correctly, as how the particle JSON files written:
Conduit particles display wrongly, the screenshot can be viewed in attachment.
Current MCBE conduit particles is using the outdated textures from MCJE snapshot 18w15a., we can recognize it as an exclusive feature in MCBE, however its textures can not match the JSON files.
In JSON files of these particles, including:
- conduit.json
- conduit_absorb.json
- conduit_attack.json
the UV part was written as
...
"uv": {
"texture_width": 128,
"texture_height": 128,
"uv": [ "Math.round(variable.particle_random_2 * 11) * 8", 104 ],
"uv_size": [ 8, 8 ]
}...
the "uv" & "uv_size" means the particle uv size should be 8*8, but in particles.png, they were misplaced as:
In Java Edition snapshot 18w15a, they were placed correctly, as how the particle JSON files written:
Pitcher Plants and Sniffer Eggs do not support HD resolution textures.
The screenshots below I used a 32*32 texture pack, the texture images was based on vanilla:
I put the texture images I use into attachments.
Pitcher Plants and Sniffer Eggs do not support HD resolution textures.
The screenshots below I used a 32*32 texture pack, the texture images was based on vanilla:
I put the texture images I use into attachments.
Update in Preview 1.20.0.21:
The sniffer egg texture images was splited but the bug is still here, I updated the .mcpack file in attachments
Pitcher Plants and Sniffer Eggs do not support HD resolution textures.
The screenshots below I used a 32*32 texture pack, the texture images was based on vanilla:
I put the texture images I use into attachments.
Update in Preview 1.20.0.21:
The sniffer egg texture images was splited but the bug is still here,
Iupdated the.mcpack file in attachmentsPitcher Plants and Sniffer Eggs do not support HD resolution textures.
The screenshots below I used a 32*32 texture pack, the texture images was based on vanilla:
I put the texture images I use into attachments.
Update in Preview 1.20.0.21:
The sniffer egg texture images was splited but the bug is still here, so I have updated the mcpack file in attachments
Pitcher Plants and Sniffer Eggs do not support HD resolution textures.
The screenshots below I used a 32*32 texture pack, the texture images was based on vanilla:
I put the texture images I use into attachments.
Update in Preview1.20.0.21:The sniffer egg texture images was splited but the bug is still here, so I have updated the mcpack file in attachments
猪笼草和嗅探蛋不支持高清分辨率纹理。
下面的截图我使用了一个 32*32 的材质包，材质图像是基于原版的：
我将我使用的纹理图像放入附件中。
预览版 1.20.0.21 更新：
sniffer egg 纹理图像被分割了，但错误仍然存在，所以我更新了附件中的 mcpack 文件
猪笼草和嗅探蛋不支持高清分辨率纹理。
下面的截图我使用了一个 32*32 的材质包，材质图像是基于原版的：
我将我使用的纹理图像放入附件中。
预览版1.20.0.21更新：sniffer egg 纹理图像被分割了，但错误仍然存在，所以我更新了附件中的 mcpack 文件
Pitcher Plants and Sniffer Eggs do not support HD resolution textures.
The screenshots below I used a 32*32 texture pack, the texture images was based on vanilla:
I put the texture images I use into attachments.
Update in Preview 1.20.0.21:
The sniffer egg texture images was splited but the bug is still here, so I have updated the mcpack file in attachments.
When I use the "Clarity" texture pack from Marketplace, that is a 32*32 resolution pack while vanilla is 16*16, some block items in my hand, their models became bigger than vanilla resolution in both first person and third person.
Here is the block item list that I have found:
Kelp
Sugar Cane
Campfire
Soul Campfire
Brewing Stand
Item Frame
Redstone Repeater
Redstone Comparetor
Hopper
Glowing Item Frame
String
Cauldron
Flower Pot
Chain
When I use the "Clarity" texture pack from Marketplace, that is a 32*32 resolution pack while vanilla is 16*16, some block items in my hand, their models became bigger than vanilla resolution in both first person and third person.
Here is the block item list that I have found:
Kelp
Sugar Cane
Campfire
Soul Campfire
Brewing Stand
Item Frame
Redstone Repeater
Redstone Comparetor
Hopper
Glowing Item Frame
String
Cauldron
Flower Pot
Chain
When I use the "Clarity" texture pack from Marketplace, that is a 32*32 resolution pack while vanilla is 16*16, some block items in my hand, their models became bigger than vanilla resolution in both first person and third person.
Here is the block item list that I have found:
- Kelp
- Sugar Cane
- Campfire
- Soul Campfire
- Brewing Stand
- Item Frame
- Redstone Repeater
- Redstone Comparetor
- Hopper
- Glowing Item Frame
- String
- Cauldron
- Flower Pot
- Chain
I have reported the bug in
MCPE-169734, However the page became invaild because it was identified as a bug of the texture pack issue, but actually the bug is a general bug of game. I just gave an example. ALL of HD texture packs when you use then the bug will happen and only happen in Preview 1.20.0.21.
That is the detail:
When I use HD texture pack, some block items in my hand, their models became bigger than vanilla resolution in both first person and third person.
Here is the block item list that I have found:
- Kelp
- Sugar Cane
- Campfire
- Soul Campfire
- Brewing Stand
- Item Frame
- Redstone Repeater
- Redstone Comparetor
- Hopper
- Glowing Item Frame
- String
- Cauldron
- Flower Pot
- Chain
I have reported the bug in
MCPE-169734, However the page became invaild because it was identified as a bug of the texture pack issue, but actually the bug is a general bug of game. I just gave an example by using a HD pack from Marketplace. ALL of HD texture packs when you use then the bug will happen and only happen in Preview 1.20.0.21.
That is the detail:
When I use HD texture pack, some block items in my hand, their models became bigger than vanilla resolution in both first person and third person.
Here is the block item list that I have found:
- Kelp
- Sugar Cane
- Campfire
- Soul Campfire
- Brewing Stand
- Item Frame
- Redstone Repeater
- Redstone Comparetor
- Hopper
- Glowing Item Frame
- String
- Cauldron
- Flower Pot
- Chain
I have reported the bug in
MCPE-169734, However the page became invaild because it was identified as a bug of the texture pack issue, but actually the bug is a general bug of game. I just gave an example by using an HD pack from Marketplace. ALL of HD texture packs when you use then the bug will happen and only happen in Preview 1.20.0.21.
That is the detail:
When I use HD texture pack, some block items in my hand, their models became bigger than vanilla resolution in both first person and third person.
Here is the block item list that I have found:
- Kelp
- Sugar Cane
- Campfire
- Soul Campfire
- Brewing Stand
- Item Frame
- Redstone Repeater
- Redstone Comparetor
- Hopper
- Glowing Item Frame
- String
- Cauldron
- Flower Pot
- Chain
I have reported the bug in
MCPE-169734, However the page became invaild because it was identified as a bug of the texture pack issue, but actually the bug is a general bug of game. I just gave an example by using an HD pack from Marketplace. ALL of HD texture packs when you use then the bug will happen and only happen in Preview 1.20.0.21.I am an 3rd texture pack creator so I can make sure that this is a game bug instead of resource pack!
That is the detail:
When I use HD texture pack, some block items in my hand, their models became bigger than vanilla resolution in both first person and third person.
Here is the block item list that I have found:
- Kelp
- Sugar Cane
- Campfire
- Soul Campfire
- Brewing Stand
- Item Frame
- Redstone Repeater
- Redstone Comparetor
- Hopper
- Glowing Item Frame
- String
- Cauldron
- Flower Pot
- Chain
I have reported the bug in
MCPE-169734, However the page became invaild because it was identified as a bug of the texture pack issue, but actually the bug is a general bug of game. I just gave an example by using an HD pack from Marketplace. ALL of HD texture packs when you use then the bug will happen and only happen in Preview 1.20.0.21.I am a
n3rd texture pack creator so I can make sure that this is a game bug instead of resource pack!
That is the detail:
When I use HD texture pack, some block items in my hand, their models became bigger than vanilla resolution in both first person and third person.
Here is the block item list that I have found:
- Kelp
- Sugar Cane
- Campfire
- Soul Campfire
- Brewing Stand
- Item Frame
- Redstone Repeater
- Redstone Comparetor
- Hopper
- Glowing Item Frame
- String
- Cauldron
- Flower Pot
- Chain
I have reported the bug in
MCPE-169734, However the page became invaild because it was identified as a bug of the texture pack issue, but actually the bug is a general bug of game. I just gave an example by using an HD pack from Marketplace. ALL of HD texture packs when you use then the bug will happen and only happen in Preview 1.20.0.21.I am a 3rd party texture pack creator so I can make sure that this is a game bug instead of resource pack!
That is the detail:
When I use HD texture pack, some block items in my hand, their models became bigger than vanilla resolution in both first person and third person.
Here is the block item list that I have found:
- Kelp
- Sugar Cane
- Campfire
- Soul Campfire
- Brewing Stand
- Item Frame
- Redstone Repeater
- Redstone Comparetor
- Hopper
- Glowing Item Frame
- String
- Cauldron
- Flower Pot
- Chain
I have reported the bug in
MCPE-169734, However the page became invaild because it was identified as a bug of the texture pack issue, but actually the bug is a general bug of game. I just gave an example by using an HD pack from Marketplace. ALL of HD texture packs when you use then the bug will happen and only happen in Preview 1.20.0.21.I am a 3rd party texture pack creator so I can make sure that this is a game bug instead of resource pack!
That is the detail:
When I use HD texture pack, some block items in my hand, their models became bigger than vanilla resolution in both first person and third person.
Here is the block item list that I have found:
- Kelp
- Sugar Cane
- Campfire
- Soul Campfire
- Brewing Stand
- Item Frame
- Redstone Repeater
- Redstone Comparetor
- Hopper
- Glowing Item Frame
- String
- Cauldron
- Flower Pot
- Chain
I have reported the bug in
MCPE-169734, However the page became invaild because it was identified as a bug of the texture pack issue, but actually the bug is a general bug of game. I just gave an example by using an HD pack from Marketplace. ALL of HD texture packs when you use then the bug will happen and only happen in Preview 1.20.0.21. In addition, the higher resolution of pack for using, the bigger items in your hands will be.I am a 3rd party texture pack creator so I can make sure that this is a game bug instead of resource pack!
That is the detail:
When I use HD texture pack, some block items in my hand, their models became bigger than vanilla resolution in both first person and third person.
Here is the block item list that I have found:
- Kelp
- Sugar Cane
- Campfire
- Soul Campfire
- Brewing Stand
- Item Frame
- Redstone Repeater
- Redstone Comparetor
- Hopper
- Glowing Item Frame
- String
- Cauldron
- Flower Pot
- Chain
I have reported the bug in
MCPE-169734, However the page became invaild because it was identified as a bug of the texture pack issue, but actually the bug is a general bug of game. I just gave an example by using an HD pack from Marketplace. ALL of HD texture packs when you use then the bug will happen and only happen in Preview 1.20.0.21. In addition, the higher resolution of pack for using, the bigger items in your hands will be.I am a 3rd party texture pack creator so I can make sure that this is a game bug instead of resource pack!
That is the detail:
When I use HD texture pack, some block items in my hand, their models became bigger than vanilla resolution in both first person and third person.
Here is the block item list that I have found:
- Kelp
- Sugar Cane
- Campfire
Soul CampfireBrewing StandItem FrameRedstone Repeater- Redstone
Comparetor- Hopper
- Glowing Item Frame
- String
- Cauldron
Flower Pot- Chain
- Warped Fungus on a Stick
- Coal
SnowballI have reported the bug in
MCPE-169734, However the page became invaild because it was identified as a bug of the texture pack issue, but actually the bug is a general bug of game. I just gave an example by using an HD pack from Marketplace. ALL of HD texture packs when you use then the bug will happen and only happen in Preview 1.20.0.21. In addition, the higher resolution of pack for using, the bigger items in your hands will be.I am a 3rd party texture pack creator so I can make sure that this is a game bug instead of resource pack!
That is the detail:
When I use HD texture pack, some block items in my hand, their models became bigger than vanilla resolution in both first person and third person.
Here is the block item list that I have found:
- Kelp
- Sugar Cane
- Campfire
- Chain
- Soul Campfire
- Brewing Stand
- Item Frame
- Redstone Repeater
- Redstone Comparetor
- Hopper
- Glowing Item Frame
- String
- Cauldron
- Cake
- Music disc (Including all variants)
- Nether Sprouts
- Flower Pot
- Chain
- Warped Fungus on a Stick
- Coal
- Charcoal
- Snowball
- Arrow(Including all potion variants)
I have reported the bug in
MCPE-169734, However the page became invaild because it was identified as a bug of the texture pack issue, but actually the bug is a general bug of game. I just gave an example by using an HD pack from Marketplace. ALL of HD texture packs when you use then the bug will happen and only happen in Preview 1.20.0.21. In addition, the higher resolution of pack for using, the bigger items in your hands will be.I am a 3rd party texture pack creator so I can make sure that this is a game bug instead of resource pack!
That is the detail:
When I use HD texture pack, some
blockitems in my hand, their models became bigger than vanilla resolution in both first person and third person.Here is the block item list that I have found:
- Kelp
- Sugar Cane
- Campfire
- Chain
- Soul Campfire
- Brewing Stand
- Item Frame
- Redstone Repeater
- Redstone Comparetor
- Hopper
- Glowing Item Frame
- String
- Cauldron
- Cake
- Music disc (Including all variants)
- Nether Sprouts
- Flower Pot
- Chain
- Warped Fungus on a Stick
- Coal
- Charcoal
- Snowball
- Arrow(Including all potion variants)
I have reported the bug in
MCPE-169734, However the page became invaild because it was identified as a bug of the texture pack issue, but actually the bug is a general bug of game. I just gave an example by using an HD pack from Marketplace. ALL of HD texture packs when you use then the bug will happen and only happen in Preview 1.20.0.21. In addition, the higher resolution of pack for using, the bigger items in your hands will be.I am a 3rd party texture pack creator so I can make sure that this is a game bug instead of resource pack!
Vanilla items are not data-driven so that we can not fix it through resource pack, except using attachable... That is so annoying.
That is the detail:
When I use HD texture pack, some items in my hand, their models became bigger than vanilla resolution in both first person and third person. Meanwhile I also found that the bobing and interactinganimation of the items are different from before.
Here is the block item list that I have found:
- Kelp
- Sugar Cane
- Campfire
- Chain
- Soul Campfire
- Brewing Stand
- Item Frame
- Redstone Repeater
- Redstone Comparetor
- Hopper
- Glowing Item Frame
- String
- Cauldron
- Cake
- Music disc (Including all variants)
- Nether Sprouts
- Flower Pot
- Chain
- Warped Fungus on a Stick
- Coal
- Charcoal
- Snowball
- Arrow (Including all potion variants)
I have reported the bug in
MCPE-169734, However the page became invaild because it was identified as a bug of the texture pack issue, but actually the bug is a general bug of game. I just gave an example by using an HD pack from Marketplace. ALL of HD texture packs when you use then the bug will happen and only happen in Preview 1.20.0.21. In addition, the higher resolution of pack for using, the bigger items in your hands will be.I am a 3rd party texture pack creator so I can make sure that this is a game bug instead of resource pack!
Vanilla items are not data-driven so that we can not fix it through resource pack, except using attachable... That is so annoying.
That is the detail:
When I use HD texture pack, some items in my hand, their models became bigger than vanilla resolution in both first person and third person. Meanwhile I also found that the bobing and interactinganimation of the items are different from before.
Here is the block item list that I have found:
- Kelp
- Sugar Cane
- Campfire
- Chain
- Soul Campfire
- Brewing Stand
- Item Frame
- Redstone Repeater
- Redstone Compar
etor- Hopper
- Glowing Item Frame
- String
- Cauldron
- Cake
- Music disc (Including all variants)
- Nether Sprouts
- Flower Pot
- Chain
- Warped Fungus on a Stick
- Coal
- Charcoal
- Snowball
- Arrow (Including all potion variants)
I have reported the bug in
MCPE-169734, However the page became invaild because it was identified as a bug of the texture pack issue, but actually the bug is a general bug of game. I just gave an example by using an HD pack from Marketplace. ALL of HD texture packs when you use then the bug will happen and only happen in Preview 1.20.0.21. In addition, the higher resolution of pack for using, the bigger items in your hands will be.I am a 3rd party texture pack creator so I can make sure that this is a game bug instead of resource pack!
Vanilla items are not data-driven so that we can not fix it through resource pack, except using attachable... That is so annoying.
That is the detail:
When I use HD texture pack, some items in my hand, their models became bigger than vanilla resolution in both first person and third person. Meanwhile I also found that the bobing and interactinganimation of the items are different from before.
Here is the block item list that I have found:
- Kelp
- Sugar Cane
- Campfire
- Chain
- Soul Campfire
- Brewing Stand
- Item Frame
- Redstone Repeater
- Redstone Comparator
- Hopper
- Glowing Item Frame
- String
- Cauldron
- Cake
- Music disc (Including all variants)
- Nether Sprouts
- Flower Pot
- Chain
- Warped Fungus on a Stick
- Coal
- Charcoal
- Snowball
- Arrow (Including all potion variants)
I have reported the bug in
MCPE-169734, However the page became invaild because it was identified as a bug of the texture pack issue, but actually the bug is a general bug of game. I just gave an example by using an HD pack from Marketplace. ALL of HD texture packs when you use then the bug will happen and only happen in Preview 1.20.0.21. In addition, the higher resolution of pack for using, the bigger items in your hands will be.I am a 3rd party texture pack creator so I can make sure that this is a game bug instead of resource pack!
Vanilla items are not data-driven so that we can not fix it through resource pack, except using attachable... That is so annoying.
That is the detail:
When I use HD texture pack, some items in my hand, their models became bigger than vanilla resolution in both first person and third person. Meanwhile I also found that the bobing and interactinganimation of the items are different from before.
Here is the
blockitem list that I have found:
- Kelp
- Sugar Cane
- Campfire
- Chain
- Soul Campfire
- Brewing Stand
- Item Frame
- Redstone Repeater
- Redstone Comparator
- Hopper
- Glowing Item Frame
- String
- Cauldron
- Cake
- Music disc (Including all variants)
- Nether Sprouts
- Flower Pot
- Chain
- Warped Fungus on a Stick
- Coal
- Charcoal
- Snowball
- Arrow (Including all potion variants)
I have reported the bug in
MCPE-169734, However the page became invaild because it was identified as a bug of the texture pack issue, but actually the bug is a general bug of game. I just gave an example by using an HD pack from Marketplace. ALL of HD texture packs when you use then the bug will happen and only happen in Preview 1.20.0.21. In addition, the higher resolution of pack for using, the bigger items in your hands will be.I am a 3rd party texture pack creator so I can make sure that this is a game bug instead of resource pack!
Vanilla items are not data-driven so that we can not fix it through resource pack, except using attachable... That is so annoying.
That is the detail:
When I use HD texture pack, some items in my hand, their models became bigger than vanilla resolution in both first person and third person. Meanwhile I also found that the bobing and interactinganimation of the items are different from before.
Here is the item list that I have found:
- Kelp
- Sugar Cane
- Campfire
- Chain
- Soul Campfire
- Brewing Stand
- Item Frame
- Redstone Repeater
- Redstone Comparator
- Hopper
- Glowing Item Frame
- String
- Cauldron
- Cake
- Music disc (Including all variants)
- Nether Sprouts
- Flower Pot
- Chain
- Warped Fungus on a Stick
- Coal
- Charcoal
- Snowball
- Arrow (Including all potion variants)
- Apple
- Trial Key
- Wind Charge
Carrieditemmodel of someblocks will be larger when using any HD texture packCarried models of some items will be larger when using any HD texture pack
I have reported the bug in
MCPE-169734, However the page became invaild because it was identified as a bug of the texture pack issue, but actually the bug is a general bug of game. I just gave an example by using an HD pack from Marketplace. ALL of HD texture packs when you use then the bug will happen and only happen in Preview 1.20.0.21. In addition, the higher resolution of pack for using, the bigger items in your hands will be.I am a 3rd party texture pack creator so I can make sure that this is a game bug instead of resource pack!
Vanilla items are not data-driven so that we can not fix it through resource pack, except using attachable... That is so annoying.
That is the detail:
When I use HD texture pack, some items in my hand, their models became bigger than vanilla resolution in both first person and third person. Meanwhile I also found that the bobing and interacting animation of the items are different from before.
Here is the item list that I have found:
- Kelp
- Sugar Cane
- Campfire
- Chain
- Soul Campfire
- Brewing Stand
- Item Frame
- Redstone Repeater
- Redstone Comparator
- Hopper
- Glowing Item Frame
- String
- Cauldron
- Cake
- Music disc (Including all variants)
- Nether Sprouts
- Flower Pot
- Chain
- Warped Fungus on a Stick
- Coal
- Charcoal
- Snowball
- Arrow (Including all potion variants)
- Apple
- Trial Key
- Wind Charge
I have reported the bug in
MCPE-169734, However the page became invaild because it was identified as a bug of the texture pack issue, but actually the bug is a general bug of game. I just gave an example by using an HD pack from Marketplace. ALL of HD texture packs when you use then the bug will happen and only happen in Preview 1.20.0.21. In addition, the higher resolution of pack for using, the bigger items in your hands will be.I am a 3rd party texture pack creator so I can make sure that this is a game bug instead of resource pack!
Vanilla items are not data-driven so that we can not fix it through resource pack, except using attachable... That is so annoying.
That is the detail:
When I use HD texture pack, some items in my hand, their models became bigger than vanilla resolution in both first person and third person. Meanwhile I also found that the bobing and interacting animation of the items are different from before.
Here is the item list that I have found:
- Kelp
- Sugar Cane
- Campfire
ChainSoul CampfireBrewing StandItem Frame- Redstone
Repeater- Redstone Comparator
- Hopper
- Glowing Item Frame
- String
- Cauldron
- Cake
- Music disc (Including all variants)
- Nether Sprouts
- Flower Pot
- Chain
- Warped Fungus on a Stick
- Coal
- Charcoal
- Snowball
- Arrow (Including all potion variants)
- Apple
- Trial Key
- Wind Charge
I have reported the bug in
MCPE-169734, However the page became invaild because it was identified as a bug of the texture pack issue, but actually the bug is a general bug of game. I just gave an example by using an HD pack from Marketplace. ALL of HD texture packs when you use then the bug will happen and only happen in Preview 1.20.0.21. In addition, the higher resolution of pack for using, the bigger items in your hands will be.I am a 3rd party texture pack creator so I can make sure that this is a game bug instead of resource pack!
Vanilla items are not data-driven so that we can not fix it through resource pack, except using attachable... That is so annoying.
That is the detail:
When I use HD texture pack, some items in my hand, their models became bigger than vanilla resolution in both first person and third person. Meanwhile I also found that the bobing and interacting animation of the items are different from before.
Here is the item list that I have found:
- Kelp
- Sugar Cane
- Campfire
- Soul Campfire
- Brewing Stand
- Item Frame
- Redstone Repeater
- Redstone Comparator
- Hopper
- Glowing Item Frame
- String
- Cauldron
- Cake
- Music disc (Including all variants)
- Nether Sprouts
- Flower Pot
- Chain
- Warped Fungus on a Stick
- Coal
- Charcoal
- Snowball
- Arrow (Including all potion variants)
- Apple
- Trial Key
- Wind Charge
I have reported the bug in
MCPE-169734, However the page became invaild because it was identified as a bug of the texture pack issue, but actually the bug is a general bug of game. I just gave an example by using an HD pack from Marketplace. ALL of HD texture packs when you use then the bug will happen and only happen in Preview 1.20.0.21. In addition, the higher resolution of pack for using, the bigger items in your hands will be.I am a 3rd party texture pack creator so I can make sure that this is a game bug instead of resource pack!
Vanilla items are not data-driven so that we can not fix it through resource pack, except using attachable... That is so annoying.
That is the detail:
When I use HD texture pack, some items in my hand, their models became bigger than vanilla resolution in both first person and third person. Meanwhile I also found that the bobing and interacting animation of the items are different from before.
Here is the item list that I have found:
- Kelp
- Sugar Cane
- Campfire
- Soul Campfire
- Brewing Stand
- Item Frame
- Redstone Repeater
- Redstone Comparator
- Hopper
- Glowing Item Frame
- String
- Cauldron
- Cake
- Music disc (Including all variants)
- Nether Sprouts
- Flower Pot
- Chain
- Warped Fungus on a Stick
- Coal
- Charcoal
- Snowball
- Arrow (Including all potion variants)
- Apple
- Trial Key
- Wind Charge
I have reported the bug in
MCPE-169734, However the page became invaild because it was identified as a bug of the texture pack issue, but actually the bug is a general bug of game. I just gave an example by using an HD pack from Marketplace. ALL of HD texture packs when you use then the bug will happen and only happen in Preview 1.20.0.21. In addition, the higher resolution of pack for using, the bigger items in your hands will be.I am a 3rd party texture pack creator so I can make sure that this is a game bug instead of resource pack!
Vanilla items are not data-driven so that we can not fix it through resource pack, except using attachable... That is so annoying.
That is the detail:
When I use HD texture pack, some items in my hand, their models became bigger than vanilla resolution in both first person and third person. Meanwhile I also found that the bobing and interacting animation of the items are different from before.
Here is the item list that I have found:
- Kelp
- Sugar Cane
- Campfire
- Soul Campfire
- Brewing Stand
- Item Frame
- Redstone Repeater
- Redstone Comparator
- Hopper
- Glowing Item Frame
- String
- Cauldron
- Cake
- Music disc (Including all variants)
- Nether Sprouts
- Flower Pot
- Chain
- Warped Fungus on a Stick
- Coal
- Charcoal
- Snowball
- Arrow (Including all potion variants)
- Apple (Added in 1.20.50)
- Trial Key (Added in 1.20.60)
- Wind Charge (Added in 1.20.70)
I have reported the bug in
MCPE-169734, However the page became invaild because it was identified as a bug of the texture pack issue, but actually the bug is a general bug of game. I just gave an example by using an HD pack from Marketplace. ALL of HD texture packs when you use then the bug will happen and only happen in Preview 1.20.0.21. In addition, the higher resolution of pack for using, the bigger items in your hands will be.I am a 3rd party texture pack creator so I can make sure that this is a game bug instead of resource pack!
Vanilla items are not data-driven so that we can not fix it through resource pack, except using attachable... That is so annoying.
That is the detail:
When I use HD texture pack, some items in my hand, their models became bigger than vanilla resolution in both first person and third person. Meanwhile I also found that the bobing and interacting animation of the items are different from before.
Here is the item list that I have found:
- Kelp
- Sugar Cane
- Campfire
- Soul Campfire
- Brewing Stand
- Item Frame
- Redstone Repeater
- Redstone Comparator
- Hopper
- Glowing Item Frame
- String
- Cauldron
- Cake
- Music disc (Including all variants)
- Nether Sprouts
- Flower Pot
- Chain
- Warped Fungus on a Stick
- Coal
- Charcoal
- Snowball
- Arrow (Including all potion variants)
- Apple (Added in 1.20.50)
- Trial Key (Added in 1.20.60)
- Wind Charge (Added in 1.20.70)
- Wolf Armor (Added in 1.21.0)
I have reported the bug in
MCPE-169734, However the page became invaild because it was identified as a bug of the texture pack issue, but actually the bug is a general bug of game. I just gave an example by using an HD pack from Marketplace. ALL of HD texture packs when you use then the bug will happen and only happen in Preview 1.20.0.21. In addition, the higher resolution of pack for using, the bigger items in your hands will be.I am a 3rd party texture pack creator so I can make sure that this is a game bug instead of resource pack!
Vanilla items are not data-driven so that we can not fix it through resource pack, except using attachable... That is so annoying.
That is the detail:
When I use HD texture pack, some items in my hand, their models became bigger than vanilla resolution in both first person and third person. Meanwhile I also found that the bobing and interacting animation of the items are different from before.
Here is the item list that I have found:
- Kelp
- Sugar Cane
- Campfire
- Soul Campfire
- Brewing Stand
- Item Frame
- Redstone Repeater
- Redstone Comparator
- Hopper
- Glowing Item Frame
- String
- Cauldron
- Cake
- Music disc (Including all variants)
- Nether Sprouts
- Flower Pot
- Chain
- Warped Fungus on a Stick
- Coal
- Charcoal
- Snowball
- Arrow (Including all potion variants)
- Apple (Added in 1.20.50)
- Trial Key (Added in 1.20.60)
- Wind Charge (Added in 1.20.70)
- Wolf Armor (Added in 1.21.0)
- Ominous Trial Key (Added in 1.21.0)
I have reported the bug in
MCPE-169734, However the page became invaild because it was identified as a bug of the texture pack issue, but actually the bug is a general bug of game. I just gave an example by using an HD pack from Marketplace. ALL of HD texture packs when you use then the bug will happen and only happen in Preview 1.20.0.21. In addition, the higher resolution of pack for using, the bigger items in your hands will be.I am a 3rd party texture pack creator so I can make sure that this is a game bug instead of resource pack!
Vanilla items are not data-driven so that we can not fix it through resource pack, except using attachable... That is so annoying.
That is the detail:
When I use HD texture pack, some items in my hand, their models became bigger than vanilla resolution in both first person and third person. Meanwhile I also found that the bobing and interacting animation of the items are different from before.
Here is the item list that I have found:
- Kelp
- Sugar Cane
- Campfire
- Soul Campfire
- Brewing Stand
- Item Frame
- Redstone Repeater
- Redstone Comparator
- Hopper
- Glowing Item Frame
- String
- Cauldron
- Cake
- Music disc (Including all variants)
- Nether Sprouts
- Flower Pot
- Chain
- Warped Fungus on a Stick
- Coal
- Charcoal
- Snowball
- Arrow (Including all potion variants)
- Apple (Added in 1.20.50)
- Trial Key (Added in 1.20.60)
- Wind Charge (Added in 1.20.70)
- Wolf Armor (Added in 1.21.0)
- Ominous Trial Key (Added in 1.21.0)
- Bundle (Added in 1.21.30)
The selected slot is missing the bottom two rows of pixels in hotbar.
This is hotbar in Java Edition:
Missing part is actually the second to the bottom row of the images because the bottom one row is beyond the screen, here is the texture image file "widgets.png":
And this is the selected slot in Bedrock:
Of course Bedrock hotbar is higher than in Java so the bottom one row part can be rendered in screen.
Watch the side line, these parts are more opaque or you can say darker but the alpha in hud_screen.json is written as 0.65, this should not happen:
Luckily the images in vanilla is all plack pixels, which will not let the bug expose obviously in vanilla, it just darker.
However the wrose is when you modify the images "hotbar_start_cap.png" or "hotbar_end_cap.png" by resourse pack, when the two images are not totally black, there will be rendered weirder:
For example:
Quadral Texture Pack
Faithful 32x Resource Pack
I was confused by this when I was making a texture pack but I found the reason now.
In vanilla resource pack, there are two JSON files were written by mistake:
"hotbar_start_cap.json" & "hotbar_end_cap.json", the two files should never happen because they are used to describe the base size and nineslice size of images. However the "hotbar_start_cap.png" and "hotbar_end_cap.png" are not need to widen the scale. So the two files are redundant.
The redundant files were written by mistake, which caused the bug, they were written as:
{ "nineslice_size": [ 1, 1, 1, 1 ], "base_size": [ 1, 1, 1, 1 ] }Two files are same.
As we can see the base_size is [ 1, 1, 1, 1 ]. However an image can only use two number for length and width, these are 2D images, not 4D! And the nineslice_size part is redundant.For developer to fix this bug, just remove the two JSON flies.
For resource pack maker, there is a correct JSON code you can copy into the two files in your pack to fix the bug:
{ "base_size": [ 1, 22 ] }
Watch the side line, these parts are more opaque or you can say darker but the alpha in hud_screen.json is written as 0.65, this should not happen:
Luckily the images in vanilla is all plack pixels, which will not let the bug expose obviously in vanilla, it just darker.
However the wrose is when you modify the images "hotbar_start_cap.png" or "hotbar_end_cap.png" by resourse pack, when the two images are not totally black, there will be rendered weirder:
For example:
Quadral Texture Pack
Faithful 32x Resource Pack
I was confused by this when I was making a texture pack but I found the reason now.
In vanilla resource pack, there are two JSON files were written by mistake:
"hotbar_start_cap.json" & "hotbar_end_cap.json", the two files should never happen because they are used to describe the base size and nineslice size of images. However the "hotbar_start_cap.png" and "hotbar_end_cap.png" are not need to widen the scale. So the two files are redundant.
The redundant files were written by mistake, which caused the bug, they were written as:
{ "nineslice_size": [ 1, 1, 1, 1 ], "base_size": [ 1, 1, 1, 1 ] }Two files are same.
As we can see the base_size is [ 1, 1, 1, 1 ]. However an image can only use two number for length and width, these are 2D images, not 4D! And the nineslice_size part is redundant.For developer to fix this bug, just remove the two JSON flies.
For resource pack maker, there is a correct JSON code you can copy into the two files in your pack to fix the bug:
{ "base_size": [ 1, 22 ] }
Watch the side line, these parts are more opaque or you can say darker but the alpha in hud_screen.json is written as 0.65, this should not happen:
Luckily the images in vanilla is all
plack pixels, which will not let the bug expose obviously in vanilla, it just darker.
However the wrose is when you modify the images "hotbar_start_cap.png" or "hotbar_end_cap.png" by resourse pack, when the two images are not totally black, there will be rendered weirder:
For example:
Quadral Texture Pack
Faithful 32x Resource Pack
I was confused by this when I was making a texture pack but I found the reason now.
In vanilla resource pack, there are two JSON files were written by mistake:
"hotbar_start_cap.json" & "hotbar_end_cap.json", the two files should never happen because they are used to describe the base size and nineslice size of images. However the "hotbar_start_cap.png" and "hotbar_end_cap.png" are not need to widen the scale. So the two files are redundant.
The redundant files were written by mistake, which caused the bug, they were written as:
{ "nineslice_size": [ 1, 1, 1, 1 ], "base_size": [ 1, 1, 1, 1 ] }Two files are same.
As we can see the base_size is [ 1, 1, 1, 1 ]. However an image can only use two number for length and width, these are 2D images, not 4D! And the nineslice_size part is redundant.For developer to fix this bug, just remove the two JSON flies.
For resource pack maker, there is a correct JSON code you can copy into the two files in your pack to fix the bug:
{ "base_size": [ 1, 22 ] }
Watch the side line, these parts are more opaque or you can say darker but the alpha in hud_screen.json is written as 0.65, this should not happen:
Luckily the images in vanilla is all black pixels, which will not let the bug expose obviously in vanilla, it just darker.
However the wrose is when you modify the images "hotbar_start_cap.png" or "hotbar_end_cap.png" by resourse pack, when the two images are not totally black, there will be rendered weirder:
For example:
Quadral Texture Pack
Faithful 32x Resource Pack
I was confused by this when I was making a texture pack but I found the reason now.
In vanilla resource pack, there are two JSON files were written by mistake:
"hotbar_start_cap.json" & "hotbar_end_cap.json", the two files should never happen because they are used to describe the base size and nineslice size of images. However the "hotbar_start_cap.png" and "hotbar_end_cap.png" are not need to widen the scale. So the two files are redundant.
The redundant files were written by mistake, which caused the bug, they were written as:
{ "nineslice_size": [ 1, 1, 1, 1 ], "base_size": [ 1, 1, 1, 1 ] }Two files are same.
As we can see the base_size is [ 1, 1, 1, 1 ]. However an image can only use two number for length and width, these are 2D images, not 4D! And the nineslice_size part is redundant.For developer to fix this bug, just remove the two JSON flies.
For resource pack maker, there is a correct JSON code you can copy into the two files in your pack to fix the bug:
{ "base_size": [ 1, 22 ] }
Watch the side line, these parts are more opaque or you can say darker but the alpha in hud_screen.json is written as 0.65, this should not happen:
Luckily the images in vanilla is all black pixels, which will not let the bug expose obviously in vanilla, it just darker.
However the wrose is when you modify the images "hotbar_start_cap.png" or "hotbar_end_cap.png" by resourse pack, when the two images are not totally black, there will be rendered weirder:
For example:
Quadral Texture Pack
Faithful 32x Resource Pack
I was confused by this when I was making a texture pack but I found the reason now.
In vanilla resource pack, there are two JSON files were written by mistake:
"hotbar_start_cap.json" & "hotbar_end_cap.json", the two files should never happen because they are used to describe the base size and nineslice size of images. However the "hotbar_start_cap.png" and "hotbar_end_cap.png" are not need to widen the scale. So the two files are redundant.
The redundant files were written by mistake, which caused the bug, they were written as:
{ "nineslice_size": [ 1, 1, 1, 1 ], "base_size": [ 1, 1, 1, 1 ] }Two files are same.
As we can see the base_size is [ 1, 1, 1, 1 ]. However an image can only use two number for length and width, these are 2D images, not 4D! And the nineslice_size part is redundant.For developer to fix this bug, just remove the two JSON f
lies.For resource pack maker, there is a correct JSON code you can copy into the two files in your pack to fix the bug:
{ "base_size": [ 1, 22 ] }
Watch the side line, these parts are more opaque or you can say darker but the alpha in hud_screen.json is written as 0.65, this should not happen:
Luckily the images in vanilla is all black pixels, which will not let the bug expose obviously in vanilla, it just darker.
However the wrose is when you modify the images "hotbar_start_cap.png" or "hotbar_end_cap.png" by resourse pack, when the two images are not totally black, there will be rendered weirder:
For example:
Quadral Texture Pack
Faithful 32x Resource Pack
I was confused by this when I was making a texture pack but I found the reason now.
In vanilla resource pack, there are two JSON files were written by mistake:
"hotbar_start_cap.json" & "hotbar_end_cap.json", the two files should never happen because they are used to describe the base size and nineslice size of images. However the "hotbar_start_cap.png" and "hotbar_end_cap.png" are not need to widen the scale. So the two files are redundant.
The redundant files were written by mistake, which caused the bug, they were written as:
{ "nineslice_size": [ 1, 1, 1, 1 ], "base_size": [ 1, 1, 1, 1 ] }Two files are same.
As we can see the base_size is [ 1, 1, 1, 1 ]. However an image can only use two number for length and width, these are 2D images, not 4D! And the nineslice_size part is redundant.For developer to fix this bug, just remove the two JSON files.
For resource pack maker, there is a correct JSON code you can copy into the two files in your pack to fix the bug:
{ "base_size": [ 1, 22 ] }
Watch the side line, these parts are more opaque or you can say darker but the alpha in hud_screen.json is written as 0.65, this should not happen:
Luckily the images in vanilla is all black pixels, which will not let the bug expose obviously in vanilla, it just darker.
However the wrose is when you modify the images "hotbar_start_cap.png" or "hotbar_end_cap.png" by resourse pack, when the two images are not totally black, there will be rendered weirder:
For example:
Quadral Texture Pack
Faithful 32x Resource Pack
I was confused by this when I was making a texture pack but I found the reason now.
In vanilla resource pack, there are two JSON files were written by mistake:
"hotbar_start_cap.json" & "hotbar_end_cap.json", the two files should never happen because they are used to describe the base size and nineslice size of images. However the "hotbar_start_cap.png" and "hotbar_end_cap.png" are not need to widen the scale. So the two files are redundant.
The redundant files were written by mistake, which caused the bug, they were written as:
{ "nineslice_size": [ 1, 1, 1, 1 ], "base_size": [ 1, 1, 1, 1 ] }Two files are same.
As we can see the base_size is [ 1, 1, 1, 1 ]. However an image can only use two number for length and width, these are 2D images, not 4D! And the nineslice_size part is also redundant.For developer to fix this bug, just remove the two JSON files.
For resource pack maker, there is a correct JSON code you can copy into the two files in your pack to fix the bug:
{ "base_size": [ 1, 22 ] }
Watch the side line, these parts are more opaque or you can say darker but the alpha in hud_screen.json is written as 0.65, this should not happen:
Luckily the images in vanilla is all black pixels, which will not let the bug expose obviously in vanilla, it just darker.
However the wrose is when you modify the images "hotbar_start_cap.png" or "hotbar_end_cap.png" by resourse pack, when the two images are not totally black, there will be rendered weirder:
For example:
Quadral Texture Pack
Faithful 32x Resource Pack
I was confused by this when I was making a texture pack but I found the reason now.
In vanilla resource pack, there are two JSON files were written by mistake:
"hotbar_start_cap.json" & "hotbar_end_cap.json", the two files should never happen because they are used to describe the base size and nineslice size of images. However the "hotbar_start_cap.png" and "hotbar_end_cap.png" are not need to widen the scale in game rendering. So the two files are redundant.
The redundant files were written by mistake, which caused the bug, they were written as:
{ "nineslice_size": [ 1, 1, 1, 1 ], "base_size": [ 1, 1, 1, 1 ] }Two files are same.
As we can see the base_size is [ 1, 1, 1, 1 ]. However an image can only use two number for length and width, these are 2D images, not 4D! And the nineslice_size part is also redundant.For developer to fix this bug, just remove the two JSON files.
For resource pack maker, there is a correct JSON code you can copy into the two files in your pack to fix the bug:
{ "base_size": [ 1, 22 ] }
Watch the side line, these parts are more opaque or you can say darker but the alpha in hud_screen.json is written as 0.65, this should not happen:
Luckily the images in vanilla is all black pixels, which will not
letthe bugexposeobviously in vanilla, it just darker.
However the wrose is when you modify the images "hotbar_start_cap.png" or "hotbar_end_cap.png" by resourse pack, when the two images are not totally black, there will be rendered weirder:
For example:
Quadral Texture Pack
Faithful 32x Resource Pack
I was confused by this when I was making a texture pack but I found the reason now.
In vanilla resource pack, there are two JSON files were written by mistake:
"hotbar_start_cap.json" & "hotbar_end_cap.json", the two files should never happen because they are used to describe the base size and nineslice size of images. However the "hotbar_start_cap.png" and "hotbar_end_cap.png" are not need to widen the scale in game rendering. So the two files are redundant.
The redundant files were written by mistake, which caused the bug, they were written as:
{ "nineslice_size": [ 1, 1, 1, 1 ], "base_size": [ 1, 1, 1, 1 ] }Two files are same.
As we can see the base_size is [ 1, 1, 1, 1 ]. However an image can only use two number for length and width, these are 2D images, not 4D! And the nineslice_size part is also redundant.For developer to fix this bug, just remove the two JSON files.
For resource pack maker, there is a correct JSON code you can copy into the two files in your pack to fix the bug:
{ "base_size": [ 1, 22 ] }
Watch the side line, these parts are more opaque or you can say darker but the alpha in hud_screen.json is written as 0.65, this should not happen:
Luckily the images in vanilla is all black pixels, which will not expose the bug obviously in vanilla, it just darker.
However the wrose is when you modify the images "hotbar_start_cap.png" or "hotbar_end_cap.png" by resourse pack, when the two images are not totally black, there will be rendered weirder:
For example:
Quadral Texture Pack
Faithful 32x Resource Pack
I was confused by this when I was making a texture pack but I found the reason now.
In vanilla resource pack, there are two JSON files were written by mistake:
"hotbar_start_cap.json" & "hotbar_end_cap.json", the two files should never happen because they are used to describe the base size and nineslice size of images. However the "hotbar_start_cap.png" and "hotbar_end_cap.png" are not need to widen the scale in game rendering. So the two files are redundant.
The redundant files were written by mistake, which caused the bug, they were written as:
{ "nineslice_size": [ 1, 1, 1, 1 ], "base_size": [ 1, 1, 1, 1 ] }Two files are same.
As we can see the base_size is [ 1, 1, 1, 1 ]. However an image can only use two number for length and width, these are 2D images, not 4D! And the nineslice_size part is also redundant.For developer to fix this bug, just remove the two JSON files.
For resource pack maker, there is a correct JSON code you can copy into the two files in your pack to fix the bug:
{ "base_size": [ 1, 22 ] }
Watch the side line, these parts are more opaque or you can say darker but the alpha in hud_screen.json is written as 0.65, this should not happen:
Luckily the images in vanilla is all black pixels, which will not expose the bug obviously in vanilla, it just darker.
However the wrose is when you modify the images "hotbar_start_cap.png" or "hotbar_end_cap.png" by resourse pack, when the two images are not totally black, there will be rendered weirder:
For example:
Quadral Texture Pack
Faithful 32x Resource Pack
I was confused by this when I was making a texture pack but I found the reason now.
In vanilla resource pack, there are two JSON files were written by mistake:
"hotbar_start_cap.json" & "hotbar_end_cap.json", the two files should never happen because they are used to describe the base size and nineslice size of images. However the "hotbar_start_cap.png" and "hotbar_end_cap.png" are not need to
widenthe scale in game rendering. So the two files are redundant.The redundant files were written by mistake, which caused the bug, they were written as:
{ "nineslice_size": [ 1, 1, 1, 1 ], "base_size": [ 1, 1, 1, 1 ] }Two files are same.
As we can see the base_size is [ 1, 1, 1, 1 ]. However an image can only use two number for length and width, these are 2D images, not 4D! And the nineslice_size part is also redundant.For developer to fix this bug, just remove the two JSON files.
For resource pack maker, there is a correct JSON code you can copy into the two files in your pack to fix the bug:
{ "base_size": [ 1, 22 ] }
Watch the side line, these parts are more opaque or you can say darker but the alpha in hud_screen.json is written as 0.65, this should not happen:
Luckily the images in vanilla is all black pixels, which will not expose the bug obviously in vanilla, it just darker.
However the wrose is when you modify the images "hotbar_start_cap.png" or "hotbar_end_cap.png" by resourse pack, when the two images are not totally black, there will be rendered weirder:
For example:
Quadral Texture Pack
Faithful 32x Resource Pack
I was confused by this when I was making a texture pack but I found the reason now.
In vanilla resource pack, there are two JSON files were written by mistake:
"hotbar_start_cap.json" & "hotbar_end_cap.json", the two files should never happen because they are used to describe the base size and nineslice size of images. However the "hotbar_start_cap.png" and "hotbar_end_cap.png" are not need to expand the scale in game rendering. So the two files are redundant.
The redundant files were written by mistake, which caused the bug, they were written as:
{ "nineslice_size": [ 1, 1, 1, 1 ], "base_size": [ 1, 1, 1, 1 ] }Two files are same.
As we can see the base_size is [ 1, 1, 1, 1 ]. However an image can only use two number for length and width, these are 2D images, not 4D! And the nineslice_size part is also redundant.For developer to fix this bug, just remove the two JSON files.
For resource pack maker, there is a correct JSON code you can copy into the two files in your pack to fix the bug:
{ "base_size": [ 1, 22 ] }
Watch the side line, these parts are more opaque or you can say darker but the alpha in hud_screen.json is written as 0.65, this should not happen:
Luckily the images in vanilla is all black pixels, which will not expose the bug obviously in vanilla, it just darker.
However the wrose is when you modify the images "hotbar_start_cap.png" or "hotbar_end_cap.png" by resourse pack, when the two images are not totally black, there will be rendered weirder:
For example:
Quadral Texture Pack
Faithful 32x Resource Pack
I was confused by this when I was making a texture pack but I found the reason now.
In vanilla resource pack, there are two JSON files were written by mistake:
"hotbar_start_cap.json" & "hotbar_end_cap.json", the two files should never happen because they are used to describe the base size and nineslice size of images. However the "hotbar_start_cap.png" and "hotbar_end_cap.png" are not need to expand the scale in game rendering. So the two files are redundant.
The redundant files were written by mistake, which caused the bug, they were written as:{ "nineslice_size": [ 1, 1, 1, 1 ], "base_size": [ 1, 1, 1, 1 ] }Two files are same.
As we can see the base_size is [ 1, 1, 1, 1 ]. However an image can only use two number for length and width, these are 2D images, not 4D! And the nineslice_size part is also redundant.For developer to fix this bug, just remove the two JSON files.
For resource pack maker, there is a correct JSON code you can copy into the two files in your pack to fix the bug:
{ "base_size": [ 1, 22 ] }
Watch the side line, these parts are more opaque or you can say darker but the alpha in hud_screen.json is written as 0.65, this should not happen:
Luckily the images in vanilla is all black pixels, which will not expose the bug obviously in vanilla, it just darker.
However the wrose is when you modify the images "hotbar_start_cap.png" or "hotbar_end_cap.png" by resourse pack, when the two images are not totally black, there will be rendered weirder:
For example:
Quadral Texture Pack
Faithful 32x Resource Pack
I was confused by this when I was making a texture pack but I found the reason now.
In vanilla resource pack, there are two JSON files were written by mistake:
"hotbar_start_cap.json" & "hotbar_end_cap.json", the two files should never happen because they are used to describe the base size and nineslice size of images. However the "hotbar_start_cap.png" and "hotbar_end_cap.png" are not need to expand the scale in game rendering. So the two files are redundant.
At the same time the redundant files were written by mistake, which caused the bug, they were written as:
{ "nineslice_size": [ 1, 1, 1, 1 ], "base_size": [ 1, 1, 1, 1 ] }Two files are same.
As we can see the base_size is [ 1, 1, 1, 1 ]. However an image can only use two number for length and width, these are 2D images, not 4D! And the nineslice_size part is also redundant.For developer to fix this bug, just remove the two JSON files.
For resource pack maker, there is a correct JSON code you can copy into the two files in your pack to fix the bug:
{ "base_size": [ 1, 22 ] }
Watch the side line, these parts are more opaque or you can say darker but the alpha in hud_screen.json is written as 0.65, this should not happen:
Luckily the images in vanilla is all black pixels, which will not expose the bug obviously in vanilla, it just darker.
However the wrose is when you modify the images "hotbar_start_cap.png" or "hotbar_end_cap.png" by resourse pack, when the two images are not totally black, there will be rendered weirder:
For example:
Quadral Texture Pack
Faithful 32x Resource Pack
I was confused by this when I was making a texture pack but I found the reason now.
In vanilla resource pack, there are two JSON files were written by mistake:
"hotbar_start_cap.json" & "hotbar_end_cap.json", the two files should never happen because they are used to describe the base size and nineslice size of images. However the "hotbar_start_cap.png" and "hotbar_end_cap.png" are not need to expand the scale in game rendering. So the two files are redundant.
At the same time the redundant files were written by mistake, which caused the bug, they were written as:
{ "nineslice_size": [ 1, 1, 1, 1 ], "base_size": [ 1, 1, 1, 1 ] }Two files are same.
As we can see the base_size is [ 1, 1, 1, 1 ]. However an image can only use two number for length and width, these are 2D images, not 4D! And the nineslice_size part is also redundant.For developer to fix this bug, just remove the two JSON files.
For resource pack maker, there is a correct JSON code you can copy into the two files in your pack to fix the bug:
{ "base_size": [ 1, 22 ] }
Watch the side line, these parts are more opaque or you can say darker but the alpha in hud_screen.json is written as 0.65, this should not happen:
Luckily the images in vanilla is all black pixels, which will not expose the bug obviously in vanilla, it just darker.
However the wrose is when you modify the images "hotbar_start_cap.png" or "hotbar_end_cap.png" by resourse pack, when the two images are not totally black, there will be rendered weirder:
For example:
Quadral Texture Pack
Plastic Texture Pack
Especially in HD resource pack including the two images within thin lines:
Faithful 32x Resource Pack
I was confused by this when I was making a texture pack but I found the reason now.
In vanilla resource pack, there are two JSON files were written by mistake:
"hotbar_start_cap.json" & "hotbar_end_cap.json", the two files should never happen because they are used to describe the base size and nineslice size of images. However the "hotbar_start_cap.png" and "hotbar_end_cap.png" are not need to expand the scale in game rendering. So the two files are redundant.
At the same time the redundant files were written by mistake, which caused the bug, they were written as:
{ "nineslice_size": [ 1, 1, 1, 1 ], "base_size": [ 1, 1, 1, 1 ] }Two files are same.
As we can see the base_size is [ 1, 1, 1, 1 ]. However an image can only use two number for length and width, these are 2D images, not 4D! And the nineslice_size part is also redundant.For developer to fix this bug, just remove the two JSON files.
For resource pack maker, there is a correct JSON code you can copy into the two files in your pack to fix the bug:
{ "base_size": [ 1, 22 ] }
Watch the side line, these parts are more opaque or you can say darker but the alpha in hud_screen.json is written as 0.65, this should not happen:
Luckily the images in vanilla is all black pixels, which will not expose the bug obviously in vanilla, it just darker.
However the wrose is when you modify the images "hotbar_start_cap.png" or "hotbar_end_cap.png" by resourse pack, when the two images are not totally black, there will be rendered weirder:
For example:
Quadral Texture Pack
Plastic Texture Pack
Especially in HD resource pack including the two images within thiner lines:
Faithful 32x Resource Pack
I was confused by this when I was making a texture pack but I found the reason now.
In vanilla resource pack, there are two JSON files were written by mistake:
"hotbar_start_cap.json" & "hotbar_end_cap.json", the two files should never happen because they are used to describe the base size and nineslice size of images. However the "hotbar_start_cap.png" and "hotbar_end_cap.png" are not need to expand the scale in game rendering. So the two files are redundant.
At the same time the redundant files were written by mistake, which caused the bug, they were written as:
{ "nineslice_size": [ 1, 1, 1, 1 ], "base_size": [ 1, 1, 1, 1 ] }Two files are same.
As we can see the base_size is [ 1, 1, 1, 1 ]. However an image can only use two number for length and width, these are 2D images, not 4D! And the nineslice_size part is also redundant.For developer to fix this bug, just remove the two JSON files.
For resource pack maker, there is a correct JSON code you can copy into the two files in your pack to fix the bug:
{ "base_size": [ 1, 22 ] }
1.Download the pack in attachments, the pack includes
only thecustom shield patterns textures;2.Import the pack in Minecraft Preview;
3.Activate the pack in settings;
4.Back to the main menu;
5.Crash.
1.Download the pack in attachments, the pack includes custom shield patterns textures only;
2.Import the pack in Minecraft Preview;
3.Activate the pack in settings;
4.Back to the main menu;
5.Crash.
1.Download the pack in attachments, the pack includes custom shield patterns textures only;
2.Import the pack in Minecraft Preview;
3.Activate the pack in settings;
4.Back to the main menu;
5.Crash.
1.Download the pack in attachments, the pack includes custom shield patterns textures only;
2.Import the pack in Minecraft Preview;
3.Activate the pack in settings;
4.Back to the main menu (Maybe you should enter a world);
5.Crash (Windows platform at least).
1.Download the pack in attachments, the pack includes custom shield patterns textures only (New 1.21 patterns included);
2.Import the pack in Minecraft Preview;
3.Activate the pack in settings;
4.Back to the main menu (Maybe you should enter a world);
5.Crash (Windows platform at least).
1.Download
thepack in attachments, the pack includes custom shield patterns textures only(New 1.21 patterns included);2.Import the pack in Minecraft Preview;
3.Activate the pack in settings;
4.Back to the main menu (Maybe you should enter a world);
5.Crash (Windows platform at least).
1.Download my pack in attachments, the pack includes custom shield patterns textures only;
2.Import the pack in Minecraft Preview;
3.Activate the pack in settings;
4.Back to the main menu (Maybe you should enter a world);
5.Crash (Windows platform at least).
I don't think there is anything wrong with my pack as it can work as expected in version 1.20.70 and earlier.
Crash when activatearesource pack including custom shield patterns texturesCrash when activate some resource pack including custom shield patterns textures
Steps to reproduce
- Download my pack in attachments, the pack includes custom shield patterns textures only;
- Import the pack in Minecraft Preview;
- Activate the pack in settings;
- Back to the main menu (Maybe you should enter a world);
- Crash (Windows platform
at least).I don't think there is anything wrong with my pack as it can work as expected in version 1.20.70 and earlier.
Steps to reproduce
- Download my pack in attachments, the pack includes custom shield patterns textures only;
- Import the pack in Minecraft Preview;
- Activate the pack in settings;
- Back to the main menu (Maybe you should enter a world);
- Crash (Windows platform only).
I don't think there is anything wrong with my pack as it can work as expected in version 1.20.70 and earlier.
Crash when activate some resource pack including custom shield patterns textures (Windows only)
Steps to reproduce
- Download my pack in attachments, the pack includes custom shield patterns textures only;
- Import the pack in Minecraft Preview;
- Activate the pack in settings;
- Back to the main menu (Maybe you should enter a world);
- Crash (Windows platform only).
I don't think there is anything wrong with my pack as it can work as expected in version 1.20.70 and earlier, besides, the bug also affects some texture pack in marketplace.
seems fixed in 1.20.0.20 Preview
Raid Omen effect icon includes old programmer art villager head texture (before texture update)
Some particles lose initial speed when they were created.
For example the vanilla campfire smoke particle, when summon a smoke particle, the initial speed is 0, which is different from the same particle in 1.20.70 Release, which causes its floating height become lower than before as you can see in attachment screenshots.
However the particle JSON file have not been modified, which means there should be a problem with the way the game runs particles, i don't know the conditional, but it also affects some of my rewritten particle.
Some particles lose initial speed when they were created.
For example the vanilla campfire smoke particle, when summon a smoke particle, the initial speed is 0, which is different from the same particle in 1.20.70 Release, which causes its floating height become lower than before as you can see in attachment screenshots.
However the particle JSON file have not been modified, which means there should be a problem with the way the game runs particles, i don't know the conditional, but it also affects some of my rewritten particle.
Some particles losetheirinitial speed (affects vanilla campire smoke)
Some particles lose initial speed (affects vanilla campfire smoke)
Some particles lose initial speed when they were created.
For example the vanilla campfire smoke particle, when summon a smoke particle, the initial speed is 0, which is different from the same particle in 1.20.70 Release, which causes its floating height become lower than before as you can see in attachment screenshots.
However the particle JSON file have not been modified, which means there should be a problem with the way the game runs particles, i don't know the condition
al, but it also affects some of my rewritten particle.
Some particles lose initial speed when they were created.
For example the vanilla campfire smoke particle, when summon a smoke particle, the initial speed is 0, which is different from the same particle in 1.20.70 Release, which causes its floating height become lower than before as you can see in attachment screenshots.
In addition, the fire smoke particles
However the particle JSON file have not been modified, which means there should be a problem with the way the game runs particles, i don't know the condition, but it also affects some of my rewritten particle.
Some particles lose initial speed (affects vanilla campfire smoke and fire smoke)
Some particles lose initial speed when they were created.
For example the vanilla campfire smoke particle, when summon a smoke particle, the initial speed is 0, which is different from the same particle in 1.20.70 Release, which causes its floating height become lower than before as you can see in attachment screenshots.
In addition, the fire smoke particles
However the particle JSON file have not been modified, which means there should be a problem with the way the game runs particles, i don't know the condition, but it also affects some of my rewritten particle.
Some particles lose initial speed when they were created.
For example the vanilla campfire smoke particle, when summon a smoke particle, the initial speed is 0, which is different from the same particle in 1.20.70 Release, which causes its floating height become lower than before as you can see in attachment screenshots.
In addition, the fire smoke particles won't move upward.
However the particle JSON file have not been modified, which means there should be a problem with the way the game runs particles, i don't know the condition, but it also affects some of my rewritten particle.
![[Mod] EVGENSYPERPRO](../../../data/avatars/users/92853.png){kind=small}
Rainvay, perhaps you meant 1.21.0.20?
But I was still able to reproduce this in 1.21.0.20.
Cocoa fruit will be so big with HD texture.
big cocoa fruit with HD texture
Actually this is because the block images size is 40*32 but the carried texture is only 16*16, not only sniffer egg in vanilla, if one block have its exclusive carried textures, when block resolution is bigger than carried item, the size in item frame will be smaller, when carried item resolution is bigger than block, the size in item frame will be bigger.
If developer only want to fix the sniffer egg bug, I suggest that split the textures, make the block resolution equal to the item, like Java Edition.
But I hope developers can fix the essential issues (item frame display size of terrain atlas), because if an HD texture pack only includes the carried texture, when put the item into frame, the size will be super large. For example, the pack only includes HD candle items but candle blocks are missing.
Fixed in 1.20.0.20
Bedrock Edition textures updated in 1.10.0. I compared the files in MCBE 1.9 with now. The classic texture is from MCBE 1,9, developer set the grass block top texture as background of grass/fern/tall grass/large fern TGA images, this is for resolve the problem. However when developer make the new vanilla TGA files, they forgot this and make the TGA background white, then if in the distance, the texture will be blurred by shaders, then the brighter background will make the plants brighter, witch caused the bug. Do not use the spyglass to watch them because the textures would not be blurred in the case.
I know the renamings will break some banner creations crafted in MCBE 1.15-now. I know the developers may have noticed this so they chose keeping the mistake and modified the crafting table recipes to match the mistake. Maybe developers will go on, rename the correct shield pattern files to keep the mistake.
But I really do not think this was a good idea. For texture pack creators, when they convert a Java resource pack into Bedrock, then they will roughly ignore the mistake and will not follow the "vanilla_1.15" to keep it, and this usually leads to bigger trouble.
Please bring back the correct image names, no keeping the mistake! We have to make a better choices, don't we?
texture images are same as Java, there may be a dark tinting layer or something else.
All X-shaped blocks in Java Edition, their textures look will never flip horizontally no matter which direction they are viewed from.
But in Bedrock, some textures will flip horizontally then cause axisymmetric in visual:
Grass, Fern, Flowers Except Pitcher Plants), Dead Bush, Saplings, Bamboo Spling, Corals, Amethyst Buds, Amethyst Cluster, Cobweb, Weeping Vine, Twisting Vine, Hanging Roots, Warped Roots, Crimson Roots, Nether Sprouts, (Flowering) Azalea (Bottom Model), Kelp, Campfire, Soul Campfire, Sweet Berry Bushes, Mangrove Propagule.
I noticed develpers have solved this problem in some new X-shaped blocks like Pitcher Plants, Pointed Dripstone, Cave Vines, so the blocks using outdated blockshapes and render methods, they should be updated because axisymmetric is ugly if watch the model carefully.
yes, I created a white image as its texture then only to find that was in green tinting slightly in game world, and this is the reason why we see it darker
I have confirmed this by custom resource pack, kelp is greenly tinted by hardcode, although the texture images are green themselves.
I remember the seagrass was also tinted before but the bug was fixed, however nobody noticed the bug is also in kelp till this page... (
MCPE-34795)Confirmed, I have come across this bug, but every time i met this bug i restarted the game then it will render correctly. I dont know when and why the bug will happen but actually it will happen sometimes.
this is because the treatment packs did not load completely. the UI json files was loaded but the UI images was not
actually the banner patterns was wrong and have been wrong for nearly 3 years while the shield was correct...
still happen in Preview 1.20.0.22
still happen in Preview 1.20.0.22
They should use UnifontJP to match these font in Japanese
Still happen in Preview 1.20.0.22
In addition, You can still craft banners in crafting table in MCBE. When you craft these patterns in crafting table, the patterns look like correct, however because of this bug, the recipe are also wrong.
In other words, do not forget fix the wrong recipes to mtach the correct image names.
Still happen in Preview 1.20.0.23
Still happen in Preview 1.20.0.23
still happen in Preview 1.20.0.23
still happen in Preview 1.20.0.23
Still happen in Preview 1.20.0.24
Still happen in Preview 1.20.0.24
Solved in Preview 1.20.0.24
Still happen in Preview 1.20.0.24
Still happen in Preview 1.20.0.20
Still happen in 1.20.0 Release
Mojang just make banner shield names wrong as well... So sad for it...
Can confirm
MC-269949Fixed in Preview 1.21.0.23