mojira.dev

Ninjadankinate2

Assigned

No issues.

Reported

MCPE-189395 Classic Skin PNG import failing on iOS Unconfirmed MCPE-176207 Comparators prioritize reading form storage over powered blocks in-between Works As Intended MCPE-174011 Tripwire hooks delay activation and deactivation for 0.5 seconds, and hooks connected to tripwire to the South (+Z) or West (-X) disconnect during the delay Fixed MCPE-166429 One block tall flowers cannot be bone mealed/spread on mud blocks. Confirmed MCPE-166005 Thai language fonts are broken - only partially render Fixed MCPE-160494 Ghast fireballs sometimes fail to break blocks that they should break on a direct hit Confirmed

Comments

I do indeed have optimized storage enabled.  However, I'd be surprised if that were an issue as the original image seems to be downloading from iCloud for import (see attached screen recording).

Also, I've always had this skin enabled, and in previous versions, imports worked.  It's especially strange that my successfully imported classic skin (imported prior to latest update) did show in the UI post-update as already having been imported, but wouldn't apply it as my skin.  It kept changing back to a default skin.

In fact, if I go into storage settings, and look at files saved/managed by Minecraft, I can see the originally imported skin file renamed to "custom.png", and again that already imported file stopped working in the latest update, and the game kept defaulting to default skin.  I'll attach a screenshot of Minecraft storage showing the same.

Workaround on iOS is to wrap your classic skin png into a skin pack, and import it.

See the following guide for details.
https://learn.microsoft.com/en-us/minecraft/creator/documents/packagingaskinpack?view=minecraft-bedrock-stable

In my case, I used a Mac to create the skin pack files and directory, zip it, rename the file extension to mcpack, and share the mcpack file via airdrop to my iOS device.  After that, just open/import the file with Minecraft.

I cannot convey how happy and grateful I am to confirm the fix for this which landed in today's preview.

Please let whichever dev(s) worked on this fix know that all my Thai Minecraft playing friends are celebrating today!  We're all beyond hyped over how much more smoothly collaboration in-game will be now for millions of Thai players!  I imagine kids explaining redstone to each other, nerding out over shared builds, and having grande explorations and adventures all without the extra cognitive load of reading garbled text getting in the way.  Just pure, obstacle-free joy.  I know this was likely a small fix, but the impact is huge.

I've been smiling ear-to-ear since I saw the preview changelog this morning.  And I know my friends in the Thai community have been feeling the same.

Thank you!!!

Even unicode.org says that rendering languages with diacritics is not hard!  Let's make this happen please!

https://www.unicode.org/notes/tn2/

Note: this is also a problem in Java MC-87751

Please devs, prioritize this issue!  Bedrock is easily the most played version of Minecraft in Thailand, and we're doing a bunch of Thai kids a disservice by not allowing them to communicate and collaborate easily in-game.  In 2024, Minecraft is the gateway to Art, Architecture, and all things STEM.  Let's help Thai kids on that path by improving their ability to collaborate, communicate, and learn from each other in-game!

This also a problem in Bedrock edition.  MCPE-166005

Please devs, Bedrock is easily the most played version of Minecraft in Thailand, and we're doing a bunch of Thai kids a disservice by not allowing them to communicate and collaborate easily in-game.  In 2024, Minecraft is the gateway to Art, Architecture, and all things STEM.  Let's help Thai kids on that path by improving their ability to collaborate, communicate, and learn from each other in-game!

In my case, in latest preview (1.20.70.20), I saw Mineville server showing up as a LAN advertised game in my friends tab, and I was able to connect to click on the LAN entry, and successfully join the Mineville server.  The LAN entry was generally quick to disappear though, and I was only able to connect through the entry once.

Attached video of approximate seven redstone tick delay between trigger and redstone output.

And uploading one more video of another broken tripwire mechanic: moving quickly through the trip wire (e.g. running) doesn't trigger it.

Uploaded two worlds.  They should be basically the same, but one was exported from the preview version, and the other from current release.  Both should be broken in current preview, but for sure the "WorkingInCurrentRelease" world should work in non-preview.

Included both files as the one exported from preview edition has better labeling of the various bits, and can be used as a reference for the other.  Also not sure if current preview exports are backwards-compatible with current release.

Just added a picture showing chunk borders, which are no doubt implicated in the asymmetric firing, but perhaps the timing is a separate bug.

Oh dang.  I was totally wrong.  They still work... maybe.  The farm in the video came from a 1.20.10.21 structure export, which I loaded into a brand new 1.20 world.

When I try my old 1.19 vanilla world with the same blaster, it loads in 1.20 just fine, and still breaks logs.  ¯_(ツ)_/¯

In my new 1.20 world, ghast fireballs are failing to break any blocks, but in the current preview (1.20.10.21) they still break blocks.  Not sure if this should be its own ticket, or if it doesn't even matter since latest preview still works, but decided to update here as a middle-ground between the two.

Attaching a video of this: GhastFireballsBroken.mp4

Workaround is to use ghast fireballs to break at least some blocks (in this case concrete).

Update to yesterday's update.  If the ghast fireball is slowed down by passing through a falling water block (1 water source and 1 block falling water), then the fireball slows down, and will explode the blocks when hit from the underside.  I'll attach a video demonstrating this.

As of 1.19.60, it's almost fixed!  Ghast fireballs will almost always break logs when hit from the side, but if hit from the bottom, as in the world download example I provided, the blocks will NEVER break.  Warped and Crimson stem are the only exceptions.  They still break when hit on their bottom side.

EDIT:  Feel my pain – https://youtu.be/fINLp7aYdCU

2-tall should pop out (not spread), which is what they do.  Nothing to fix there.

1-tall should spread, but they don’t.  That is what needs fixed.

Just tested in 1.19.51, and it still does __ not work.  Please update affected versions.

Video is attached.

This is Bedrock Edition, which is why I marked the version as "1.19.70.20 Preview" and chose to file this ticket under the MCPE Jira project.

Steps to Reproduce
1. Place a 1-tall flower on top of a mud block platform.
2. Apply bonemeal to flower (either manually or with dispenser)
3. See that nothing happens
4. Replace 1-tall flower with 2-tall flower
5. Apply bonemeal to flower (either manually or with dispenser)
6. See that 2-tall flowers are produced.