Armen Vardanian
Assigned
Reported
Comments
I would say that it's impossible for Mojang to build a correlation of reported issues unless a device model is reported along with the symptoms
To determine your device model, use these steps:
Go to {*}{*}the settings app (swipe down on main screen, click the gear icon) , then select About phone or About tablet.
Record the Product Name and Model Name
Click on Software Information on the about phone page and record the Android version. For added detail, you can include the Google Play System update date (may not be shown on older devices).
There are a few ways to collect the RAM on your device, but I suspect the three most valuable hardware specifications are:
CPU model
Amount of RAM
Graphics chipset
This information isn't always available through the standard android menus.I have found many android apps to have incomplete device data, which they lookup anyway, so I can't recommend any just for this. My suggestion is to use a site like gsmarena, search on your product name and confirm the correct device model name is on the page. Their page lists the key device specifications Mojang would need to know about and can also confirm what android version your device is capable of running (not what it's running at the moment). This search doesn't communicate with your device, it's just looking up specifications.
I do wonder if the google play analytics history Mojang would have access to reports the device models that are actively using particular versions. any device models that disappear from the stats after particular releases would be candidates for further investigation.
I have found predictable stutter related to camera changes, particularly when I'm dragging allays or frogs behind me and switching to reverse 3rd person camera to take a look. A particular stutter event happens on switching camera angle while in motion, whether in a boat or on foot.
This was seen on a Samsung Note20, running latest patches, connected via 5 GHz to a BDS survival world on a LAN on a performant windows system.
Here's a method to reproduce stutter on android, possibly akin to the above observation.
Start a flat world in creative. (I tested on a local world with 4 chunk render distance, not BDS)
Optionally drag 4-20 mobs behind you. in standard survival I find dragging allays in particular to cause lag, but for testing I used sheep and pigs that spawned nearby, creating a few more using spawn eggs.
I did some additional tests with stationary mobs, and with allays, without any noticeable difference in frequency.
Walk in a straight line in any direction, there will be single-pause stutters at regular intervals of roughly every 10-20 seconds.
I did additional tests flying at fast speed and on horse back, with no apparent difference in frequency or stutter length
Regularly change the camera angle while walking in a straight line and stuttering is more regular (a consistent ~1 second after changing angle when the stutter happens) and not specifically associated with any particular camera angle.
after further the number or frequency of camera angle changes doesn't result in a change of frequency, but when a stutter happens it's shortly after a camera change.
If you start walking in a small 2-3 block circle by spinning the camera in reverse 3rd person (and not changing camera angle), the stutter doesn't seem to happen, whether you're dragging mobs or not
Further testing of stationary tests with camera rotation + camera angle changes does show some stutter, whether standing or on horseback, and regardless as to whether the camera is pointing straight up or down.
It's hard to tell if dragging mobs in front (By walking backwards with the mobs sometimes off-camera ) has less of an impact, but stutters still happen.
Further testing suggests there's no variation in stutter frequency based on any mob behaviour, type or position on screen.
I tested with larger render and tick distances, and with all fancy options turned off with no discernable difference in stutter length or frequency.
My observation from testing is that I can reproduce stutter purely with camera angle changes, without any other observed variation from chunk loading, mob activity or even render distance. The stutter can be triggered more frequently with frequent camera changes, to a shortest interval of about every 3 seconds. The stutter itself is less than a second, but everything halts, including mob activity. dragging the sheep in creative, they were happily eating, but the eating animation, as well as the mob position would halt and then quickly update after the stutter.
I'm on android, 1.20.10 and I had the described symptoms, where the character creator menu would not render anything but steve. premade skins were fine.
I tripped over this bug without realising the cause and tried a bunch of potentially destructive things like reinstalling the game. I was contemplating removing my skins to see if that resolved it, before i tested and realised my xbox wasn't having the issue.
I am using a health bar addon, so by removing player.json, i lose my health bars for other players, so i can't tell who needs help.
Thanks for continuing to engage, EVGENSYPERPRO.
I would raise five observations, to affirm thay that the fix is not correctly implemented for this issue as raised on this ticket.
the horse has previously always fit in the boat both visually and functionally.
I don't recall observing any z-fighting issues when using this behaviour previously. (contrast the panda that visually is too big)
Although the horse is not the smallest mob to fit, it was always possible to get the horse out of the boat. certainly not as difficult as a ghast or panda on ths scale of mobs. This is the case without the java parity feature of showing hitboxes.
it only stopped fitting when a java parity element was introduced to increase the hitbox size of horses to match java. That had a side effect of removing horses in boats on bedrock
mobs still fit in minecarts when there is clearly
I would wager that a poll of the bedrock AND Java playerbase would have rhe majority say that having horses fit in boats is a core mechanic, compared to an incremental size of the hitbox.
we're having a notably useful feature sacrificed for simple consistency, which in the context of other inconsistencies still present, makes QOL worse.
a better solution that maintains overall expectations and QOL would be to:
reduce the difficulty of breaking oats on bedrock to match java parity to reduce the effort to break boats on bedrock
update java with a bedrock parity feature to set hitbox size to allow an adult horse to fit.
there's other alternatives possible as well:
set a variable growth limit on horses, so that sometimes a smaller horse is ridable but will fit
alter the boat mechanics to not be purely based on hitbox size but on ganeplay value. (tag:fits_in_boat)
can we request that a mod/helper that knows and deals with bedrock updates this ticket please?
MC-96212 relates to Java engine behaviour, whereas this ticket relates to bedrock, which had had horses in boats for many years.
This is a feature removal, not a fix. it is most certainly NOT working as intended.
Confirming that this bug is present on 1.19.30, when running a BDS on windows 11 and connecting with an android mobile bedrock client.
The symptoms are very close to described in the original report:
Approach a 1.17 created chunk boundary, with the adjacent chunk not existing and created in 1.19.
the new 1.19 chunk will initially render with a harsh boundary where heights don't align
after about 2-20 seconds the area will flatten out and potentially render into a different biome (I saw a desert turn into an ocean and a forest biome), but the flattened chunks will go completely dark even in the middle of the day; lighting doesn't resolve itself with any torch or other lighting placement to time of day change, although placing blocks in the dark area sometimes increases light levels slightly
rejoining the BDS instance without restarting it will still result in a dark patch shown
There is a 1.19 bug somewhere in the chunk creation/conversion engine that is resulting in light levels not updating after conversion.
This is still an issue for the latest 1.19.10.03 formal release.
What's curious is that there was a recent attempt to market the bedrock server release for the Microsoft developers, using advanced release beta builds, so there must be someone assigned on the backend in Mojang to facilitate this. Even a text-version of the changelog notes would be a good addition (assuming java content isn't erroneously put/left into the notes).
If there's no inclination to add a maintenance step for content updates, can we at least have a permalink to the latest changelog notes in the release notes txt?
I experienced this several times with boats in a fresh experimental world on Android/bedrock.
The boat would disappear before leaving the area, after getting out of the boat and walking/swimming a few blocks away. The last time it happened, I had a skeleton horse in the back and it disappeared too. no hitbox or interactions possible with either. The horse and boat reappeared after leaving and re-entering the world.
My 1.17.40 experimental world created on android 11 just after that version was released, is also seeing this.
what's very odd is that it spawned entirely surrounded by deepslate at y=-52! no torches were present.
By sheer luck, I found a chest 2-3 blocks into a wall dig. it had a variety of items consistent with with a bonus chest.
Unfortunately, I didn't realise what it was at the time, i thought it was a random spawning chest. I had turned on the experimental options on world gen including spawn variation of 5, custom biomes, and bonus chest.
i spawned halfway up a steep mountain (Y=83). i realise now that there was no bonus chest around. no torches either. I was keen to explore and promptly forgot about the missing chest.
A few play hours later, found this chest deep underground.
the purple beacon is the chest at -260,-53,-280
the white beacon is last spawn at - 259,83,-286
[media]same problem and crash experience with a fresh install of 1.1.6.40 specifically on an lg v20 (oreo 8.0.0), which was working on an older 1.16 release prior to a factory reset.
tried clearing cache and data, no joy.
tried fresh install, no joy.
i tried it with auto rotation on and off, but there's no obvious way to affect the rotation check that's seen in the previous person's adb log.
using the Microsoft launcher and edge (default) , neither of which have login issues. it's something specific to minecraft. maybe an interaction with chrome for the saml login prompt?
Tested and confirmed behaviour on a Note20 running 1.20.72, both in single player creative world and a BDS survival world. I also tested the workaround and it works.
Clearing the app cache and reinstalling the android software from the play store had no effect on existing worlds.
The render issue is on the inventory ragdoll and on the main screen
Changing any of enchantment settings in the accessibilty screen does not resolve the issue
The enchantment glint speed does affect how fast the gap on the helmet moves upwards, but doesn't affect the texture rendering.
Running textures from the market place has no effect; armour will render the correct icon in the hotbar, but not render correctly on the player model itself.
Applying the bedrock tweaks enchantment glint modification (by itself) has no effect on the rendering behaviour of armour on the player model, in any combination of vanilla or the workaround pack.
Applying cheeseballs60006's mcpack (mediafire DL variant) fixes the rendering at the cost of glint being removed entirely from the player model,
The glint is still present on the inventory icon and the icon glint mechanics are still affected by the accessibility settings for glint behaviour.
the pack also resolves the rendering for texture packs (I tested with Quadral), allowing custom enchanted armor textures to render correctly, albeit still without glint when worn.