Skaijie

Did you activate the pack under Settings > Global Resources?

Seems fixed for Realms - they now show up in the same order every time (though I'm not quite sure how it's ordered).

To add on, the circuit as shown in the book is still valid, but only on the Java edition of the game, because it requires that sticky piston spit out their blocks, which is a Java-only feature (MC-5726). Sticky pistons not doing so on Bedrock is also currently working as intended (MCPE-36986), hence this circuit will not work on Bedrock.

Redstone on the MCPE/Bedrock Edition couldn't even be placed on the ground until late 2015.

Still an issue in 1.17.10.

Still an issue in 1.17.10.

Still an issue in 1.17.10.

I have got this to happen once, via the behaviour that you describe as the blaze holding its charged, which can be considered MCPE-45311/MCPE-89026. By having the blaze fire once, getting out of range, then getting back into range for the blaze to then fire twice immediately, I was able to observe the third fireball going backwards at a slow speed, which then disappeared upon contact with the floor. I was not able to reproduce this again subsequently, and I think part of this is because the first time round, the second fireball seemed to actually fire downwards, which I also observed with skeletons while testing MCPE-89026 (the arrow would sometimes land right below the skeleton on the floor when they shot in the case of MCPE-89026).

This is still reproducible in 1.17.10.

What this ticket is saying is that when you move out of the range of a skeleton that is actively targeting you, and move within range again after a while (even after it has stopped looking for you), the skeleton will instantly shoot at you. What differs from ghasts as described in MCPE-45311 is that the skeleton does not visually show that it is still "charged", which is like what you observed.

I'd think the underlying cause is the same, so resolving as a duplicate instead may be feasible.

We're using MCPE-129901 as the main ticket to track this issue, so this ticket is being resolved and linked as a duplicate. Thank you for your report though!

If you would like to add a vote and any extra information to the main ticket it would be appreciated.

If you haven't already, do use the search feature to see if the issue has already been reported.

Quick Links:
📓 Bug Tracker Guidelines _{– 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki}

The Beta 1.17.10.22 changelog includes this change:

• Fixed a legibility issue with some Japanese font characters

Does this fix the issue?

If you access the website and get something similar to the following page:

Then the website is working perfectly fine. If you are referring to the description, a description is not required for the website to work properly.

Your hotbar shows that you have an activator rail. Powered rails have yellow on its sides.

Click the blue text: 

 
If you somehow still can't click it, download it from the attachments or use this:

Simply click the blue link and it should download automatically.

On a side ntoe, it is listed as "MAY NOT WORK" when you look at the pack description because I wasn't sure if the only issue was the toggle. Others have since confirmed that enabling the toggle works.

I believe that @unknown's issue would actually already be covered by MCPE-121708, so I am requesting it to be relinked as such.

Also, I initially confirmed the report as my initial test on the beta found no dungeons, while another device on 1.17.0 running the same seed and same coordinates contained dungeons. In subsequent tests, however, I was able to find dungeons in other seeds, and creating a new world with the same seed from the positive test yielded dungeons, hence my confirmation would be void as I could not reproduce it consistently.

@unknown could you provide the seed where dungeons generate?

Removing 1.17.0 from affected versions because this issue is not present in that version. Repeating the teleportation in 1.17.0.23 beta yielded no dungeons.

The website you linked shows that dungeons spawn in both 1.16 and 1.17. I tried teleporting to the locations listed by the website and 8 of 10 times there was a dungeon. What it also shows however is that dungeons now spawn 70% less than before. You can compare the two images I've attached. I suspect that the change might have been to achieve parity, though.

Analysis of differences in absolute ore amounts and y-level distributions between 1.16.5 and 1.17

We are looking to find out whether there is a difference between the absolute amount of diamond ores generated in 1.16.5 (μ1), and the absolute amount of diamond ores generated in 1.17 (μ2).
H0: μ1 = μ2
Ha: μ1 ≠ μ2

Sample size: 30 worlds, 15 in 1.16.5 and 15 in 1.17, using randomised seeds.
The data collected is the amount of diamonds at each y-level from 1 to 16 inclusive for all selected worlds in 1.16.5 and 1.17. We use the coordinates -256, 1, -256 to 255, 16, 255 (32x32 chunks) in all worlds.

Boxplots (totals is for 1.17 while totals16 is for 1.16.5):

It appears that there is a greater variation in the number of diamond ores between worlds (or chunk areas), from 1.16.5 to 1.17. A larger sample size will be needed to see if this variation is consistent, but without any further anaylsis, this suggests that luck plays a bigger factor in 1.17 than it did in 1.16.5.
Diamond ore samples can be said to be independent. I think there are trillions of possible seeds.

By running the data through a 2-sample t-test, we obtain t = 0.994 and P-value = 0.329, which means there is a 32.9% probability that this result arose by chance, and is not significant. There is no evidence to suggest a change in the absolute amount of diamond ores on average.

If we run the data on a y-level basis (specifically, y=11 and y=12) using the same test, we obtain respective P-values of 0.0230 and 0.0320 on a two-tailed test (Ha: μ1 ≠ μ2), or 0.0115 and 0.0160 respectively for a left-tailed test (Ha: μ1 < μ2), which suggests a decrease in diamond ore levels on these two levels. Note that this does not show how much it actually decreased, only that it could have decreased.

In the dataset linked above, light gray represents the 25th percentile, yellow shows the 50th percentile, dark grey shows the 75th percentile and aqua shows the 100th percentile. Pastel blue in 1.16.5 seed 14 represents both numbers at the same position near the 75th percentile. In both versions, the top quartile of y-levels with the most diamonds appear to be 5 - 7 and 12.

Another factor that could be involved is deepslate. Deepslate takes almost twice the time to mine as stone (87.5% more for an iron pickaxe if the Wiki is correct), and depending on whether you tend to divert upon seeing deepslate, this may be a bigger factor in the apparent reduction in diamonds than the ore distribution changes.

Tl;dr: No statistical difference in absolute amount of diamond ore generated, but possible slight decreases on a y-level basis in 1.17. Y-levels 5-7 have always been good for diamonds. Deepslate may be a larger factor as it will increase the mining time significantly. Diamond ore amounts could vary morein 1.17 than in 1.16.5, which could mean that luck has become a larger factor.

The only remaining analyses would be on whether ore vein sizes have decreased and veins have become more common (while retaining similar absolute numbers), and whether this negatively affects the chances of finding diamonds.

The reopen was when @unknown first asked a question, set the resolution to Awaiting Response, and OP replied, thus reopening the ticket. Tickets are usually left open as a point of reference until the full release of an update, unless the bug appeared in a beta and got fixed in a later beta for the same release (where it is Resolved at that point in time).