Dead Gye

Experienced this again today on pre-release-2. This time I logged out and logged back in between throwing the first pearl and the second pearl. Was met with the same situation of seeing an ender pearl fly and hit a wall, teleporting me, after the second pearl sends me through the portal.

I'm suspicious that the angle I'm throwing the pearl at might be playing a part. Typically I end up aiming such that if it went through the portal it would hit the bedrock on the lower side that is farthest from me, and the pearl almost clips the bedrock on the upper side that is closest to me. And then deviate from the baseline randomly.

The killed_by_player condition is never met/applied when killing mobs while in creative mode.

I can confirm this behavior isn't present in 20w19a, so the relation to the fix is highly probable.

The bug isn't that you can't break blocks while lying down. You can break the blocks one y level above where you are trying to break, for example. The real problem is either that you can attempt to break that block at all, or that what a player can actually reach isn't changed by lying down.

If you stand up you'll find that you can't even reach that far down to attempt breaking that block. Meanwhile, if you dig directly up while lying down (align yourself with nearby block to make sure you don't stand up) you'll find that you can dig up as high as you can when you're standing up.

I believe the issue is that the killed_by_player condition is not being applied/met when killing an entity in creative mode. With 1.16.pre2 I used a data pack to add two drop items to a mob, both with 100% chance but the second item has a killed_by_player condition. Spawned the mob from an egg twice. Killed the first mob with a sword while in creative mode, then switched to survival mode and killed the second one. They both dropped the first item, but only the second mob, killed while in survival mode, dropped the second item with the killed_by_player condition.

Unlike resource packs, data packs are per world and their final location is the .minecraft/saves/worldname/datapacks directory. The dilemma is that the default location cannot be that directory because it has not been created yet, because the world name is not finalized yet.

Even if the default location was changed to be .minecraft/datapacks, there would not be much benefit over the TEMP folder as the data packs will still be moved out from there upon world creation. "Available" and "Selected" is a bit of a misnomer, it's better to think of them as "disabled" and "enabled". It is desirable that adding data packs during world creation does not cause those data packs to be added to all subsequently created worlds by default; Which is why the data packs would be moved, not copied.

Personally, I would prefer the Data Packs screen to have 3 areas with 3 buttons, instead of 2. The leftmost area would be the data packs repository, which defaults to .minecraft/datapacks and has a button that opens up said directory. The middle would be the 'Disabled' data packs with a 'Open New World Pack Folder' button that opens the TEMP directory. And the rightmost area would be the 'Enabled' data packs with the 'Done' button. Moving packs between the 3 areas would graphically be the same, but data packs would never actually be removed from the repository directory (.minecraft/datapacks).

I have experienced this problem on 20w19a as well. I threw an ender pearl into a return gateway and did not get teleported. I waited for somewhere between 60 and 120 seconds, while continuing to move closely around the gateway in circles. The server was not under any stress. After those 1~2 minutes I decided to throw another ender pearl into the return gateway, whereupon I was immediately teleported back to the main island–however one of the ender pearls was there, mid-flight, as well. It quickly landed before I could get my bearings and teleported me to where it landed like a normally thrown ender pearl does.