Daniel Burnett

@beebee "Artificial" creakings (a) take damage, (b) don't process any connected hearts, and (c) don't despawn during the day. My guess is that the sum total of these differences made them easier to implement as separate entities.

@clamlol I would assume it's because creaking spawned with commands or spawn eggs aren't invulnerable, don't have a connected heart to process, and don't despawn during the day. Those distinctions were probably easier to implement as two separate entities, and "creaking" was the ID given to the player-exposed one for intuition's sake.

Can confirm the issue as Leo Xiang described above, where a precision issue is causing the wrong amount of damage to be applied when using set_damage. That also breaks future relative-mode set_damage calls from working at all.

My test where I encountered it:

1. Gave myself an item with the max_damage component and damage component both set to 100: 

/give @s minecraft:clock[minecraft:max_damage=100,minecraft:damage=100,minecraft:max_stack_size=1]

2. Set up two repeating command blocks, requiring redstone, with similar commands to add and remove 0.01 damage – which should be 1 damage per tick: 

item modify entity @p hotbar.0 {function: "set_damage", damage: 0.01, add: true}

item modify entity @p hotbar.0 {function: "set_damage", damage: -0.01, add: true}

3. Use a stone button for repeated 1-second runs of each. It works at first, going from 100 damage to 80, then 60... but then the precision error happens and it drops to 39 instead of 40. After that point, the command to subtract damage no longer works on it.

Seems like a precision error to me, but it breaks the intended use cases of that item modifier function, and should be fixed.

Perhaps this is a different issue than the original ticket, and a separate ticket should be opened? If it's the same issue, then this one should be re-opened.

Confirmed. I was coming on to report this very bug when I found it has already been reported 🙂 I attached a screenshot; the "spy" score is minecraft.used:minecraft.spyglass, and you can see I'm clearly using the spyglass, but the score remains at 0.

Can confirm it's back in 20w10a, and so this ticket should probably be re-opened. (It was also confirmed in a YouTuber's snapshot review video... I can't remember if it was Xisuma, Cubfan, or someone else, but I'd take that to mean thousands of people can confirm this bug now 😃 )

@Mikeware it's still client/server desync. In single-player worlds, there's still a server, it's just an integrated server. But it handles all the same things a dedicated server would.

@Mikeware I've only tried on a single-player, normal terrain world, but my computer isn't great and lag is common. I can only imagine it's worse for people with even worse computers than I have. I've been able to mitigate the effect a little by surrounding the honey block with slime blocks, as they tend to push the player or mob back into place when there's lag, though it's not 100% effective and obviously is just a cumbersome workaround.

Not that I know of. I was just able to actually reproduce it in my own inventory after trading with a villager for a bit; all the items in my inventory became ghost items that just disappeared when I tried to take them out. During trading, shift+clicking the results out of the inventory also lead to my input stack (emeralds) only losing a few items, but then reverting to the correct (lower) amount after clicking it. When this happened, the shift+clicked results wouldn't show in my inventory until I clicked something, either, and then they suddenly appeared.

I'll try creating a fresh world to see if maybe I do have some commands running I've forgotten about.

EDIT Well, in a fresh world, the problem disappears. Maybe I do have a command somewhere that I've long since forgotten about... well, there goes my testing world 😞 Anyway, I guess this can be marked invalid, then.

I agree the crouching changing your hitbox is a welcome change and probably intentional, but the way the model stands up if you let go of the button while under a slab, thus getting your head rendered inside the slab even though your hitbox and first-person view remains crouched, is definitely a bug.

There's a more specific bit of code at the root of this bug. (Basing this off the source of 1.12.2.) When writing an arrow entity to NBT (i.e. on save or when modifying the data), it only writes the color tag if its fixedColor property is true. This property is only set in the setFixedColor and refreshColor methods, the latter of which sets the color to the default blue. This means that for normal arrows, it's false by default, and will never be written to NBT data; so when it reloads, the color tag isn't there, and it's refreshed to blue.

The fix to this is quite simple, and requires only two small changes. In the tipped arrow entity's setPotionEffect method, instead of setting the color directly on the data manager, it should call setFixedColor to do this, which will then set the boolean flag properly and allow -1 to be written with the arrow's NBT, fixing the issue for bow-fired arrows.

The second change is to fix the issue for dispenser-fired arrows. In the registerDispenserBehaviors method of the Bootstrap class, when it registers the arrow behaviors for normal arrows, it just needs to call entitytippedarrow.setFixedColor(-1) somewhere between creating the entity and returning it. (The method is currently private, as is the flag, so this would need to actually call a new setter or just make the setFixedColor method public.)

Those small changes should fix this long-standing bug for good 🙂

Comments here seem focused on entities shooting arrows, but I have this issue even with player-fired arrows (from unenchanted bows, too). It seems all arrows are treating air like a solid block.

I can confirm this in the latest snapshot, 18w46a. I thought it was just a new bug, until I found this ticket. It's definitely annoying when working with setblock/fill.

@Urielsalis Nope, it's turned on.

This is not the same as MC-139000. That one is about items rendering incorrectly. This ticket is about entire chunks of the screen – sometimes held items, sometimes hotbar slots, and sometimes terrain – completely flickering, i.e. failing to render at all for a frame or two.

Oh! This was a bug! I was so confused XD I don't work with model overrides often, but I started making a data pack / resource pack combo in pre-3, and I quickly noticed that it was backwards. I thought I was misunderstanding or remembering something about overrides wrong >_< Glad it's fixed in pre-4, but now I have to re-do all my overridden models :|

Most likely caused by 1.12.2 using numerical enchantment IDs, while 1.13 replaced them with string identifiers. 1.13 doesn't understand what "enchantment ID 3" is anymore, it only understands things like "enchantment ID 'minecraft:blast_protection'" instead.

A fixer/walker needs to be added to convert these IDs in 1.13 for worlds coming from previous versions.

Even worse, if you have an actual night vision potion effect active in a dark cave, and you step in water, everything goes dark for a second while the water-vision system kicks in. Which is super annoying since natural water pockets exist in caves.

I think the solution for at least some of these issues is to implement the following checks before triggering the water-vision rendering:

1. Check for water at player's eye level rather than their position.
2. Check that the player doesn't already have a night vision status effect.

Those are the most important and most easily fixed issues. As for figuring out what the brightest light level should be, that's quite a bit more complicated, but perhaps lighting updates could somehow be calculated in a second pass, ignoring water's attenuation, and those values used for the maximum brightness underwater? I know that sounds like it'd be super inefficient, but it's just an idea off the top of my head.

A quick test shows that it works fine in 18w07c, at least with a chain of command blocks. I can't test how it performs with functions until tomorrow, though I can't see why one would work without the other also working (since command chains occur in 1 tick as well).

If you use /setblock to place a bubble column manually over a normal block (rather than magma or soul sand), then push a piston into it, you'll find that it does in fact get pushed by pistons (and then becomes water due to block updates and noticing there's no magma below it). This makes it very clear to see what's happening.

@Steven Hanff You could have just used /kill @e[type=trident] to kill only the trident. Still, this is a bug that shouldn't happen.