MantacidTech
- MantacidTech
- mantacidtech
- Europe/Stockholm
- Yes
- No
MCPE-58091MCPE-81865MCPE-89023
MC-194404MCPE-90966MCPE-118199MCPE-131479MCPE-131484MCPE-134462MCPE-137096
Confirmed on MCPE 1.13.1
Do you think it would be possible to use this to cause client-server Desynchronization?
If you get far enough away from a wall of solid blocks with scaffolding placed right behind it, you can see a thin outline showing the contours of the scaffolding.
This may be related to
MCPE-8142, but I'm not sure.
Screenshots will be coming soon, but suffice it to say that the faces of the torches on repeaters and comparators are misaligned, and do not meet up at the corners of the model.The faces of the torches on repeaters and comparators are misaligned, and do not meet up at the corners of the model.
Edit: Screenshots Added.
While attempting to design a redcoder without target blocks, I noticed that redstone dust with a signal strength of 1 that points into A block after TURNING (as shown in the f
irstScreenshot) will not power the repeater coming out of the block it is turning into.When the signal strength is increased to 2, both repeaters light up, similar to pre-1.16 behavior (Shown in the
2nd screenshot).It is only when the dust points STRAIGHT into the block WITHOUT turning that the correct behavior is Demonstrated, as shown in the
last two screenshots.While attempting to design a redcoder without target blocks, I noticed that redstone dust with a signal strength of 1 that points into A block after TURNING (as shown in the fourth Screenshot) will not power the repeater coming out of the block it is turning into.
When the signal strength is increased to 2, both repeaters light up, similar to pre-1.16 behavior (Shown in the 3rd screenshot).
It is only when the dust points STRAIGHT into the block WITHOUT turning that the correct behavior is Demonstrated, as shown in the first two screenshots.
While attempting to design a redcoder without target blocks, I noticed that redstone dust with a signal strength of 1 that points into A block after TURNING (as shown in the fourth Screenshot) will not power the repeater coming out of the block it is turning into.
When the signal strength is increased to 2, both repeaters light up, similar to pre-1.16 behavior (Shown in the 3rd screenshot).
It is only when the dust points STRAIGHT into the block WITHOUT turning that the correct behavior is Demonstrated, as shown in the first two screenshots.
Edit: I don’t know how the screenshots will be ordered, and they seemed to change their order a day after I created the issue. Please try to guess from context.
NewRedstonebehavior is incorrectNew redstone "Pointing" behavior not behaving correctly.
When A Structure with trapdoors is loaded from a structure block, the orientation of the trapdoors respective to the rest of the structure is incorrect. This occurs only if the structure has been mirrored, rotated, or a combination of the two.
Attached please find a Zipped world folder for Minecraft on Android v.9 that’s contains transformations of a test model that demonstrate this behavior.
Edit: I apologize, This is for MCPE, I forgot to check the Project Feild.
Several events do not trigger skulk sensors, including (but most likely not limited to):
-pistons, dispensers, and droppers firing
-armor equipping
-food, potions being consumed.
-tnt exploding
-ringing bells
-placing sea picklesThese were just the things i immediately noticed. I will update with new testing.
Several events do not trigger skulk sensors, including (but most likely not limited to):
-pistons, dispensers, and droppers firing
-armor equipping
-food, potions being consumed.
-tnt exploding
-ringing bells
-placing sea pickles
-placing powder snow from a bucket (breaking it activates the sensor as normal)These were just the things i immediately noticed. I will update with new testing.
![[Mod] LateLag](../../../data/avatars/users/92884.png){kind=small}
MantacidTech - Helpers are basically volunteers with more permissions than regular users. Moderators (also volunteers) are above us and have even more permissions.
Sorry for the late response, MantacidTech. Running the command "/tp @s @s" will teleport the player under boats when they're floating up.
@MantacidTech the sounds do not at all play in the center. This is not intended because I mainly play Java Edition and the sounds are normal, also this only started happening with version 1.16.0. If it was intended. it would be in the settings as a feature under accessibility.
![[Mod] Anthony Cicinelli](../../../data/avatars/users/10122.svg){kind=small}
MantacidTech this is the java tracker your on bedrock. Go here for the bedrock tracker.
![[Mod] EVGENSYPERPRO](../../../data/avatars/users/92853.png){kind=small}
MantacidTech
Not. As I found out only with Sea Pickles.
MantacidTech Yup, it does the same thing as that
confirmed for Android MCPE 1.13.1.
Any way this could be used to cause Client-Server Desynchronization?
I don't really know what to say about this, other than It isn't due to client server desynchronization, since it wasn't affected by disconnecting the client. It's still interesting. I encourage you to experiment with this, try to reproduce it, and see what properties it has when interacting with non-player entities.
I may not be a moderator here, but I can tell you that this is intended behavior. to get your contraption to fully retract, you would need to pulse the top sticky piston after you retract it with the bottom sticky piston.
Are you sure it desyncs the client and server like you said? Try bringing another player account into the world, and have them tell you where you end up while attempting the replication of the glitch. Alternatively, attempt to toss an item from your hotbar. if it doesn't come form your position, the client and server are desynced. I look forward to hearing the results.
I've confirmed this bug is present on Android.
Another Question: How did this friend join the world? And who was hosting? Over LAN, Servers, or Realms?
Next test:Try to make a contraption based of this bug that would prevent you from teleporting back up to the boat. move a few chunks away, then set the time to night. See where mobs spawn: they'll spawn either in a ring around your clientside location or around the boat (radius approx. 24 blocks)
have you tried holy water?
if you could post the file for your skin, please do so, as it may help us.
you may have improperly linked your Nether Portals. Don't feel bad, Nether portal Linking is complicated. try destroying the portal you come out of, and building it further away.The worst that could happen is some free obsidian if it doesn't work.
While your other issues were certainly visible in the video provided, I noticed the boat only stuck in the wall when near the cobweb-hopper wall, leading me to believe the hitbox of the boat became stuck in a cobweb. the bouncing thing is still quite janky, though, but probably just a matter of tweaking a few values in the code.
DrownedZombie, I don't think that villager would agree.
The white line is actually the top faces of the sand blocks you are looking at. the height of your head is changing with the bobbing of the boat, allowing you to see the top of the block when you bob up. In short, It's a visual illusion.
I have seen this happen in 1.13 as well, but not with parrots. With armorstands though, it's pretty harmless, since they don't really know what to do with them.
this probably relates more to #MCPE-46309. It's the same thing, but with a boat.
This was actually the basis for minecart propulsion before powered rails in Java. It was called a "Minecart Booster."
The reason it happens is probably because the hitbox of the minecart is larger than a block, so it overlaps (and thus interacts with) a minecart on an adjacent rail.
This probably won't get changed, so do your best to wok around it.
I wonder if this could be used to create Bug-Powered pistons.
This is probably due to the fact that a Honey Block is not a full block on all sides. This means that standing on the very edge of a honey block doesn't apply the effects of the honey block to the player.
While the height of the model may not be the same, it's possible that the hitboxes are still consistent. Villager-like mobs cannot pass through a two block tunnel if the floor is carpeted, due to the size of the Carpet's hitbox. Make entrances of varying heights and see which mobs pass through what.
I honestly don't think this should get removed, simply because dual-wielding rocket launchers would look sick.
Honey Blocks aren't full blocks on any of their sides. This is intentional Behavior.
Okay, we're getting somewhere!
Create the device mentioned in my last comment on your friends world. He/she may need to help you determine if the contraption works. Once it does, have your friend enter the end (so he/she doesn't spawn any mobs and mess with the results). then perform the procedure described in my last comment.remember, mobs will spawn approximately 24 blocks away from the player's serverside location( where your friend/the server sees you). If desynchronization is achieved, your clientside instance (where you/your device thinks you are) will be able to enter that mob-spawning area and not affect the spawn rates in any way.
Also, I recommend checking out Docm77's older video on Client-server desynchronization with boats, so you can see what I'm testing for. He demonstrates the Mob spawning phenomenon I've attempted to describe in a very understandable manner.
PS: when you do this, please tell me how to make the contraption, so I can attempt the procedure myself.
Also confirmed to be affecting Android 1.14.0
I've noticed that, at 2:38 to 2:43 in the youtube video you linked me to , that the sound and effect of the block seemed to be dependent on which one you were looking at. I don't know if this has any effect on the results, but try the procedure again, taking this into account.
At 4:36 the particles indicate some kind of discrepancy in the location of the player. Like with your boat collision report, I suggest getting a friend to observe the effects of these experiments. I can't say much more, except that this looks like the developers somehow figured out how to get computers to use voodoo.
'That doesnt change the fact that it needs to be fixed.
Confirmed for android, 1.13+
Not on Android
I have observed this in my worlds as well. it is not just caused by relogging, but by unloading the chunks as well. It's still really annoying, especially when using these kinds of clocks to determine whre chunk borders are.
relates to MCPE-58151
If you want an unlit redstone torch, just power the block the torch is placed on.
relates to
MCPE-57063andMCPE-34497. I have reproduced both of these on Android as well in the latest versions.I don't know what helper means, but Makzevu Deserves a promotion.
I have actually used these client-side water sources to determine that rideable entities are handled by the server when no one is riding them, but are handled by the client as soon as they are mounted, in case that helps you guys fix any other bugs. Additionally, you can sill Riptide through these source blocks.
Confirmed for the rest of the music discs as well.
While in first person, only the hand is rendered. Increasing the FOV simply doesn't cause the program to load the rest of the body.
Directions to replicate this glitch may be beneficial.
I have found this before as well, however, it appears to be an isolated incident with no apparent cause.
This page may benefit from the addition of screenshots and a detailed procedure one could use to replicate the bug.
I am interested to know what would happen if the device from the 2nd teleportation example were used in conjunction with the desync procedure involving boats detailed in MCPE-59679.
Is the pulse also Inverted? If not, it's probably just a visual glitch. Otherwise, I would be interested to know how to replicate this, as it would be useful in a variety of redstone contraptions.
Additionally, this page could benefit from the addition of clearer images, to better demonstrate the conditions that produced this bug.
Thank you. I will now never be able to unsee this.
This is due to Lava's hitbox being a full block regardless of the model currently being rendered. Soul sand is shorter than one block, so your feet are actually within the lava's hitbox.
This is one of the funniest bugs I've seen in awhile.
Yes, I know. Fortunately, I think I know what has been causing it. Here is an Excerpt from a patchlog:
"Fixed an issue that would cause the armor to unexpectedly render on mobs when being held in its hand."
Evidently this also applies to totems. It is purely a visual glitch.
Blobs2: This randomness is due to the fact that piston head are tile entities in Bedrock, and as such are updated in a random order. In Java, they are their own block, and as such are ticked by a different updates.
As much as I want crouching parity, I don't believe the developers will take action on that aspect of slabs.
However, the issue regarding line of sign is very important. Unfortunately, I don't have any clue as to why this behavior occurs.
Just a theory, but perhaps this has something to do with outbound packets from the client.
When you left-clicked with the map, your client told the server to get info for the map. At the same time, it told the server to break the blocks. The server updates the map, and doesn't update the wood, because you were making a map, not breaking wood. At that point, the wood block was present for the server BUT NOT FOR THE CLIENT. This is proven by the absence of block-breaking particles, indicating that no block-break packets were sent to the server to cause it to generate the particles.
When the redstone dust was placed, a packet was sent to the server, telling it to place the dust. The server (thinking the wood is still there) says to the client, "You cant do that there's already a block here." The client then updated itself to match with the server's perspective.
regardless of whether it is a feature request, parity request, or bug, we can all agree that panes an bars need to connect to wall properly.
As has been said earlier, this is likely due to the hitbox of the minecart.
This would benefit from the addition of more details. Right now, I don't know whether to panic because togglable portals may not work, or if this is simply describing a different phenomenon.
Run the command /seed to obtain the world seed.
The height of the player is actually too low for their head to get stuck in the ceiling upon exiting the bed (It is a common misconception that the player is 2 blocks tall; they are actually only 1.8). I believe this issue is due to Carpets not being counted as a spawnable area. This results in the server attempting to spawn you inside the walls.
Temporary solutions you could try include removing the carpets or making your room 3 blocks high. However, I agree that this should be fixed, as it would make a good quality- of-life change for 1.16.
This page would benefit from the addition of more information. At the state it's in, this report is likely to be closed as "cannot reproduce" since you did not describe the procedure to replicate this bug. please do so, be it in text or video form.
If you could attach a video showing this phenomenon in action, I may be able to determine wherein the issue lies. This sounds similar to a previous bug involving unloading the ender dragon during its death animation to reset it and thus gain infinite XP. Try repeating the procedure but waiting until the wither's death animation finishes before exiting the end.
Redstone updates don't process in unloaded chunks. I'm not sure about random ticks, though. If they do, it may cause the hive to fill up without triggering the comparator. If it is possible on your platform, try setting up a ticking area at the location of the farm. Alternatively, build the device adjacent to a chunk border and have a device in the next chunk provide a redstone update to the comparator when it gets loaded.
This is due to loading chunks not causing block updates. if a water source (or flowing water for that matter) generates on the edge of a chunk, it will not get updated when a new chunk is generated adjacent to it.
I have observed this behavior too. I don't know if it's intentional, however.
This bug could be bad news for those trying to create TNT powered arrow launchers in the bedrock edition of Minecraft. I suggest testing which entities are affected by this. Projectiles, items, minecarts, etc. may behave differently than mobs with this setup.
If you can, Include a video or screenshot. I personally am mystified by this bug, and would like to know what caused this.
While the loading screen is being displayed, the player is actually already in the world serverside. It is possible that a mob killed you while you were still in the loading screen. I will vote for the issue in case I am wrong, but I am fairly certain this is the cause.
This is due to the way villager pathfinding is coded. check out this page: https://minecraft.gamepedia.com/Villager#Preferred_path
The higher the block cost, the less inclined they will be to move onto that block (or jump, as is the case for the jump row in the table.)
Therefore, this behavior is working as intended.
You are correct. That does indeed appear to be a ghost water source block. But to be sure, place a boat in the water (if it disappears when you do so, it is a ghost source. If not carry on.) If it is a ghost water source, the boat should behave as if there is no water there. If you then get into the boat, the boat will float. This is because rideable entities are handled by the server, until they are ridden by the player, then the client handles them. This handling behavior was most likely implemented to patch a bug in the early versions of minecraft that allowed for client sever desyncronization. This bug is demonstrated in the video below by Docm77:
https://www.youtube.com/watch?v=CQ1zX_jNMmY
There are several reports tracking piston inconsistencies, however, I'm not clear on what you meant by "the picture of the piston was fading." Consider adding some screenshots o videos to show what you mean.
I understood all those words but separately. From what I could understand, the issues you are facing are:
1) An issue with sprinting
2) A crafting bug that prevents you from retaining items in your inventory.
Additionally, please make a separate bug report for each issue. it helps the developers fix issues faster. Bedrock can be a buggy experience, but it isn't without its fair share of perks.
From what I can understand, you are pointing out a phenomenon that occurs when a falling block entity falls through a wall-mounted torch, which is intended behavior. If that is not the issue you were attempting to highlight, please clarify the issue by adding some details to your bug report.
This issue may be related to
MCPE-46767, as both appear to have a similar setup. Furthermore, the video attached toMCPE-46767may give insight as to what is happening. The items are not deleted, they simply appear in a different place than they actually are.I suggest you check out
MCPE-25593, as it describes the same phenomenon, and gave me insight into the issue.Edit: At the time of this posting,
MCPE-25593has been closed as cannot reproduce. this status is incorrect, as ken du has just reproduced it.Without a detailed description of the setup, I can only assume that the water is at such a low level that the item's hitbox collides with the block underneath it, causing it to slow down. replacing those blocks with ice should circumvent the issue.
You can attempt to recover the world through the filesystem on your computer. I am not familiar enough with the windows 10 version of minecraft, but I imagine you can find it in a method similar to on windows 7 (that is to say, searching %appdata% from the start menu). However, given that the world wasn't recognized by the game, I am uncertain as to whether or mot you can salvage it.
The number in the recipe book indicates how many times the crafting recipe can be performed with the items in your inventory, not how many items you will end up with after crafting.
Unfortunately, I have a feeling that this will be closed as "works as intended." However, it is a valid complaint about the Bedrock edition of minecraft. I for one would love to see this functionality implemented as it has been on the Java edition.
this may be related to a bug having to do with chunk corruption in large world files. If not, It may have to do with your device memory not being sufficient to load chunk data. This occurred frequently for me on my android device, due to an issue involving my internal storage.
I am unsure as to what you mean when you say that frames drop. Do you mean that the piston causes a decrease in FPS? or something else?
The beam disappearing is intended behavior. I am unsure, however, about the status effect.
To elaborate on Eyeth's comment, Animals spawn in packs of four, but all spawn in the same place. When you're flying around in creative, loading new chunks and spawning new mobs, you are looking at more white horses than you think. The reason that this doesn't occur in survival as much is because you load chunks at a slower rate due to not being able to fly to load chunks.
Confirmed for android, on the same version.
If it is possible to replicate the setup (possibly be recreating the world), a screenshot or two would be helpful in narrowing down the possible cause of the issue, as there are a number of things this could be from your description.
I have replicated the setup in 1.14.60. no blocks were broken, but the sticky piston head did appear to be inside the test blocks sometimes. I will continue testing.
Even more annoying is the fact that dispensing bonemeal from the side into the space above the grass block appears not to work, removing the only other method by which grass and flowers can be automatically grown.
This may be due to the fact that a flowerpot is always considered a flowerpot, no matter what it has in it. The warped fungus isn't placed as a separate block; instead its presence is reflected in the NBT data of the flower pot, and as such, doesn't repel hoglins. This doesn't mean your issue isn't valid, it just means that an oversight has been made by the developers.
From what I can tell, you went into a portal in the overworld, but the corresponding portal was not there in the nether. If I have misinterpreted this report, please clarify yourself, making sure to include details about all possible variables, such as the location, size, and orientation of the nether portal; along with the world's seed. I imagine this is a one-time occurrence, but if it persists, these details – along with a procedure we can follow to reproduce this glitch – will help those assigned to fixing the bug to do thier job.
it is my position that Quasiconnectivity should be added into Minecraft Bedrock, simply because it is so useful.
I encounter this issue when creating piston doors. This behavior is due to how updates are processed in each tick. When you flick the lever, the redstone signal is updated at a different stage in the update order (player interaction phase) than repeaters (world changes phase). this difference in timings causes the observed behavior.
In circuits requiring split second timings, this can be very infuriating. However, if you instead hook up the lever to a sticky piston moving a honey block with an armor stand on top, you can move the armor stand into a tripwire and power the circuit using that. this serves to update the redstone during a different phase of the update order, allowing the signal to pass through the block before the piston extends.
Edit: see
MCPE-31790for a more concise explanation from someone who actually knows the names for all the update phases.I have filed a similar report (
MCPE-79821), though I did not include soul torches. Redstone torches are included in the types of objects affected by this bug.I was upset as well, as I just got my phone fixed 2 days after the update dropped. I will be adding my vote to this issue.
77Tigers, If I wanted a block that redirects red stone without being powered, I would use a lectern.
Can you provide screenshots of the bug? I have a theory about the placement issue.
Additionally, You would do well to separate these two issues into their own bug reports, as not doing so can result in the issue being closed as invalid, which means no one will do anything about it.
Could you please be more specific? That may help diagnose the issue.
The sound may be dependent upon which side of the player the source of the sound is. This is probably intended behavior, introduced to help you pinpoint where a noise is coming from.
I found a stronghold like this once; it was so strangely generated that there was no portal room and some rooms cut off passageways entirely. However, I don’t think this occurs for me 100% of the time.
This is (Unfortunately) Works as Intended. As far as I am aware, MCPE has never had Specator mode.
If possible, could you provide a recording?
I experienced this on a factions server, but only in a certain place and only intermittently. This behavior seems to stem from the way Bedrock deals with player position and momentum. Long story short, The code rounds the heck out of the position.
This has plagued Bedrock for quite some time, since the Better Together update. Pistons in general have no set update order. The behavior has been marked “Works As Intended” for now; Mojang Devs have stated they will change this in a future update.
It may help to use a different design for the flying machine; looking for slimeblock quarries on YouTube has returned some decent results.
I got around this by dispensing the gold onto the block diagonal from the one the liglin was standing on, then opening and closing a fence gate quickly. This let the piglin think it could pick up the ingot, so it did.
This may be due to general fluid mechanics in minecraft incorrectly positioning the model due to the presence of another source block. To fix this, all one would need to do is make the liquid logic for lava ignore water except when forming blocks.
Could someone provide a link to the download? I haven't been able to find it in the marketplace.
Can you provide screenshots?
I will get you the screenshot, but I Play on mobile, and do not have an F3 menu.
This is intended behavior that was implemented to prevent unauthorized op on servers.
In case the email that informed me that this issue was reopened was erroneous, the bug occurs on Android, Which I believe falls under the project you specified in the statement you made upon closing the issue.
Edit: Nevermind.
just so you know: skeleton horses that spawn naturally will turn into four skeletons riding skeleton horses when you get close. so dont.
The amount of space that a mobile device HAS is often more than the space that the user can actually USE.
Will this be fixed for 1.16.2?
The reporter’s request - while not a bug report - is still a prevalent issue in Bedrock. Please fix it.
I believe this may be something that is working as intended. Slabs only pass a signal in one direction, either up or down ( but I can never remember which it is for the life of me). If you’re dead set on using a material that would blend in with the shelves, try cleverly placed stairs. I’m not sure if they will work, but it’s a start.
This is very interesting! Can you find a way to reproduce this effect reliably?
This is intended behavior. As far as I can remember, powered pistons were never able to be moved.
This bug is a byproduct of a fix for a different bug which got rid of sand pushers that were possible in 1.14.
I have experienced this too; however it seems like this feature was intended. You can accomplish the mid-air sneak you need by holding both the up and down fly buttons at the same time. I still agree that a sneak button that works wether you’re flying or not would be a welcome addition to the mobile version of Minecraft.
Confirmed for Android 1.16.1, though on this platform, the bug only caused a pause in the flickering of the torches. This could, however, still be used for wireless communication if some observer- based circuits were added to the contraption to produce a reliable pulse output.
From my testing with this bug, I have deduced that it is caused by a problem having to do with the number of updates in a certain tick. I had accidentally made a T-flip-flop utilizing this underlying issue back in 1.14, however the basic principle is the same: too many Queries caused by redstone components, and the rest of the pending queries need to wait for the server to catch up. This means you can just move a block behind a comparator and the receiver will STILL TRIGGER.
This bug still works if the activation piston is in a different chunk than the torch clock. Testing is underway to determine if the phenomenon occurs If the clock is loaded by another player at a considerable distance. Experimentation is also being conducted to determine if it is possible to have multiple isolated wireless connections transmitting pulses at the same time without interference from one another.
Can confirm this is still present in 1.16.1, although it seems to have gotten worse. There was a full block between me and lava, yet I still caught on fire.
I have seen this occur when they run into a few carpets stacked on top of each other. They refuse to pathfind anywhere else. Same with endrods.
Confirmed for latest version of MCPE. I believe this may be an issue with the client sending weird velocity packets to the ender pearl upon creation. I will test this further, as it frustrates the creation of viable ender pearl stasis chambers.
Is this behavior dependent upon the orientation/position of the contraption?
Attempted to reproduce in 1.16.200, was unable to do so due to another bug that causes detector rails to be stuck in the On state
Does this occur with other blocks?
This could benefit from a video, mostly because i need to see this to believe it.
Block breaking is slowed by water in 2 ways:
1) if your feet arent touching the ground, and
2) if your head is submerged.
These effects stack. This is intended behavior.
This may be a side effect of piston inconsistency. The dripstone is pushing the piston before it has a chance to activate.this will occur even if blocks other than dripstone are used (assuming that those blcoks are able to be pushed by pistons as well)
Connor, I think you are right. I remember seeing something on the MC bug tracker that talked about coordinate rounding. I would also like to add that this bug is an issue with the client, seeing as I could still reproduce its effects when playing on a java server that i was connecting to with my bedrock client via proxy.
Still present in 1.16.201, which I found out after having to go through a build and manually replace every trapdoor.
Hey, this issue is gonna get closed as incomplete if more details aren’t included. You need a way to reproduce the glitch, or at least a world download so the properties of the block can be observed.
How does your game reach BELOW 0FPS? Can you include a video, I kinda want to see this.
The slabs were bottom half slabs, correct? Because mobs spawn on top half slabs just fine.
This is actually an intended feature, called repeater locking. By powering the sides, you prevent the repeater from changing state, even if the block powering it changes. You can still change the delay, however.
Gravity blocks have had issues like this in the past, previously with piston heads and slabs with air beneath rather than shulkers. These bugs were used to make devices called sand pushers, before the behavior of falling block entities was changed to make them break after 30 seconds of fall time. It’s possible that, seeing as a shulker is an entity with collision, it can affect the falling sand in a similar way.
Parity issues are tracked on the bug tracker since the buzzy bee’s update.
This appears to be a form of client-server desynchronization. The server thinks you are still on the strider, while your client thinks you are elsewhere. You cannot break blocks further than 5 blocks away because the server calculates your reach based on your server-side position.
This report is also reproduced by
MC-217736Duplicates
MC-217736, which is related toMC-201647.This happened for another friend. Th player cap was shown to be -2billion or something.
Hi. Sorry for not getting back. I havent been able to test this in the latest version due to not having a lot of free time. I remember seeing it happen a bit more recently, but i will try to test it in the newest version. As for the steps to reproduce, here they are:
1)build a staircase using stair blocks (note: might be directional)
2) build a roof above the staircase, again using stairs, but upside down this time) such that there is a 2 block gap between stairs that occupy the same x and z coords.
3) sprint up the stairs
4) attempt to sprint back down
Expected results: the stair tunnel would not be traversible, as the players hitbox is 0.6 blocks in width, causing the upside down stair that is located 2 blocks above and one block in front of the stair you are attempting to climb to block your movement.
Observed results: you can sprint up the stairs just fine, but you cannot go back down.
Ive found this issue as well; and discovered that any orientation works as long as there is a block adjacent to the tip of the cluster. Useful for building though, so this is one of the better bugs I’ve encountered.
I’ve seen it happen here and there, but I Haven’t tried to intentionally reproduce it in 1.17. I’ll check and let you know.
I have found that if the component the armor stand is on is activated, the armor stand will change state, even if the component is being powered indirectly. This includes stuff like lamps, repeaters (which arent pointing into the stand, by the way), and even the dragon head. Are the trapdoors being powered? That might explain why the armor stands are reverting.
I have found that the signal transmits through blocks that aren’t directly powered. For example, an armor stand on top of a redstone lamp will change pose if the lamp is powered through a block. Many other things that dont even conduct redstone also work, the strangest of which have to be the dragon head and TNT.
I have attached the screenshot to the report. As you can see, the dust is not pointing into th block behind the repeater.
I am unsure. I will check and get back to you.
I have noticed this. I think the relative sea level code was implemented incorrectly or not at all.
I have found that in the latest version, an android device can connect to a world hosted on an IOS device, but IOS cannot join android hosted worlds.
I have just realized that that was not my screenshot. However, it shows the bug very well.
I can confirm that this is the case. I joined my sister’s world (hosted from her iPhone) with my android phone, and neither of us could see the other’s skin.
Do you have the hopper minecart on a powered activator rail? If not, then it might be what is sucking all the items out, as it isn't locked.
I’m not sure i understand your issue. Could you send a video showing how to replicate the bug?
This seems like block lag. Including a world download might be helpful, as it could then be investigated as to whether this is the case.
To explain what youre seeing: that is a TNT entity. It was pushed through a portal at the moment it blew up in some past version, rendering it stuck like that. You can move them around with fishing rods. They’re a neat little novelty item to have.
If you want to get rid of it however, try running a command to kill any primed tnt entities.
This is still a problem. It Affects the most recent 1.18 beta on android 7.0