Projectiles launched by the player fall through blocks, sometimes into the void, when player moves far away

Confirmed broken on Realms via Xbox. 

Trident will despawn after the chunk becomes unloaded. 

I could not reproduce this in a flat world I made for testing. Does it only happen in worlds created before the 1.17.30 update, maybe?

@goldenhelmet …. They said they tested it in the later BETA so I’m guessing it’s not that.

@goldenhelmet - I don't have a non beta world, but I was able to duplicate in a new creative, flat world in hard mode. Throw trident and move 200 blocks away. I discovered this morning you don't need to wait 30seconds, it will despawn. I also discovered that moving 120, 150 or 175 blocks away will not cause it to despawn. I'm playing on sim distance of 4. Render distance 7

Forgot to mention it was a new 1.17.40.21 beta world

I can confirm, as my realms trident killers have all gone inert. Lost about 18 tridents before checking the bugtracker. Glad im not crazy.

The tridents don't actually despawn, they clip through the world (and possible mobs underneath) when outside the player simulation distance. The video

I attached should show what happens when I exit and quickly re-enter the specific chunks using teleport commands. The tridents fired by Drowned are not affected.
Ticking area commands can't fix this

That sounds like it could be related to MCPE-138740 or any of several other tickets recently reporting entities that glitch through small gaps when a chunk is loading, but which they can't fit through during regular gameplay. For a list, try searching for the keywords "glitch through".

This is slightly different, because the tridents shot by the drowned are perfectly fine.
Based on my testing, the tridents actually start clipping through the world while unloaded, but stop clipping when loaded again.

this also affects arrows

Strange, because if they are clipping through the floor, would they not just fall into the air space blow?  I have an open area below where mine was thrown and it was not there when I checked.  Testing this in a flat world should be easy, throw the trident on a raised platform instead of on the base ground level.

OK, I threw six tridents on a raised solid-block platform with two air blocks underneath, then another layer of solid blocks.  All six tridents disappeared when I moved ~200 blocks away and returned.  They do not appear to be clipping through the floor.  If they are, I would not expect them to clip through the second floor,

Further testing,

Tridents disappear regardless of the face they are thrown on (top, bottom and all four sides).

I verified that the tridents status using commands to make them say 'hi' in chat if they are loaded.  Tridents were responding until I moved more than 16 chunks away. (Sim 4, render set to 8)

Tridents thrown on top, side, and bottom faces will remain in the world if the player relogs near to them (in my test, I logged out and back on in the same chunk they were thrown).  After relog the one on the side face fell to the ground below, the one on the bottom face is floating a half-block below the face.  This behaviour is similar to how they behaved on 1.17.11 and prior.

I was finally able to reproduce this based on comments above and outside help. I am finding that the trigger distance is Render Distance + 5 chunks away from the chunk in which the trident/arrow is located. For example, with render distance set to 6, tridents at -1, -1 and -1, -5 fell through when I travelled to 0, 176; or when I travelled to 140, 140. With render distance set to 12 I had to travel more than 272 blocks away from the chunk. I confirmed that they were falling through when moving away and not when reloading/moving back using /execute commands to detect them.

Arrows also fell through as noted by a comment above, but items dropped in the chunk did not. Snowballs floating in bubble columns also fall through at the same distance. So it seems that the bug here is really that projectiles are being simulated at infinite distances. That could be related to the fix reported for choppy projectile movement far away (MCPE-101102).

Wanted to confirm this broke all my trident killers while I was exploring more than 200 blocks away chasing an achievement.

This affects all projectiles that can be fired by players, not just tridents and arrows. I tested with splash potions, bottles of enchanting, and other gravity affected projectiles.

I believe this affect hopper minecarts as well. Hopper minecarts I have sitting still (for example jammed into blocks in trident killers) are disappearing when I leave and come back.

Issue still persists on realms. Built silentwisperer guardian farm with 21xImpaling 5 enchanted tridents plus 2xImpaling 5 tridents from gold farms all gone. Worked fine prior to latest update v1.17.3202.70 on xbox which was intended to fix the issue we didn't have on the realm in the first place. Tried testing hopper minecarts but they seem to be working as intended. Back to farming trident and emeralds I guess :/

Here is further confirmation that tridents are falling into the void, not despawning, when the player moves far enough away. My render distance is set to 10 in the video.

In Windows 10 PC Bedrock v1.17.40.20-23 Beta, a minecart with chest is falling into the void. in a similar fashion as the trident.   

I have made a behavior pack that can prevent tridents from falling through blocks.

. It is only a partial patch because tridents attached to the sides of blocks still slip down when unloaded or reloaded. They only will not fall through the tops of blocks, so they won’t be lost in the void. The pack works by removing tridents’ projectile component when the nearest player is >191 blocks away.

While testing I found that the bug has another effect distinct from allowing tridents to fall through into the void. They also fall down from the sides of blocks when reloaded even if the player does not move far enough away to unload the blocks. For example, if you relog while right next to a trident it will slide down the side of its block. This makes some trident killers that used to be relog-proof now require the tridents to be re-thrown after relogging.

Jessica B: that sounds like a different issue. If you can reproduce it please make a new report with as much detail as you can gather. The issue on this report is specific to player-launched projectiles.

 >>For example, if you relog while right next to a trident it will slide down the side of its block. This makes some trident killers that used to be relog-proof now require the tridents to be re-thrown after relogging.

This is similar to what happened in my gold farm w/ quad 2x trident killers (single player).  I logged off to do something while it was running, then upon logging back in i noticed none of the zombie pigs were dying.  Set to peaceful to troubleshoot and found that all 8 tridents were gone.  I had initially thrown them at the center of a 2x2 blocks on the floor though, not the sides of any blocks/pistons.

I have received confirmation from multiple players that this is fixed in 1.18.0.20 Beta.

@GoldenHelmet - will that fix eventually hit 1.17.x as a hotfix or will we need to wait for 1.18 before using trident killers safely?

We don't know. Mojang doesn't publicly announce such information and the bug tracker staff don't have inside access (and couldn't disclose it if we had it, either). However, you can already use trident killers safely by storing the tridents in chests between uses. They don't normally issue a hotfix for a problem that has such a reliable, easy-to-use workaround.

the workaround may not be practical if the user is on a multi-player realm with unplanned disconnect and other players are within chunk load/unload distance. 

I have a guardian farm with 50 tridents in it. it's use was ideal for my large scale mining project, so that i can very quickly recharge the durability on my tools. But relocating 50 tridents twice everytime (before and after use), isn't a very quick process. It destroys the efficiency of my farm. 

Also if I'm not mistaken: there's another bug where tridents now take damage uppon being thrown. Meaning the tridents wil break after a certain amount of uses anyway. so it's only a very short-term workaround.

In my ghast farm tridents dissappear even when chunks are loaded. The tridents are towards the middle of the mob spawn  area of the simulation distance but still within. Possibly happens when one player leaves area but another player remains. >Just adding this addtional because the comment prior minimizes time needed to remove tridents. Many of our late game farms are very hard to get into to get the tridents without tearing layers of the mechanics off. Some farms that we have can take hours to get into to remove the tridents and rebuild. Played in realms windows 10 bedrock. As well as single player bedrock pc. 

Reminder: The bug tracker is not a discussion site. Comments are for reporting new information to the developers, not for conversations. You can use the Minecraft Discord or the Mojira Discord for that.

We don't normally depend on user reports to tell us whether a bug is fixed. We get that information mostly from the changelogs. User reports are unreliable, because a partial fix might help one person but not everybody or because their devices make a difference, so we typically ignore user reports saying the bug is fixed and may remove those comments. Especially when, as in this case, we already have a fix report from Mojang. This bug has not been fixed in the retail release, at least not for everybody, but it has been fixed in the Beta and we expect the fix to propagate into retail in 1.18.

Just a reminder/report that trident killers aren't the only affected entity.

I made an ender pearl metastasis chamber (at about y=65).  I did a quick fly away and back.  during that time, the ender pearl phased through the ground down to y = 14.  I know this because as soon as I was close enough to reload the area on my way back, the ender pearl began interacting with blocks again, and I was teleported from way up in the sky down into solid blocks at y = 14.

Unlike tridents, there is no simple "stick it in a chest when done" for this case.

@unknown: Please remember that this is not a discussion forum or customer feedback site. Comments are meant only for providing new information that might help the developers.

Also, this ticket is specifically about projectiles thrown by a player. There are other reports about players falling through the world into the void, under various circumstances. Please search for them if you wish to comment with new information about such issues.

Since the information in your comment wasn't relevant to this issue and the remainder of it belongs on the feedback site, I have removed your comment per our guidelines.

I have two farms (with trident killers) that I travel to and from ONLY via Nether portals, and all of the tridents at those farms have remained in place. The farms are far away from my base (hence the Nether portals), further than the render distance + 5 chunk distance mentioned in the "Steps to Reproduce" of this issue. I have had other, closer, tridents disappear.

If this information is unimportant and/or can already be assumed, mods please feel free to delete this comment!

Still a problem in 1.17.40 however render distance 24 doesn't seem to be affected.

Testing different render distances: https://youtu.be/DKIe5FHGy98

Testing Render Distance 24: https://youtu.be/RQwJLWXziRk

Reply from @unknown: in the render distance 32 test in your video, you don't move far enough away to trigger the bug. With render distance 32 and a trident at Z = 0, you would need to move past Z = 607.

In the render distance 24 test the first video, the trident does disappear.

The second video you linked does not show a test at all.
 

I have a possible work around that I wanted to share that avoids the need to collect and rethrow each trident every time. I have a mob farm with 16 trident killers and I noticed that some of them would lose the tridents repeatedly and others never did. The thing each group had in common was the orientation of the piston (each trident is hit repeatedly by a single piston in this design--I'll link an example video below).

For the 6 trident killers where the piston head extends to the north or west from the piston body, the trident in front of that piston never vanished. 4 were pointed west and 2 were pointed north. 

For the 10 trident killers where the piston head extends to the south or east from the piston body, the trident in front of that piston would sometimes vanish when I would leave the area or when relogging. 6 were pointed east and 4 were pointed south. 

The pattern emerged because I modified each module after the first time a trident disappeared to make it easier to replace, so I could see which tridents never disappeared. They were all build the same way except for the orientation, and all were used at the same time as they are part of one big farm. 

The trident killer I used is essentially the same as this one here: https://youtu.be/_S4zNY5TdH4 (TK build starts at about 10:30). This video is from YouTube user GoldenHelmet403.

There is a similar trident killer concept used in the guardian farm from SilentWhisperer here: https://youtu.be/cBhmlacCkMs (TK build starts after about 18:30).

Either above design lets you push the trident in only one direction, making this work around possible.

Edit: 1 player commented that they saw the same directionality in the Trident Killer affected by the bug in their world. The comment has been deleted but IMO the information is valuable to know whether the suggested work around is going to be helpful for others 

Workarounds are always welcome, because something that prevents the bug is almost always a good hint about what's making it happen. However, the bug tracker is not a discussion site and should not be used to discuss theories or share speculation. Please use other tools for that, such as the Community Support Discord or Mojira subreddit.

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

If we can't discuss theories and speculation in the structure of a bug tracker, how are we supposed to coordinate and validate our testing? The average Discord or Reddit thread is so chaotic this sort of targeted and topical discussion is basically impossible. This is the only forum for solid structured discourse regarding specific issues. On Discord and Reddit we're shouting into the wind and hoping to find each other, here, we're already here. Unless you'd rather these threads become filled with links to discussion threads off platform?

Reply from

@unknown
Sorry, but them's the rules. Of course, that's not a satisfying answer and you're being quite reasonable while asking for a justification, so let me try to do so this once.

The problem is that the devs' only source of information about the bug comes from these reports. That means they have to read them top to bottom, including comments because as often as not those have the best clues. As moderators, we need to ensure that the devs can do this as efficiently as possible, From past experience, we know that a leniently moderated report will become dominated by distracting, useless comments: "me too" comments, complaints about how long it's taking, questions that we can't answer, attempts to report similar or related problems that need to be in a report of their own, and suggestions and analysis from nontechnical people that, while well-meaning, are based on false beliefs. And those are just the general categories of useless comments, from the devs' viewpoint. Some widespread bugs have garnered hundreds of such comments. When a ticket becomes so overloaded with drivel, the devs simply can't waste the time it takes to trudge through it looking for clues. Our job as moderators is to prevent that, but we are even fewer than the devs and we're volunteers who don't really want to spend all our free time here. And while many of us are technical, some even former devs, we don't know the game's internals and often aren't qualified to pick out what's useful to the devs, so we have to leave questionable stuff alone. So it's important that on a ticket with many comments – that is, one that affects many people severely – we keep those comments focused and informative to the devs.

We often say this as "this is not a discussion site". Although it looks somewhat like one and was meant by the Jira authors to function as one, they anticipated an audience of developers, not nontechnical people who are ignorant of the development process and who therefore have no basis on which to judge what is relevant here. The Jira software is not ideal for the use Mojang has put it to, it was just the closest they could find at the time, and now they're pretty much committed to it. So it falls to us moderators to keep it adapted to the use Mojang has put it to, and keeping comments focused is how we do that.

On topic:

The issue at hand looks to be mathematical. For some reason tridents that aren't at whole number coordinates are being unloaded incorrectly, that is, not at all. Tridents that are located by pistons against the north or west edges of a block, can be inferred, and if my favorite Bedrock map editor was working currently, confirmed, to be exactly located at x.0000 coordinates. However, when thrown on to a block or otherwise piston located against the south or east edges of blocks, they will have full decimal coordinates. In the case of the south and east edges something like x.999999.

Auldrick your point is well taken. At the same time though, it seems likely that the devs would find it helpful to see whether other people do or don't observe the same direction-dependence. At this point I'd rate the work around as "probable but unconfirmed" because we don't have enough independent reports to rule out random chance 

Reply from

@unknown
--A limited number of confirmations of each others' test experiences is, of course, welcome. You need to understand, though, that there's only so much reliance the devs can put into reported user experiences. We all (including us Mojira staff) play a certain way, most of us on a single platform, and it's not likely that a couple, or even a dozen, of our experiences cover the gamut of the bug's consequences. To that you can add that generally speaking, our inferred models of how the game works internally are extremely likely to be oversimplifications of what is actually going on. We simply don't have the devs' broad perspective on the details of what the game does and why. So what the devs are looking for as they read through a report is just the core of a bug, which they then have to explore themselves on various platforms and with knowledge of why the code works the way it does. Our conclusions are only speculations that might give them something to include in their analysis, but they aren't typically conclusive to the devs, who will need to test across many more platforms before deciding how to characterize the error.--

On review and reflection, let me try to say that a better way: I don't think the devs are guided as much by our experimental results and confirmations of them as we might expect, though that doesn't mean they're not wanted. I think the devs evaluate our reported experiences in light of their greater breadth of understanding of the game's internal logic, and when they find that something we suggest is plausible, they proceed to test it themselves, whether or not it has confirmations from other users. But they can really only draw conclusions from their own testing, so our confirmations only contribute a little to their plausibility assessment.

That's fair. I suppose this whole tangent will have to be deleted, which is too bad since it's been an illuminating conversation for me and probably the few people who are following this thread.

They really should give the mods some better tools to allow some community discussion without being a distraction for the devs. I feel like a similar problem has already been solved by Wikipedia when they added discussion pages behind each article. It'd be great if something like that was possible here, then the mods could move the chat instead of deleting it. 

My experience puts a damper on Mr. K's comment. I have one trident killer that has lost three tridents. The first two were thrown directly into the center of the kill chamber (4x4). The third trident was thrown into a north facing piston. Every one of these three tridents disappeared on me. I won't sacrifice any others until this gets resolved.

It is important that we keep issues distinct.

1. Projectiles launched by a player fall into the void (appearing to despawn) when all players move far away.

2. Tridents stuck into the side of blocks dislodge and fall when reloaded.

   [media]

3. Tridents in a "head" trident killer fall out of place when reloaded.

   [media]

Issue 1

This is the subject of this report. It occurs because player-launched projectiles, once loaded into ticking range (simulation distance), continue to be ticked even when outside of ticking range and beyond the distance where the game loads block data (render distance + 5 chunks). Due to the nature of this bug, it only occurs with travel in the same dimension as the projectiles. It does not affect projectiles when exiting and reloading the world or traveling to the nether and back.

Tridents falling into the void can be worked around by using

, but to use it you will need to pick up all tridents before applying the pack and then re-throw them after applying the pack. After that you do not need to pick them up again and they will not fall into the void.

Issue 2

This occurs when reloading a trident, either by (a) exiting and reloading the world or (b) traveling to a different dimension through a portal close enough to the trident not to trigger (1) and also not within about 100 blocks of a player spawn point, and then coming back to the original dimension and coming within ticking range of the trident. It does not depend on which face of a block the trident is stuck in. It is plausibly caused by the same changes to trident ticking as issue (1), i.e. ticking the player-thrown projectile almost as if it were a player. There is currently no workaround for this.

Issue 3

This occurs with tridents being pushed into the north or west sides of blocks (i.e. pushed toward the east or south), when the trident is reloaded (by exiting and reloading the world or travelling to another dimension and back), after the trident has been previously reloaded while the piston happened to be fully extended. In this scenario, the reload with piston extended puts the trident into a state where it offset inside the block it is being pushed into but the trident killer still functions:

This offset occurred in earlier versions, but it would reset it self when reloading the trident while the piston was not extended. What is new since 1.17.30 is that the next reload always causes the trident to fall, whether the piston is extended or not. This is also plausibly caused by the same change to projectile ticking as the above issues. It can be worked around by using a different kind of trident killer or installing on/off switches and making sure to turn off the pistons before leaving the area.

 Haven't noticed chunk distance being an issue for me as much as loading in (as for my my despawn problems) single player world off realms.

Replaced all the tridents in the trident killers on the realm after the update, they are now gone again.

Reply from @unknown: that may be due to MCPE-144208.

About half my guardian farm tridents disappeared yesterday (1.18+). This is definitely not fixed.

Issue #3 still occurs (1.18.2 world on Nintendo Switch).  Does that aspect of the bug have its own report?