Yann
- Yodalf
- yodalf
- Europe/Stockholm
- Yes
- No
MCPE-42937MCPE-46580MCPE-47294
Realms are a lag fest at the moment.
With only one player logged in, mining with efficiency pickaxe is to laggy...
Activating more than 5 pistons at the same time is too laggy...It's not the pc or the connection, your servers are bad, fix them.
Looking at dragon_fireball.json behaviour file,
spawn_aoe_cloud doesn't have a reapplication_delay like lingering_potion.json have.
Maybe it's as simple as that ?
It should be fairly easy to make a behaviour pack and test it ourselves.
Hi,
Since 1.13 villages behave weirdly.
I made this world to demonstrate it.On windows, if you break one of the bed the villagers are in (right in front of you when you load the world), the villager will link on the village on the left.
On Android the village will stay there and not link to any free bed.
I believe this is a bug in the way the game finds the closest village.
- Yodalf
Hi,
Since 1.13 villages behave weirdly.
I made this world to demonstrate it.On windows, if you break one of the bed the villagers are in (right in front of you when you load the world), the villager will link on the village on the left.
On Android the village will stay there and not link to any free bed.
I believe this is a bug in the way the game finds the closest village.
Villages behavie differently on Windows and Android
invisible shulker box that crashes the world when you break them
So I have some invisible shulkers that crashes the game and the realm when you break them.
Only one shulker is present in the tile entity data of the chunk.Coords of the shulkers :
675,64,7
674,64,7
Link to the world download :
https://drive.google.com/open?id=1d-m1r4NYiykCZ-avXwzL7Y-0GvSViqDI
So I have some invisible shulker boxes that crashes the game and the realm when you break them.
Coords of the shulker boxes :675,64,7
674,64,7
Link to the world download :
https://drive.google.com/open?id=1d-m1r4NYiykCZ-avXwzL7Y-0GvSViqDI
Jacob2of3, Yann, or anyone else experiencing problems with end gateway portals in 1.11: Please give more detail about the problem. Is it only occurring in portals that were generated prior to 1.11, or in new gateways as well? When you use one, are you suffocating inside the portal or does everything eventually go black and the game crashes?
There were many reports of problems using end gateways that were marked as duplicates of this report, because our best guess at the time was that they had the same underlying cause. But it's possible they were actually different problems that the developers didn't fix, and you're experiencing one of those. This seems likely given that a lot of people are apparently no longer having the issue described in this report. If so, we may need to reopen one of the duplicates and work on a specific fix for it.
Yann: That actually sounds like exactly the same issue, although perhaps on a larger scale. The collateral damage I was talking about is that chunks around the portal become unrenderable. The blocks are there, but can't be displayed for some reason, so the graphics engine just skips over them. For most people, that happened at the outer portal, but in your case it happened on the main island side, which isn't surprising since the original bug was rapidly flipping you between the two portals. The only difference is that you happened to be on the main island side when the collateral damage occurred.
"If we log out and back, we get stuck on the loading screen": I assume you mean the world loading screen, the one with the "Generating world" box. I think you'll find that you're not actually stuck there, you're in the world but in the damaged chunks. The graphics engine can't render those chunks so it doesn't overwrite the loading screen as it should. I learned this in Windows 10 when I thought it was stuck on the loading screen. I minimized the game window, then restored it, forcing the graphics engine to redraw the entire window. That left me with a black screen, and then I knew I'd been in the world the whole time.
Unfortunately, this probably means that a large chunk of your main island is damaged beyond repair. If it doesn't include your spawn point, you might still be able to use the End and maybe even fight the dragon again, but before you can do that you'll have to get out of the damaged chunks. You can do that as usual by walking and jumping, although you'll have to do it while blind and you might walk off the edge and die (but would then respawn in normal chunks again).
![[Mojang] Mega_Spud (Jay Wells)](../../../data/avatars/users/92696.png){kind=small}
Yann At this point I think the issue you are describing would be best tracked in its own ticket - if you could please create a new one with steps to reproduce, it would be appreciated.
Thank you Yann - the crashing issue with 4 loading ticks remaining is being tracked at MCPE-46684.
Yann: I'm rather confused by all the discussion, some of which seems to have extended the original bug description, but at this point I'd say we probably don't need an additional ticket. This ticket has been passed to the developers and they will read everything here, so I don't think anything is going to slip through the cracks.
Steps to reproduce :
All the remaining objects are apparently deleted.
I had this issue yesterday, upon reconnecting today I got my items back.
I reproduced it to do screenshot, reconnecting works if you have enough space. Otherwise you get the max amount back but the left over disapear (I tried to free up some space and reconnect a second time).
I tried to reproduce it a second time, to demonstrate it to someone, and this time items dropped on the floor.
I confirm that this still happens in 1.11.1.
We opened the end portal yesterday so it's a 1.11.1 ender gate.
Hi,
I belive I didn't had exactly the same issue, when going back to the main island using a 1.11 generated end gate, we get teleported back but the terrain is not rendered.
We can actually break blocks or put some blocks down, we can even see enderman.
If we log out and back, we get stuck on the loading screen.
Loging back a few minutes later and everything is fine.
This happened to me twice this past week on realms, buttons would not generate signals anymore, breaking them and replacing them would fix it.
Comparators, observer and torches wouldn't work either.
This seems to be chunk related since the redstone on the next block but other chunk was working well.
Disconnecting/reconnecting would randomly fix the issue by itself.
Hi,
This is still occuring all the time in 1.11.4, on realm, with either android app client or windows 10 client.
Logging out on top of glass with :
Above :
Under :
Log back in,
Instant death under bedrock :
This happened to me twice, I tried it again to try to anderstand what happened and it happened again.
So I think this happens all the time, I not really willing to try it too much, since I lost two sets of fully enchented gear already
Logging out on top of glass with :
Above :
Under :
Log back in on the slab :
This is reproductible 100% of the time.
I never relogged on the glass block I unlogged on in this area.
I tried to reproduce it on creative without success so far
I'll ask the owner of the realm for a world copy and see if it can help.
After a bit of tickering, I found that the important factor here is lava.
What I did :
- create a 3x3 pool of lava (only one lava source on the center is required)
- a few air blocks above this create a 3x3 glass platform
- logout on the glass platform
- log back in, one block above the lava a few blocks on the side of it.
This is 100% reproductible on my realm. But doesn't seem to happen on worlds.
Lava is the important part, I tried to put water instead or glass blocks and I would log back on the same block I logged out.
In my second test yes I respawn a few blocks over 'safe'.
However as I said in my previous comment I have a case where I respawned under bedrock.
I suppose that the game checks for a safe place from y=255 to y=0 and if it doesn't find a 'safe' place, you will end up at y=0.
The fact that the game doesn't consider a glass block a safe place is probably the real bug here.
Leaves instead of glass triger the same bug, however upper slabs are ok.
There is bug in texture update when putting on horse armor.
If you put a colored leather armor on a horse and then put a diamond armor, sometimes the texture is not updated.
Leaving the game and logging back fixes the issue most of the time.
Bad game design could be considered a bug though.
Will you reopen this ?
Should I open a new one with the demonstration on how to build a platform that will make you log in under bedrock ?
I had a bear spawning on a glass block or a hopper yesterday
You are lucky it only freezes, on Android it crashes completly.
Most of the time I have to restart the game 4-5 times before I can play.
Happens with smokers too.
The wiki says that in 1.12 they increased the amount of trades before a villager locks out.
That will help with the amount of time needed to unlock all trades for a villager, but prices are unchanged.
This is still a thing in 1.11.4
Steps to reproduce :
- place berry bushes on a 9x9 square
- wait for them to grow (increase random tick speed)
- spawn some blazes on them
Blazes will take initial damage then not take any damage even while moving/jumping...
Still a thing in 1.11.4
I have 74GB available on my phone, minecraft refuses to download the realm.
This is a thing since 0.15 version.
Android version will sometimes crash multiple times before it accepts to start.
Clearing the cache usualy helps.
Crops do not grow at light level 8. That's how it is supposed to be.
https://minecraft.gamepedia.com/Light#Blocks_2
1.12.0
One plus 6
20190805_125323.mp4
Hi,
I went though my world file with a custom script.
I have 15 chunks that have more than 1000 pendingTicks all of them being from kelp blocks. All those chunks have the same redstone issue.
I might be able to extract one of those chunk and attach it to this ticket if you are interested.
This is a duplicate of https://bugs.mojang.com/browse/MCPE-46540
Your video link is private btw.
Currently realms are 1.12.1 while client version is 1.12.0, so we can't open a realm world after downloading it.
The wiki is fairly accurate : https://minecraft.gamepedia.com/Trading
Multiple differences make it very long and costly to level up a villager :
- A Java villager need 480xp to level to master, 540 on bedrock.
- Small trades give less xp on bedrock edition (ie Armorer trade coal for 1xp on BE, 2 on Java)
- You can trade a lot less (ie Armorer trades 6 times coal on BE, 16 times on Java before locking up).
- Villager don't instantly restock when leveling up (like they did before 1.11 and still do on Java)
- Trading prices don't depend on player's popularity in the village, so the prices always go up and you have to wait a lot of game days for them to go down. In Java popularity decreases prices.
- Curing a zombie villager don't decrease prices like they do on Java.
The fact that you can trade less also makes a lot of trades useless, for example quartz blocks from the stonemason. To get a stack every restock, you need 5 villagers on java, 13 on bedrock.
If you actually want to take advantage of villagers and trading to build, you need a lot of villagers which mechanically means a lot of entities and lag...
This bug is literally bringing realms down.
Steps are easy to reproduce :
- Create an new world
- Load ocean chunks with kelp in it
- Wait... (To speed up the process you can increase randomTickSpeed)
At any point you can take a look at the nbt data of that chunks to assess the amount of pending tick that will never be removed, but still be simulated every tick by the server.
When the numbers get too high the server starts to lag and end up crashing.
He is saying that campfires are not stackable on bedrock and they should be because they are stackable on java.
Every game tick there is 1/7000 chance for a golem to spawn if there is at least 10 villagers and 21 beds
Max average rates for one village is 41.14 ingots/h
It would be very easy for the devs to tune those values.
At least until we get parity with java, if we ever do.
I attached a behaviour pack that :
- Get rid of the disparity in xp requirement to level up a villager
- Make the trades identical in number/prices
Unfortunately restocking and price decreasing requires dev team intervention.
So, in 1.13 they added a new bug to the villages mechanics,
Basically, they wanted to prevent pillager patrols to not spawn inside villages. So they added something that computes the rough radious of a village instead of just using the village center.
The issue with this new method is that it's bugged, and breaks stacking villages technics.
I'll open a new bug about this because it breaks a lot of thing in villages.
Make sure they have beds.
I can confirm this happens quite often.
So I did a bit of testing and this is what I found...
The circle has a ~38 blocks radius and is centered on the village center.
The fact that it doesn't behave the same way on android and windows makes me think of an undefined C behaviour, like casting a negative signed value to unsigned.
Also I can confirm this still happens in beta 1.14.4
Happens on android too,
Up is switched with left and down with right.
If the player rotates they go back to normal.
Hi,
Your world is probably corrupted.
You can try to edit your world with Universal Minecraft Editor or mcctoolchest, locate the chunks with the coordinates and delete those chunks.
Make a backup before using those tools !
Editing the world with UME/Toolchest and adding shulker boxes with the same coords as the invisible shulker boxes in the tile entities part of the chunk allows the shulker boxes to be visible and broken.
I was just letting the dev know that shulker boxes are present in the block data of the chunk, but not in the tiled entities, and that's what is crashing the game.
Hi,
The world if from a realm. The earliest back up I have of this is June.
The world I uploaded is truncated, I removed nether/end and reduced the overworld, the original file is 500MB and backups are larger. I'm not sure how I could make them available to you.
Are piston arm collision in the same chunk ?
I don't believe there ever where pistons in that chunk.
There was invisible chests too. I broke them before crashing the realm.
The only work around for that is having minecraft on windows.
Or find someone that has it and that you can trust with your account password to get the worlds and send it to you. I wouldn't recommend it. But at this point...
Chunk borders and sub chunk borders don't transfer light level sometimes.
If you go in an ocean and place a sealantern at y=64.
Unload the chunk reload it, the top face of the sea lantern will have light level = 0
And mobs will spawn on them.
I've only noticed this since 1.13, so it may be another bug.
They changed the aging system to have parity with Java.
So each time a kelp block is ticked there is 14% chance for it to grow if it hasn't reached the max age.
Pre-1.14 there was 100% chance for it to grow, so it should be ~4x slower than before.
However, sometimes the kelp, just stops at random age, this is the real bug.
Steps to reproduce :
- Create an empty world
- Make a water column
- Plant kelp on the bottom
- raise random tick speed to 4096 (kelp plant should grow at least twice per second)
- wait a few seconds
- look at nbt data of the chunk to check kelp age.
Of course rates will be slower from java because it's random tick based. And if they keep the parity, it will be always slower unless you setup your random tick speed to 3 to match java's.
But it's very easy to make a test where kelp is not growing. and it's age is nowhere near 26.
Getting the age of the kelp is a bit tricky because it's in the block data part of the chunk nbt data.
I would assume it's a collateral of the pendingTick bug they "fixed".
I've looked at the code, and there is a method called fetchClosestVillage in the VillageManager class that is used to distribute poi and villagers amongst villages.
The fact that you can't find that it's the closest village that is used, is because this particular method is bugged. Note that there is a limit to join a village of 96 on x-z and 38 on y.
To go into the specific of this bug, the methods computes the euclidian distance between a villager/poi and a village centers.
Since 1.13, it substract the "approximateRadius" which for square villages resumes as (x/2+z/2)*0.6, so roughly 38.4 blocks for a standard 64x64 village.
This gives a floating point value that is negative when you are less than 38.4 blocks away from a village in a sphere.
The error in the code is casting this negative floating point to an unsigned integer, which results in undefined behaviour in C++.
On Arm devices, results is 0, on x86 devices it's (2^64)-1-value).
This is still affecting 1.14.30 release.
Simple and easy to check, make a kelp field and push randomtickspeed to 4096, admire very little to no kelp growth...
Can you share your testing protocol ?
I tested this :
Make a 16x25x16 water tank.
Plant kelp
increase randomtickspeed to ~1000, so that it doesn't take ages.
Kelp barely grows higher than 2 blocks.
If the age system was working properly growth should be equaly distributed in height (0-25).
They changed the age system to that the max is 23 (was 15 before), and the 14% chance of growth in 1.14 (was 1 before). Parity isn't always a good thing.
It's not listed in the changelog but they did. This alone would reduce significantly growth rate, but it's not the only issue.
When kelp grow, the new kelp block has the age of kelp block below it +1.
The original kelp block doesn't incease its age (you can check in the block data of chunks).
So technically if you break the kelp block above it it should be able to grow again, which is the expected behaviour. But for some other reason, it stops growing.
After growth the original kelp block age is unchanged.
It's easy to get a world with kelp with an age < 23 that doesn't grow even with randomtickspeed at 4096.
It uses the same random generator the game uses everywhere.
I think it has to do with the pendingTick fix they made to remove kelp to fill up a chunk with pending ticks.
I'm also pretty sure they didn't change anything in 1.14.30 and it's just miscommunication.
While I like the fact that the initial explosion don't break obsidian anymore.
In the beta, blue skulls don't break obsidian anymore.
And the wither is supposed to be able to break all blocks around it when it takes damage, including obsidian.
Still applies in 1.14.30 and 1.15.0.51 beta.
The situation is explained in length in this video : https://youtu.be/3Fdy93XXC9U
Should we open a new ticket "kelp sometimes doesn't grow even with it's age < 23" then?
It's the same issue, the rates are bad because the kelp stops growing randomly, and not because of its age.
And a kelp plant that you can't bonemeal will never grow.
Hi, nothing changed in the code regarding kelp in 1.14.30
Growth is not defined by behaviour packs. You can search them there is nothing about kelp in there.
Are you it made the release ? Kelp seems to grow faster on the 1.15 beta. Even though it suffers from the same 'stop growing' issue.
Composter never accepted bamboo.
The fact that villagers always link in the same order is actually a pretty usefull and easy mechanic to use.
Villagers will unlink from their beds at night and possibly reset the village.
To prevent unlinking, always keep one villager with access to their beds.
If all beds are removed by the player, the village is removed and poi will be scrambled.
All of that is how village mechanics works.
However sometimes, they don't link at all, and that's a bug.
Here is how the current POI scanning system work :
- Each villager request the village manager to scan 32x8x32 area around the block it is on
- Village manager has a LIFO (last in firt out) where it stores scan requests
- A request can only be submitted once (if it's in the list it's not added anymore)
- A request is only processed, and removed from the list if a player is in the same region (I believe 512x512 around the block)
- The LIFO max size is 64
- Each query is splitted in 8 (1024 blocks scanned), to do so, the village manager only stores the position where it stopped scanning, not the request its processing.
This can lead to multiple situations :
1/ DDOS
- A village with a lot of villagers is loaded (lets say a trading hall with 70 villagers)
- Take a nether portal (at this point the LIFO is full, and requests aren't being processed anymore)
- Go to another place, at least 512 blocks out, using the nether, and try to do stuff with villagers. The LIFO is full so the villagers will not be able to query for POI.
This can also happen if you are on multiplayer and if a player logout in its trading hall.
This situation can also happen in the same simulation distance, a lot of villagers in one place can prevent one from linking if it's not in their scanning area.
2/ POI Scan expansion (infinite amount of block scanned)
- A village with some villagers is loaded (ie 0,0).
- The village manager start scanning for a POI on x - z, it does the first part of the splitted query
- The player go to the nether (+x +z coordonates, ie 50000,50000)
- The player go to the overworld and load an other village thousands of blocks away.
- The loaded villagers add queries in the LIFO, setting the end of the current query to those new coordonates
- The village manager goes from the last position it was scanning and continues, (from 0,0 to 50000,50000).
This can cause villagers to take a lot of time to find their POI. Especially on multiplayer worlds where multiple villages are loaded at the same time and requests overwritting the previous one all the time.
The only solution for the player is currently reloading the world or reseting/crashing realms.
For the devs, theeses could be fixed this way :
- using a FIFO (first in first out) instead of a LIFO.
- dropping requests when a player is not around.
- if you dropped a requets, reset the internal state of the Village Manager regarding last block scanned.
The limit of 64 could still be an issue for large multiplayer worlds, since there is a race condition in being accepted in the list, some villagers could never be added to it and never link.
I found a village that generates with only one villager.
So it's not "empty", but I wouldn't consider this as normal either :
Seed : -27149278
Coords : -2929 -3335
Fixed in 1.16.
After some code analysis, this issue comes from HopperComponent::pullInItems.
The method fetch entities around the hopper, but only tries to take the first item of the list.
It should try all items of the list until addItem returns true.