mojira.dev

Philip Cooper

Assigned

No issues.

Reported

MC-186183 Shulkers open into other shulkers when unable to teleport Won't Fix MC-186172 Shulkers open into blocks when unable to teleport Fixed MC-168900 Shulkers teleport with original dimension coordinates after passing through portals Fixed

Comments

Yeah, I was concerned about the deterministic method's performance, but I thought there might be ways to mitigate it. Perhaps if it was able to be spread over multiple ticks, that could reduce the impact, but then of course, that would require extra data fields to save the search's progress. Alternatively, as most inexperienced players sending a shulker through a portal would expect it to appear near the front or back, a deterministic search over a small region in front and back could be used if the normal placing method doesn't work after going through a portal.

Likewise, I can see the issue with block updates. I wasn't positive how the entity AI's keep track of blocks around them, so I was just throwing out ideas.

I can also see the benefits of the current behavior, the main issue I see is that inexperienced players trying to get into technical minecraft will likely not have an optimized layout for shulker attachment, so a notably larger percent of the shulkers could be lost. Of course, once renewable shulkers are in a major release, that loss will not be as frustrating as it would be in the current release.

One major caveat to your final note about it still being possible to get the 1/8 conversion: even if you provide a reasonable number of valid locations on the other side, there is a moderate chance the shulker will not be able to find a spot before it gives up and appears at it's original dimension coordinates.

I believe there are several ways this could be patched in a consistent and useful way that is significantly less confusing to the average player.

All of the ways would start with the shulker arriving in the portal frame in the other dimension and looking for a valid attachment point, similarly to the current behavior. Afterwards, if it doesn't find an attachment point, one of the following could happen:

  1. The shulker remains in the portal/position it should be according to usual entity behavior, periodically searching for an attachment point.

  2. The shulker behaves as in option 1, but instead of periodically searching for an attachment point an indefinite number of times, it searches an optimized number of times and then gives up to reduce lag until a nearby blocks update occurs, causing the procedure to repeat.

  3. The shulker behaves as in option 2, but before giving up, it performs a deterministic search for attachment points within the teleportation range.

  4. The shulker behaves as in option 3, but instead of giving up after the deterministic search, it follows the current behavior and goes to its original dimension coordinates in the new dimension. Thus the current behavior is somewhat preserved, but it will only be likely when players intentionally plan for it.

All of these methods retain at least some consistency in portal-entity interactions while accounting for some of the unique shulker behaviors. They also all either significantly reduce or completely eliminate the chance that players who aren't highly familiar with the technical community will encounter the current poorly documented behavior that can cause them to waste hours of time without a clue as to what's going on.

No confirmation that I know of. I was saying I think it is likely WAI because the durability loss system seems intentional. No durability is lost when cast into water without catching anything, 1 durability is lost when something is caught, 2 points are lost when the lure collides with a non-water block, 3 are lost when reeling in item entities, and 5 are lost when reeling in mobs.

I think this works as intended. MC-29768 is almost exactly the same issue, and was marked as such.

Reported MC-186183 for the related issue I mentioned in the above comment.

Issue is still present as of 20w20b. If the shulker lacks a valid space to teleport to, it will still open into the block above it. Expected behavior would be that it would be unable to open.

[media]

This issue is still present as of 20w20b. While shulkers attempt to teleport away if they would open into another shulker, they will still open if they cannot leave the block due to a lack of valid teleportation locations nearby. Expected behavior would be that they would be unable to open if not able to teleport.

[media]

Can confirm that shulkers in minecarts do not count toward the cap, but outside of minecarts they do. Can also confirm that witches in minecarts still count toward the cap.

Right clicking with glowstone will not set your spawn unless the anchor is fully charged. If it's not fully charged, you have to right click with another item or an empty hand to set your spawn.

If this is a bug, than I would assume that the fact that dying in creative mode also causes the respawn anchor to lose energy is also a bug.

I've been unable to replicate this bug. Could you give a more specific example of the steps you did?

If you updated the world to the snapshots, you'll have to explore far away from the parts of the nether you explored before the snapshots. The parts of the nether you explored before the snapshots wouldn't have ancient debris because they have already generated, and new blocks will only appear in terrain that generated while you were using the snapshot.

I think it is best the way it is. Having netherite be extremely rare adds some interest and value to getting it. It would be kinda strange to me to be able to farm netherite armor from a spawner, even if it was extremely uncommon.

While it may make sense to lower rates to improve the experience of exploring/building in the Soul Sand Valley and Warped Forest, I think keeping somewhat increased rates for both (and for fortresses in the Soul Sand Valley) would be nice because it would add add some incentives to choose one biome as opposed to another for mob farming.

This is almost certainly a duplicate/combination of MC-139265 and MC-176399

From my experience, entities in general with passengers (like boats, and presumably jockeys) don't pass  through portals. Probably an intended feature.

Still an issue in 1.15.1

Still an issue in 1.15.1. Have tested with sand.