Can place/take water/lava/lily pads outside world border and inside spawn protection

Confirmed.

Confirmed.

Confirmed 14w18b, also it seems that the water you take is ghost water, and the hole that you leave is a ghost-hole.

Proof: Take water from beyond worldborder. you get an unmoving hole in the water visibly apparent, and a visibly apparent bucket-full-of-water.

Try emptying your bucket back into the hole. Empty bucket, hole back to normal and full of water.

Try emptying your bucket anywhere else, outside or even inside the world border. Empty bucket, but no water.

Try restarting your world, or reconnecting in SMP. Hole you left vanishes, bucket-full-of-water you were holding (if holding one) is now empty.

Try having third party walk up to you and inspect the hole you left, or what you are holding in your hand. They will report no hole, empty bucket.

Thus, client side engine thinks you are taking water but server never allows that transaction to succeed. Client only continue to show you an illusion of water in a bucket or hole in the water until it's memory on that matter are cleared and brought back to jesus.

Confirmed for 14w18b

Good analysis, @unknown!

Really good analysis, Happ!

Confirmed for 14w19a.

Confirmed for 14w20b.

Confirmed for 14w21b.

Is this still in 31a?

Confirmed 14w31a. Still matches my previous analysis, with one exception.

Now if you try to empty your ghostbucket full of water into a new spot (such as onto the land) outside the worldborder, it no longer behaves the same as when you place it inside (empty bucket, no effect on world). Instead, your bucket is emptied and you get a ghost water surplus in the one outside block that you targeted.

Also, things get fun if you take or place ghostwater, and then extend the world border so that you can access the mess you made. Because the server sees no block updates with the worldborder growth, it never corrects the client and you can go swimming about in ghostwater blocks that don't flow or else walk on the bottom of a lake through a ghostwater hole. At least, until you begin taking damage for no apparent reason ~10 seconds later once the server reckons you must be drowning. xD

Confirmed 14w33a

Confirmed 14w33c

14w34b

confirmed pre3

confirmed 1.8.1-pre3

confirmed 1.8.2-pre1

Also, I notice in the "environment" tab it mentions Windows 8? I am confirming this bug on (probably jre-7) 64 bit java on Windows 7, and since it appears to be a direct bug in game logic I doubt it will be any different on any other environment for the PC version of the game. :J

Happy Horlidays gais!

MC-54119 confirmed 15w31a

confirmed 15w33c

confirmed 15w39b

confirmed for 15w39c

confirmed 15w40b

confirmed 15w43c
(say, is there a way I could be set to just update version on this one mahself? :3)

@unknown, I've made you the reporter on this issue, since the original reporter no longer seems to be active on the tracker. This will allow you to change most of the fields, including the affected versions.

Does it affect 15w47c ? I'm typing this on a mobile device so I can't tell.

Yes it does, 15w47c confirmed.

While 1.9.1-pre3 is confirmed, the actual behavior has become a bit more complicated than it was in 1.9.1-pre2 and before.

it used to be, you use your bucket out of the border (to scoop up water or to place it) and on client side the water scoops or places (but doesn't flow) and your bucket looks as though it has scooped or placed. Then trying to use the bucket within the world border causes it to look as though you are scooping or placing for just a fraction of a second before the server over-rides client's view of the updated block(s) in the normal world (within border) and the bucket in your hand. EG: try to dump ghostwater onto land, you see the ghostwater on the land for a brief period before it vanishes and your bucket is left, now correctly, empty.

New behavior is: the first time or two you try to interact with world outside of border, client is corrected by server. But when you try again and again there is an increasing chance the client will get back out of sync and demonstrate the bug again (ghostwater or ghostempty bucket, with hole in water or standing water outside world border again). And THEN, sometimes trying to update bucket in real world takes a try or two as well! It's rather weird. xD

But it is not the desired behavior, which is A> Any time client gets incorrect world state server always and exactly corrects it, and B> client should agree on every gamerule with server (such as: no, you cannot f@#$ with things beyond the worldborder, Timmy!) reducing or eliminating any known cause of client getting incorrect worlds state to begin with.

As of 1.9.2, the slight complications mentioned regarding 1.9.1-pre3 appear to have lapsed back to older bug behavior again. That, or what I observed with 1.9.1-pre3 may have been a strange issue of IPC lag between client and server SSP. I don't view the distinction as important enough to justify loading up 1.9.1-pre3 again to clarify, unless somebody working on the code thinks that would be worth a look? :3

Please link to this comment in the description

The following is based on a decompiled version of Minecraft 1.9 using MCP 9.24 beta.

The reason for this is that the method net.minecraft.world.World.isBlockModifiable(EntityPlayer, BlockPos) which is called to test if the player can modify the block returns always true for the client. For the server the overridden method net.minecraft.world.WorldServer.isBlockModifiable(EntityPlayer, BlockPos) tests if the block is not inside the spawn protection and inside the world border. As the client knows at least the worldborder information, the parent method probably should contain this code instead of only the server method.

This affects blocks inside the spawn protection and glass bottles as well

Thank you for that inspection, Marcono. I have added a link to your comment into the description as you've requested.
Does anybody know if comments or descriptions in mojira support BBcode or similar, so that I can label links instead of just spilling out complex looking URLs? ;3

@unknown, look into local help about markup (you can also get it by clicking on a "?" in a circle)

Thank you Suncat. :3

Do you happen to know if waving my arms about in the comments will help bring attention to ancient bugs which ought to be either easy to fix, or like this one good canaries for solid client/server synchronization in general? 😃

@unknown you shouldn't, bumping is not appreciated.

Does it bump when I test a half a dozen listed issues on each snapshot release and add results to the listed versions field too? Because after a hundred snapshots or so it starts to feel like so many forms filed into a round bin.

The activity feed lists affected version changes/additions and new comments just the same, only comment edits are omitted(❓ ). Both actions also affect the last update field of the ticket. I don't know if there are native ways to filter the activity feed.

OK, IIUC that means that comment + updating affected list emits two emails instead of one (which might be what FVbico was concerned about) but to people only paying attention to ordering tickets by most-recently-updated there won't be any appreciable difference.

I guess what I'm really after is insight into what the coders view as priority. I've been reporter for 6 (real, non-duplicate) issues. One was next to impossible to reproduce and only happened on one in a zillion computers but got resolved in two snapshots. The other 5 are globally reproducible, easy to reproduce and at least as annoying to experience as the one that got fixed yet go unresolved for years. 😞

Bugs are not all equally easy to fix. Some are just a single edit on a single line, other require ripping out and replacing code spread across the entire codebase. And the impact of the bug isn't necessarily proportional to the amount of effort required to fix it. Sometimes something that looks simple leads to a cascade of changes that risk breaking other things, and so that change gets put off until they're ready to tackle the consequences of it. Basically, they can only fit so many major changes into a release, they usually decide which part of the code they want to tackle, and then look for issues related to it. Sometimes they take a sweep through open, currently updated issues and look for things they can fit into their schedule. They've just got so many things that they already know they need to do.

@Torabi
> Bugs are not all equally easy to fix. Some are just a single edit on a single line, other require ripping out and replacing code spread across the entire codebase.

Perhaps so, but this bug we are chatting in is a single-line fix, according to @Marcono1234 who has done a decompile and described the problem in this comment.

As of 18w19b I can confirm that bug is at least more difficult to trigger. Not every right click of bucket will scoop up a liquid, though spam clicking or clicking at just the right angle facing a liquid can still do it. And I have not yet successfully been able to dump a liquid past world boundary.

So from a user-facing perspective (custom survival maps that use a tight worldborder) I would rate this bug as "much less annoying" now at least. 🙂

18w22a, While it is more difficult to dump a liquid past world border than it is to scoop it up, I have now confirmed that it can still be done when you try enough.

Plus a very curious side effect, when you make your bucket false-empty in this fashion, you can now use the false-empty bucket to scoop up liquid on the inside of the world border and create a new kind of "dead air".

Previously, if you scooped liquid inside the world border with false-bucket, client would render the liquid as scooped for only about one tick before server rejects client's interpretation and liquid re-appears.

Previously you could also scoop liquid outside of the world border, there would be no block update, and if you expanded the world border you could go into the standing hole in the liquid. It would act as a sort of "dead air", the client thinks there's no liquid there while the server does, client allows you to swim only where it thinks the liquid is, no bubble meter comes up when you submerse your head in the dead air, but after a time you do start to lose health as the server thinks there is liquid there.

Now, with dead air (which can now be created without having to first move the world border outwards) the new effect is that the bubble meter DOES appear, even though client still does not allow you to swim through the dead air.

All interesting stuff, but understandably all much harder to reach now that something blocks picking past the worldborder on ~97% of attempts.

Confirmed for 1.13.1.

relates to MC-167374

Affects 1.16.1 and 20w29a

Can confirm in 20w48a.

Can confirm in 21w03a.

Can confirm in 21w05b.

Can confirm in 21w06a.

Can confirm in 21w07a.

Video attached.

Can confirm in 21w11a.

Can confirm in 21w14a.

Can confirm in 1.17 Release Candidate 2.

I'm still able to reproduce this issue in 1.18 Pre-release 1 and 1.18 Pre-release 5, so I'm requesting for this ticket to be reopened.

Can confirm this in 1.18.

I was told to create a new ticket regarding this issue so I've gone ahead and done so. The new report is MC-245845. 🙂