Boat location desync

I can confirm that boats still break from lily pads in 1.4.5. It can happen at any speed and water depth. I've made a video in which I reproduce the bug at various speeds and angles in both shallow and deep water. http://www.youtube.com/watch?v=u4uai1h3usc
I can also confirm the desync bug in 1.4.5. I've made a video for that as well, it shows the issue quite clear. http://www.youtube.com/watch?v=zOm_iUSscBA

Boat constantly smashes apart on lily pads in a swamp in 1.4.6. Seems to occur when catching lily pads by the corner of the boat.

Soooo annoying (lily pads breaking boats). I confirm in 1.4.7 Voted.

Lily pads still break boats in snapshot 13w16b. It even seems worse now.

Happens for me in usual swamp biomes as well, no need for a custom creative world to reproduce. Just go to a swamp biome, get in a boat and hit a few lily pads.

Still in 13w24a

Still an issue in 1.6.1

In 1.6.2, I was not even near lily pads. My boat has broken under me 3 or 4 times the past few days, and only once did I find the materials, they were 10 - 15 meters away next to the coastline. I think they computer is showing the boat in a different location than I am and breaking against shoreline when I am well away from the shore. This doesn't seem to be the lily pad issue, but several complaints of boats breaking for no reason have been redirected here, so I put it here. You may have two separate issues.

Still at 1.6.2.
I was popped out from the boat with distance of 30~50 blocks to my last location in the boat, without crushing into nothing (at least, from my client-side's view).
There seems to exist a serious location de-sync bug when riding boats.

I'm on a older (slow) computer.
AMD Athlon 64+ 3400 (2.2 Ghz single core)
AMD Radeon HD3300
1 GB RAM
WinXP
Runs minecraft at on average 20-30 fps.

However, whenever I get on a boat... I need to move REALLY slow, to avoid this issue. If I use a boat normally (speeding) it just vanishes from under me after a while, even at full ocean. I first thought it was lag + me crashing into a squid. But it even happened without any (visible) squid or block near.

Because my PC is slow, this happened EVERY time I got on a boat since 1.6, I can't say which version I last used boats though, but it wasn't an issue before.

This is a rather severe bug. Although I like having my boats intact, I'm okay with my boat breaking if I crash it into something. I'm not okay with the desync, which rapidly makes it impossible to tell where the boat is with any precision.

When I tried boats again after some inactivity (now in 1.6.2), they kept breaking randomly every few minutes on average, but sometimes after just seconds (a narrow canal does that to you). Moving slowly, it's clear the boat is bumping into things that are offset from where Minecraft renders you.

It's even more fun combined with MC-881, because it may not break the boat but will kill you, also in what looks like empty waters.

As far as the boats breaking, they collide with items. You can test it by setting up a dispenser on a clock a few blocks above some water, filling your inventory, and boating through it in survival.
I would imagine that in some cases the boat manages to hit the lilly pad item before it gets a chance to be picked up or fall far enough to avoid the boat.

I assume that it's the lag thing, but normally when I have trouble with lag, (landscape not rendering faster than I can get to it, for instance) I pause the game for a bit and wait for it to catch up. Once the server is caught up, it should have the boat in the corrected place, but does not. I know it's lag because the launcher development console says, "Client> 2013-08-04 18:47:11 [SERVER] [WARNING] Can't keep up! Did the system time change, or is the server overloaded?". Somewhere in there when it's caught back up again, it needs to put the boat in the correct place.

As a work around for those who have this problem, if you hold a stack of something you don't mind wasting (cobblestone? zombie flesh?) and throw it (Q) you will see it coming from where your boat actually is. Just keep that 'ghost boat' from hitting anything. It's not a great solution, but it's helpful.

What would help with both this issue and the "can't pick up item" issue would be a re-sync trigger. Various things get off between the client and server (drops end up in different places between the client and server and so you go to pick up the drop and it's not there) but if you could hit a function key that would re-sync the client to the server it could fix any issue that ensues. You might have to pause the game briefly - in fact, you could make a re-sync occur automatically when paused to prevent problems before the user notices them.

Currently, when my boat gets near land, I exit the game and re-enter. This puts me back where the boat actually is, but takes too long.

Affects 13w36a, but only slightly. I've gone for several minutes and been off by only a meter - this is much better. Whatever you've done, good work.

I don't want a re-sync trigger. I just want it to work correctly. Everything should be synced in a way that doesn't cause drift. I think quantized network coordinates might be responsible for entities that fall or shoot away for no apparent reason.

So far I've had my most extreme desyncs while pulling hordes of animals behind my boat. Even while crossing a small strait I managed to leave the loaded area client-side (with view-distance=15), giving me a new perspective of the void. Oh, and don't call PETA.

This bug becomes especially annoying when mapping. Mapping much faster to do from a boat, and with the multiple stops, starts, turns and close (cautious) land approaches, the desync between player and server seems to become quite large.

The desync seems to be due to speed and direction changes, not keeping inline. Having the server report the players real location (in boat, horse or otherwise) more often may resolve the issues.

The idea of a resync button, that not only re-loads your location from from server, but also reports yoru correct position to other clients, would be very useful. We have many other F3 re-sync functions are available and either attching this to one of those or as a extra key would be useful. Especially while the nether portal de-sync is present, or any other de-sync situations that may turn up in the future.

Been having the boat de-sync issue a lot that I actually want it fixed in time for 1.7 so we can all go exploring happily. Insanely annoying when you follow the edge of a land-based biome or out in the middle of nowhere in the ocean/lake that your boat just implodes/explodes, or whatever it does. Because of such I've stayed on land avoiding any form of water travel.

As the comments say, a re-sync button or script that runs every minute or so to place you correctly on the exact water block would be helpful.

I just ran into the positional de-sync today when I went to explore the edge of the landmass I started on. Three times now my boat has broken up because the server believes me to be in one position while the client shows me I am in another. I have also had the issue where I got out of the boat (into the water near some cobblestone I had built earlier) and the boat stopped being an interactive entity. Logging off my SMP server and back in fixed this. However, logging off while de-synced and in a boat caused another boat to just disappear (and for me to spawn on stuck in the ground underwater in the last position I was in while in the boat when I logged back in).

From my perspective, it appears the server is moving the boat faster than the client shows, and the faster you move the boat, the more out of sync the client-server gets. The worst example for me was moving about 500 blocks in a straight line, then turning slightly to stay well clear of an approaching island, only to have the boat get destroyed while I was still 10+ blocks away from the closest bit of shallow (1 block deep) water, let alone the island itself.

I did find one nice way of knowing where the server thinks you are while you are in a boat.

I started mapping using not just boats but a donkey (for extra storage). If you lead your donkey/mule/horse before getting in the boat, the animal will swim with you on the lead, just behind your REAL location. You can still travel just as fast as normal (which can look really funny) but the animal will track you real location, according to the server.

You can now navigate around islands and land by looking at the location of your animal, even if that animal is a LONG way away due to de-sync. Quite often I find myself boating behind my donkey, because the server thinks I am ahead of myself.

It is a good way of experimenting to see exactly what situations cause de-sync, expectantly with speed. Something you can not easily do using lily pads.

I do not think it is just speed, that causes de-sync, It also seems to be direction and acceleration dependant.

Yeah, I discovered you can do this by placing lily pads and watching the client place one where you appear to be (that doesn't actually exist if you get things resynced) and the server place that same lilypad where it thinks you are located. Using an animal on a lead would be much easier to track, however.

I have to revise my earlier guess that the server was moving faster than the client. After another few hours of being not really lost (I didn't know where I was, but I knew how I got there) while boating along the coastline, I noticed that the client moves faster than the server as far as your boat position is concerned. Reading the Minecraft Wiki on boats, I noticed that there was an update where boats were sped up. This makes me wonder if the server side code didn't get the exact same tweak. That or the two have some kind of rounding issue where the client rounds less than the server does.

Bug still present in 1.7 pre-release, swamps are almost impossible to navigate without breaking and lilypads placed in a row are a boat destroyer.

The boat breaking is still present in 1.7.1 pre-release. The easiest way to test this is by creating a superflat world with this preset: 2;1,20x9,111;1;village
There you can only travel a couple of meters in a boat before it breaks.

I'm still seeing this in 1.7.2.

Another rather disturbing thing that I think is related is that if I get far enough out of sync, I can actually sail "off the edge of the world" into an unrendered chunk, and look back to see the edge of the world down to bedrock.

Also, sometimes when my boat is de-synced, it will "stick" as if it's dragging on the bottom, even though it looks like I'm in deep water.

My elaborate system of canals, some of them underground, is now just about useless.

The MindCracker BdoubleO100 has a recent video (Mindcrack Epsiode 57) where he was experiencing this bug in a sever way. That is jumping out of the boat and appearing a long way off shore.

Boat desync still occurs in 1.7.2 and is a huge pain. Exploring oceans by boat is only reliable if you take 3-5 boats with you and always have one in your inventory hot bar. If you sail past an island and the server copy runs aground, and your boat breaks, your local self drops into deep water. Opening the inventory to get another boat overrides jump/swim so you sink.

Sailing rivers or canals on multipplayer servers is now almost impossible.

While I recognise that client-server synchronisation is a tough coding nut to crack, it's not impossible. Come on Mojang, get a grip. We pay for this game so terrible issues like this are not tolerable. If you need help, get in touch.

As it's not only a problem with lilipads, the report was renamed.

I'm having this issue in survival 1.7.4; If I'm looking at a map I can see that where I am server side is clearly different to my client side location.

I too can confirm this occuring in 1.7.4. Was exploring new territories and about 20-30 blocks before land, the boat broke.

It is terrible for me. Boats have been literally unusable for me since 1.7.1. Once I floated off the edge of the world - there was no chunk there, only waterfalls into the void. All the other time I try to ride a boat I can get a few chunks away and then suddenly snap back to where I started (or close to it) and the boat breaks. I can only enter, ride, and exit a boat successfully if I stay within a couple chunks of where I start. Playing on a server in vanilla 1.7.4.

This bug appears to be fixed in the 14w02c snapshot.

Before creating what may be another duplicate: In 1.7.4 almost every time I exit the boat I land about 20 blocks away from the boat. Is that what was fixed in 14w02c?

@CaptainStarbuck : No, see MC-44909

Desync still observed in 14w04b.

I can confirm it is still occurring as of 14w06b. It's not a server issue, it's happening in local games for me, too. The workaround I've found is to quit the game and reload when I start getting close to land. That reloading re-syncs your visual position with the boat's collision box.

That's very interesting, Bob. I was convinced it was a client-server mismatch in position, which could be a fundamental limitation of the client-server messaging structure, and therefore hard to fix. But that can't be if it's happening in local games. So, it seems like a bug to be fixed rather than a a structural limitation, and we need to get Mojang to kick it up the priority list. For me it's a critical failing whenever adventuring afield in oceanic worlds, but they don't even have anyone assigned to look at or fix this issue. 😞

I've voted for this issue to be fixed, have all of you? Please do if it annoys you too.

Local games have been client-server as well, in versions 1.3 and up. This is definitely a bug in that department, among many others. You'd think they'd have it figured out after a year or two.

Why are boats special? Other entities do mess up on a regular basis. But those don't usually suffer from a total lack of syncing.

I am observing this in 14w06b (actually have been observing this since the 1.8 snapshots been coming out). Here are my observations:

Placing boats is almost impossible. I can't seem to place a boat into the water, even despite saving/reloading the client to force a location re-synch with the client/server. I would find myself downgrading to 14w05b to place the boat(s), then reloading to 14w06b to use them.

Movement in a boat is not in-synch between the client/server. Not sure what is causing this, but I have noticed that my perspective could be either "in front" or "in back of" the actual location of the boat from server-side, and usually results in crashing with coastlines and other entities unexpectedly.

Boats seem to be more prone to breaking than in previous versions. Causes me to always pack extra boats on even small trips and almost always lose all of them by the time I reach my destination(s). I would suggest to make them a little more resilient (iron/diamond boats?? Durability?)

Thanks.

When there is boats desync, blocks breaking/destroying works glitchy..

I was also unable to place boats in 14w06b. In 14w07a boats mostly work ok but there are still a few glitches. The worst is that often my boat will break when I get out of it, even if there is nothing else around and the boat isn't moving. Also squids can break a boat even if the boat isn't moving, but maybe it's supposed to work that way. The good news is that I think the de-sync issue is fixed.

I am still observing desynchronization with boats in 14w07a, though to some lesser degree than in earlier snapshots. I can't put my finger on it yet, but I think it has to do with PC performance in part; the time it takes the pseudo-server to render new chunks and save that data for the client to render may not be counted by the client while doing vector calculations with the boat entity. It's possible that the server isn't sending the boat's coordinate/vector information as often as it should to the client (if at all), and the client is still calculating while the server is on "hold" with map generation, hence the desynch.

Why I say this is I notice a lot less of this problem in areas where I've already been for some time (by my base or other location where all chunk data is already generated/loaded), and experience it a lot more in areas I'm exploring for the first time.

Hope this helps.

Yes I think the number one issue that leads to desync is chunk loading. Happens a lot in SP, but in MP, I simply don't bother boating ANYWHERE near land (I only get in a boat in MP to cross oceans), because I'm almost guaranteed to crash while my client says I'm far from shore. River boating? Literally impossible in MP.

I don't know why boats cause such desync issues. I just pulled up to a weird house standing in the water on my boat, reached up and broke a block of the porch and the fence on top of that so I can place ladders to climb up. Each time I tried to place the ladder where the wood block had been, it changed back into a wood block. I finally got out of the boat and found I was several blocks away from the wood. The boat appears to drift off in one direction and when I swam over to it and tried to board, I could not. I quit and reloaded the game to find that the boat had in fact drifted off in the other direction.

Confirmed in 14w18a, also noticed an odd case of falling through the block below if the boat breaks. Demonstration in video - http://youtu.be/XHBC40P9k0U

Still a problem in 14w18b, SMP. Less of a problem when the server isn't busy, but still present.

I have the same kind of problems in SMP (14w19):

• sometimes player location change when you leave the boat

• sometimes, when the new chunk generation is complex and may be late, the boat falls into void while the chunk is not generated.

• sometimes, when you quit playing while in the boat, the boat breaks when you load back.

• sometimes when you quit the boat, it become solid : it's still visible and immobile, you can stand on it, but you can't get in or move it.

I am experimenting with moving boats via water streams (EATS road) and have noticed a few things about this issue. Note that a lot of this may vary a bit in normal boating as these tests were all when dealing with moving water streams and not still water blocks.

• The desyncing only seems to happen when a player interacts with the boat

• It does not seem to happen if there is no player in the boat, but if a player jumps into a boat that has been moving in water streams it will desync immediately and severely, even if the player is only in the boat for a split second.

• The desyncing itself does not seem to be related to loading/unloading chunks, though the additional lag may contribute to it

  • It can happen even when the boat never leaves a small area and no chunks are being loaded/unloaded

  • If there is no player in the boat and the chunks are reloaded (Fully reloaded, A + F3 will not work) the boat will go back to its real position and move as expected. There is one situation in which this is not the case and that is if the boat loads in a water stream that is pushing it to a block which it cannot pass, in which case it will start ghosting past the block and snapping back to its original position

  • If there is a player in the boat when the chunks are reloaded (relogging) the boat will start where it is supposed to and then desync immediately and very noticeably

The coordinates for both the player and the boat are technically done correctly somewhere down the line, they just seem to be thrown off on the way to being drawn. This is definitely one of my top hopes for something to be fixed in 1.8, particularly with the new things being added to make traveling around water more worth while and because I would really like to be able to use my EATS road without this happening.

Confirmed in 14w25b on my server. Very annoying! I can't search for ocean monuments because as I travel, my boat isn't actually where I am, leading to crashing into islands that I'm far away from and chunks not loading because I'm "not there yet."

Ditto on 14w26c. I repeatedly get unloaded chunks even though I've been in them all. (I generally make my home in an ocean biome ever since 1.5)

This bug happens with 1.7.9 and 1.7.10 also. I experienced both issues above while exploring a massive ocean in search of a mushroom biome. Furthermore, once the boat broke without warning, nowhere near any land of any sort.

Ditto.

I decided to investigate this issue by inspecting the code. One of the problems is that the client pretends to own the boat when you enter it. Another is that it still pretends to own it after you exit it (there's some broken code that attempts to deal with it but is never called in the way it expects). While it thinks it owns it, it's completely unresponsive to position updates by the server. Current versions even have the audacity to break blocks, as in the lily pad test case (leaving two trails of broken lily pads, the one made by the client not existing on the server), leading to even more pernicious desynchronization.

A simple fix is for clients to always use server updates without attempting to apply physics (or ignoring updates off by less than a meter). During my testing on the integrated server it was still a smooth ride. And really, a little bit of delay is infinitely better than this game-ruining bug. My urgent suggestion is to apply this fix immediately. Then you can potentially work on making the client own the boat, and only put it in a release when it doesn't screw up. Heck, even horses run on the server, and with their acceleration and speed they could really be more responsive. Move those to the client if anything.

Thanks for the investigation, @unknown. I'm a little surprised that there's still some ugly bits of the old pre-client/server-separation logic floating around in the code, but as far as I know, they're planning on moving that all to the server as part of the preparation for the plugin API. Hopefully that will be enough to fix this issue completely.

@unknown, there is an attempt at separation, but it fails big time and then some. I doubt the plugin API will automatically make them get things right, although I don't know what it actually does.

A very basic fix for those wanting to mod their current MCP-less client:
1.7.10: xi.class: at 0x1DD9, change 2A 1B B5 00 69 to 00 00 00 00 00.
14w28b: acy.class: at 0x1E3E, change 2A 1B B5 00 58 to 00 00 00 00 00.
This keeps the client from thinking it owns the boat.

For increased responsiveness, also do:
1.7.10: xi.class: at 0xE1B, change 08 to 03.
14w28b: acy.class: at 0xE8C, change 08 to 03.
This makes the boat interpolate to the new position faster, which is potentially jerkier but more responsive. This is as fast as it would interpolate, had the bug not been there. Boats not ridden by you that are 'supposed' to interpolate slowly now also interpolate faster, but that shouldn't be an issue. A more granular fix would be much more elaborate than the change of a single byte, when it may not even be better.

"I'm a little surprised that there's still some ugly bits of the old pre-client/server-separation logic floating around in the code". Then you haven't used boats much.

Jonathan2520, you are a superhero for digging into this, pointing out the corrections which need to be made and even posting patches for existing releases. That's awesome. Now we just need Mojang to lift a finger and implement the fix you've found. Great work!

I would like to patch 14w21b. I can make the patch if I can find the right class file, but it's not acy.class. How do I identity the file?

@unknown, I often use strings or other constants to find known classes. "Boat" works well, leading to an entity directory where entity classes and names are linked. As long as Mojang didn't make major changes in the vicinity it should look familiar. In 14w21b it's zq.class:
At 0x1E1D, change 2A 1B B5 00 6B to 00 00 00 00 00.
At 0xE75, change 08 to 03.

I forgot to mention that the client does keep track of the position sent to it by the server in separate variables. If the client doesn't pretend to own the boat (which is only until the first time you enter it), it prepares itself to interpolate to the position in some default number of ticks (3) + 5. When the boat subsequently ticks, it does just that. If the client pretends to own the boat, it ignores updates off by less than a meter (bad, but not the main problem here) and prepares for interpolation in 3 ticks otherwise. But when the boat ticks, it just runs server physics without incorporating the update. Just a heads-up in case Mojang devs find this and are confused by it.

You can't predict based on an interpolated position, BTW, so don't even try. Don't do anything at all until you fully understand the implications, or you'll just complicate the problem further. This bug is already an example of that, and will continue to be if you don't put a stop to it by always simply interpolating on the client.

Just one more thing. Excuse all the updates. Something similar is going on with the boat's velocity. It doesn't quite break the game, but it can lead to things like boats sliding across the ground and periodically being put back where they really are. E.g. drop some water on flat ground and place a boat on the next to last water block in any cardinal direction. I don't feel like figuring this one out at the moment. It takes a ton of reverse engineering to work out all the interactions (not having source code (MCP at best) or the bigger picture of the workings that Mojang employees ought to have) and I'm doing it for free, mind you.

@jonathan2520
What are the MCP names for the bytecode locations you're changing in 1.7.10 above?
Would like to incorporate it into my vanilla bugfixer Forge mod (I'll give credit!)

@unknown: net/minecraft/entity/item/EntityBoat.java:
Clear method body of setIsBoatEmpty.
In setPositionAndRotation2, remove the addition of 5.

There are always tradeoffs in client/server communication. If you don't do any prediction, then movement becomes unresponsive in high-latency situations. If you do predict, then there's the risk of desynchronization. So it wouldn't be a change without any potential drawbacks, though it might be better than the current problems with boats as a temporary workaround.

They're aware that the client-server separation is incomplete. That's one of the things they know they have to fix in order to implement the plugin API. The server isn't supposed to trust the client, so clients wouldn't "own" boats. I imagine there will still be some prediction code, but the client should accept whatever the server says the position is, rather than ignoring it.

Mojang's pretty heavily focused on blocks, rendering, and performance for the 1.8 release. Entities, including boats, will probably get an overhaul in a future version.

The client does mostly own the body of its player. It's rare for the server to 'rubber-band' you outside of a few glitchy cases not related to lag, whereas others might see you skipping all over the place or taking a while to react to knockback. Last UHC had some amazing examples. Here's what's probably the most bizarre encounter, where it's evident that players own their own position:
mcgamer's perspective
PauseUnpause's perspective
Really, the fact that lag becomes most obvious when (unpredictable) players interact is very telling.

The client also predicts block placing/breaking, which usually works well. Once you get block lag there's so much lag that it's a miracle anything works at all. Could be better, but also could be so much worse. So there's already some examples where the client predicts (simplistically but pretty much correctly) or downright owns things. This does not cause (permanent) desynchronization. It isn't about predicting or not predicting; it's about doing whatever it is you're doing correctly. If there's a tradeoff, it's about complexity and relatively minor effects (such as entities not controlled by the client not turning smoothly if you make them lead the position sent by the server).

Playing 14w30c in single player, boats seem to be unusable. I broke 5 boats in a row in open ocean and only once found the drops on the shore some blocks away. I was also teleported on a short distance twice which hinted me to the location desync.

Edit: I managed to use my sixth boat a little longer and there was a lot of teleportations (the last one about 30-50 blocks away). In the end new chunks stopped being displayed (not sure if related) and I was sailing in the void above some ocean particles.

Edit2: Nevermind, I had a forgotten automatic chicken farm exploding. Boats went buggy before anything else. This is just boats being very sensitive to lag. Nothing new.

Playing in single player 14w32d I am getting the same issue with boats desyncing. The actual location of my boat is several blocks away from where I am seeing it on my screen. There is definitely a desync issue that has gotten worse since 1.7 which needs to be looked into and fixed.

This happens to me. The boat sometimes syncs and sometimes it runs into the shore and crashes. Riding by boat is very laggy and causes server overload. Fast traveling in general causes major overload.

@Tobias
The thing is, really good horses travel in the overworld at or above the speed of boats, yet the lag is much less pronounced.
Boats are just screwed up and need to be rewritten.

Contrary to what @unknown is saying, boats do not sync at all to clients that have entered them. At best the error remains small enough to have had no significant effect, yet.

@unknown: Up in the comments you can find a simple patch by me that keeps the client responsive to updates. It's so incredibly simple to make boats, well, work! A more comprehensive fix would be possible, but those few bytes are really all you need to make boats more than usable. Unfortunately such a patch needs to be remade for each version, which is why Mojang should fix it.

Yup, I saw it! Incorporated it into an ASM bugfixer mod for MinecraftForge.
Sometimes during lag I rubber band severely, but at least now I know where the true location of the boat is.

On reddit I read an interesting description of what exactly is happening with the boat desync bug after someone asked why the same problem doesn't happen with running, minecarts, or horseback riding:

"You know how you seem to stop running/carting/riding if you are lagging? Boats don't work like that - you just go on sailing despite lag, but then the server will then disagree with you on where you really are"

Confirmed for 1.8-pre1.

Seems to have been fixed in 1.8-pre3. Can anybody confirm this?

Definitely not fixed as of 1.8-pre3.

Applies just as badly in single-player, even on a computer which is quite capable. (last test: 1.7.10)

Boats shouldn't break with lillypads.

Confirmed on 1.8.1.

What happened to all the comments on this bug that were posted on Jan. 29, and the change to the description, and the switch to jonathan2520 as reporter of the issue?

Reporter has been changed. Changes made to the Jira had been reverted due to bugs with the previous upgrade, so some changes were lost.

Isaac King had changed the description to the one written by Vincent Lee, which is here: http://pastebin.com/tYU9havV. That change was lost.

@jonathan2520, now that you're the reporter (thanks CubeTheThird) could you change the description, either to Vincent Lee's, or write your own?

Excellent description, @jonathan2520, although I might have toned down the comment "you don't know what you're doing" slightly, for diplomacy's sake.

I hope the devs read this and address this frustrating, longstanding issue.

You don't really have to be a "good" developer to make a fun and popular game, so calling out amateur design shouldn't offend anyone. This site is filled with examples of haphazard coding.

I don't like to do that, but it's just too blatant. After years of dodgy boats I'm not going to dodge around the issue. If it takes pointing out their inadequacy to get them to step back and solve it in a way they can actually manage, then that's what it takes.

You know what the difference between boats and horses is? Notch implemented boats. The current development team has three options for dealing with problems like this: bandage, ugly hack, and complete rewrite. It appears they haven't chosen the best bandage, which would probably be disabling the line where the client takes control of the boat, as @unknown suggested in this comment. Yes, trying to be clever with someone else's too-clever-for-its-own-good code is almost certain to result in disaster.

But the current dev team really doesn't want to waste time patching up the current code. They've been overhauling huge portions of the code, and have fixed a lot of issues that way. I imagine they'll use @unknown's pocket edition implementation, much like they backported his cave culling algorithm for the PC version. Waiting for a full rewrite can be frustrating, but it's the most efficient use of their time. Any time they spend bandaging or hacking on this issue seems wasteful, when they're just going to replace the code anyway. They could use that time and energy more productively, and they have to prioritize. They're adults, you're not going to shame them into fixing the issue by "pointing out their inadequacy".

Regardless, the new description is a significant improvement over the old one, though the superflat preset won't work due to MC-59696. Here's a working preset string: "3;minecraft:bedrock,2*minecraft:water,minecraft:waterlily;24;oceanmonument,biome_1". It quickly and clearly illustrates the problem. A small amount of lag, such as when generating new chunks, will cause a second path of broken lily pads to appear. The player and boat will teleport to the server location after some time, and leaving and rejoining the world shows that client-generated path of broken lily pads didn't really happen.

I think this somehow belongs to here:
Discovered trough the commands in MC-31076

If you summon a boat riding a fireball, a smallfireball or witherskull. The game is pretty unsure where the boat acutally it.

/summon Boat ~ ~3 ~ {Riding:{id:Fireball,ExplosionPower:0,direction: [0.0, 0.0, 0.0]}}

Note that this only happens with boats

Confirmed for 15w31c. The boat stops randomly in the midst of an ocean, then starts again; when throwing an Eye of Ender it spawns ~7 blocks in front of me.

Confirmed for all snapshots up to and including 15w35e.

As an aside - at MineCon2015's recent question and answer session, Jeb was asked "When are you going to fix boats?" This was almost certainly directed at this problem, as it is perhaps THE most glaring issue in Minecraft as far as is noticable during normal play. He response suggested that he thought the asker was asking about the fragility of boats, not the syncing problem (his response was that it was WAD but that they will be adding more sturdy boat options in the future.) This may be a silly question, but are we sure they're aware of this? For me, this is the worst bug in the game!

@MatthewPlumb I agree that this longstanding bug is the most glaring issue in Minecraft because it's so noticeable. I, too, wonder if Jeb and Dinnerbone are even aware of this issue for the PC version of MC. If they aren't, is there any way to bring it to their attention?

@Evan Gamble

I'm sure they are. If you want to bring it to their attention, Twitter is best. Talking to some of the big minecrafters, like Sethbling, could also help, as they can speak with Mojang.

@KingSupernova

I did try to bring it to Dinnerbone's attention via twitter. Don't know if that worked. Then I emailed Sethbling and asked him about it. He replied and said they're definitely aware of the bug. So that's encouraging!

Searge on twitter:

For more information about boats, follow @_tomcc #MojangLeaks @Dinnerbone

Yeah

Fixed for 15w41a/b?

Still an issue on 15w41b. Teleported from the "edge of the world" unloaded chunk boundary back into an island I was nowhere near. Server was on localhost, so it wasn't a network issue.

WOW! I've been playing with the new boats on the latest snapshot, and they're great! The "rowing" took me a bit to get used to, until I realized I can just hold down both buttons and go. I'm still getting used to the steering, but they don't seem to catch and jump like they used to, they can be pushed but don't shoot away when you get out, and they don't break when you run into things. I ran full speed into a squid, and it wound up in my boat. It's still there, after I've gotten in and out, and slept a night. It's adorable.

I'm happy.

Cannot confirm for 43b. Haven't been getting this with the new boats.

Same here. Can no longer reproduce in 15w43b

Resolving as fixed for 15w43b.
If you're able to reproduce this issue in either 15w43b or newer, please create a new issue mentioning this one.