mojira.dev

TheRoyalBlock

Assigned

No issues.

Reported

MCPE-183492 Adding "minecraft:npc" component to player.json hides nametag Won't Fix MCPE-178169 Observers Only Pulse When Shriekers Exit The Shrieking Phase Duplicate REALMS-11420 Crash when catching Baby Pink Axolotl in Bucket Incomplete MCPE-172756 TNT and Creepers cause no damage in water Duplicate MC-264100 TNT Damages Players In Water Duplicate MCPE-169866 Custom Horse Conversions Duplicate Armor Confirmed MCPE-154475 Milk buckets move to inventory when crafting cake Confirmed MCPE-154375 Black and Blue dyes incorrectly named Duplicate REALMS-10112 Commandblockoutput gamerule randomly enabling Duplicate MCPE-153023 Baby villagers walk through half slabs Confirmed MCPE-152936 [EX: Wild Update] Sheep eating doesn't update grass Cannot Reproduce REALMS-10044 Applying packs when no pack changes made Cannot Reproduce MCPE-152387 Placefeature Block Errors Cannot Reproduce MCPE-152263 Create UI: RP More Details brings Marketplace Error L-404 Duplicate MCPE-152261 Create UI: RP Activation Fixed MCPE-152260 Create UI: Scollbar Flickering Fixed REALMS-10023 Updating Realm Requires Editing Fixed MCPE-151295 Reduced stacks of custom items delete excess Cannot Reproduce MCPE-151227 Outdated Loading Tip Duplicate MCPE-151090 Fluid collisions modify hitbox Incomplete

Comments

Updating this to say this still occurs in the latest stable release and is still replicable.

This still occurs in the latest stable release and is replicable using the attached pack.

Really not sure how this is WAI. How is it "intended" to have any player animations or animation-based UI changes break custom skins and capes entirely? Can this be reopened or the decision explained?

This is an updated version of MCPE-163810

Was this fixed along with MCPE-169988?

Still affects 1.20.50.

RandomTickSpeed does not impact the deepslate redstone ore either.

I have tested on two realms – one with addons, and one that's completely vanilla. Both experienced this issue.

This is a bedrock realms-only issue. Does not impact any other modes of gameplay (BDS is untested)

Can confirm. 

Observed behavior: TNT underwater does no damage to players.

Expected behavior: When TNT is dispensed underwater, it damages players around it unless their feet are behind blocks – just like above the water.

Notes: This is inconsistent with the behavior from Java Edition which was marked Works As Intended in MC-26279 , and can serve as a correction to MCPE-21611 which was from prior to Buzzy Bees+ parity initiatives. 

Thanks. Search function hates me sometimes.

Confirmed as well. Bonemeal doesn't work underwater. 

This is continuing to impact 1.20 on realms. Wonder if this relates to MCPE-74493 

Just tested once again in 1.19.80: maps still inflate world size. 

The in-game world size counter is slightly inaccurate, more of an estimation. Here are accurate steps to reproduce:

  1. Create a fresh world, exit without moving at all.

  2. Open the world in an NBT editor like an old version of Universal Minecraft Editor (current one is paid, you can find an old version for free easily).

  3. Notice that there are 0 maps

  4. Close the world in the NBT editor and reopen the world in-game

  5. Create a map in-game and leave the world immediately, without even viewing it.

  6. Reopen the world in an NBT editor.

Expected Result: There is one map created at the default scale, with a very minor file size increase.

Observed Result: There are 5 maps created at all scales, without even viewing the map. The file size is increased permanently and to a greater effect than it would be otherwise. (See "Map Bug.png" attached to the report, showing 1 map in-game with 5 maps in the world NBT). 

When a map is generated, it remains in the files forever; hence why maps continue to increment in numbers in-game overtime. This is intended and destroying the maps will not do anything. What is unintended is the auto-generation of all scales for every map created.

Yes

Seems to be working for me @D3vinRil3y, have you tried changing the hover note and structure name that you're using to a different one after each edit?

I don't believe this bug should be labeled Vanilla Parity – this is a feature that used to work and now fails, not something in need of a parity update.

RE: Umija5895M

If you set your simulation distance to 4, load a new world, and run "/fill ~-40 ~ ~-40 ~40 ~ ~40" the command fails. There are very specific areas – not limited to chunks, but specific blocks – where the command succeeds. 

40 blocks is within simulation distance 4, no matter where you are in a chunk, proving that the issue with /fill is dissociated from simulation distance.

All blocks within the command must be in a Saved Chunk, and chunks only save when they're interacted with – not just when simulated. 

Yes @Marco Bergsma that's right. It's ONLY the gamerules that are NOT in the world settings. Great deduction!

That other issue seems like a separate command-functionality based issue. This issue in this case is that the realm is only saving world settings. Intended behavior is that "permanent settings" were meant to be set through the realm menu, , for EXAMPLE, the /difficulty command used to only last until restart. This issue is a problem because these ingame-command-gamerules cannot be permanently set through the menu.

Happens to vanilla realms as well.

This can be confirmed by multiple people on REALMS-10112