Well, given how utterly broken multi turned out to be, I approve of adding new features over bugfixing.

Thanks. I'm away from home now, and I don't think I'll get very far trying to play on my laptop over hotel wifi, but once I get back I plan on adding a minecart station.

Map is updated. My desert appears to be larger than the entire starting continent.

So there is. It's mine, all mine I tells ya!

Sorry about that. I didn't notice your door until I accidentally fell off the cliff above it.

I can make do. I'm planning on building a test dome over the small bay there in front of my mine. and put a train station inside. I think it'll look freaking awesome.

It's just the mapping software, it apparently likes to randomly transpose some chunks when creating the map.

I wonder how he's implemented this... Surely he hasn't done it properly.

But I hope it fixes some/most of the lag issues.

I did a tcpdump and took a cursory glance over the traffic pattern minecraft generates. There were several instances of ~60-byte packets in quick sequence, although there are runs of 1440 byte packets, which I assume are chunk updates. 1440 would be the MTU, so that's the ideal rate that you can send data at for maximum throughput.

This change will help a lot; I think. Unfortunately, the larger gain is going to come from a server-level view-distance. This is unfortunate because it will lead to a severely impacted user experience, and it doesn't solve the underlying problem.

I'm pretty confident that the problem isn't anything that will be tweaked to how the data is being transmitted. The server is simply transmitting too much data. For example, if you log in and stand completely still, the server will send you 2.85 MB of data. This is the initial map; I don't know if it's compressed but it certainly doesn't feel like it. While standing and doing nothing, you are constantly downloading at 8 KB/s. That's doing nothing, just staring at the wall. I took a ride on the train and the entire time the server was sending me data at 40 KB/s. That's just from riding the train! Here's another example: the bobbing of dropped items is synced to the server. As a quick experiment, I threw 200 blocks on the ground. My data rate increased by about 1.2 KB/s while staring at a wall.

Syncing the position of things every 20 seconds only compounds the problem Notch already has

Not to make you redo several hundred blocks of track, but shouldn't the rails be on the inside, so animals can't get in the way of the carts?

That's part of the problem. With a proper priority queue system in place, one large set of updates to one player wouldn't lag off the rest of the users. It would just take longer for that one user to "Sync" but then no-one would get kicked off, so I think that's a win over all.

It's also important to place IMPORTANT commands in a higher priority queue than regular old updates. Regular old chunk updates or silly animations would be given a low priority, and would only be sent after all the important, required stuff is sent.