Jeff Bowman
- fyberoptic
- fyberoptic
- America/New_York
- Yes
- No
MC-85120![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
If that's the cause, then it's unlikely to be changed back. Their stated goal is to move as much game logic as possible to the server, for both security and so that plugins can modify it. In single player, it shouldn't matter whether it's on the client or server, since they're both being run on the same machine. In a multiplayer environment, mobs shouldn't be any less responsive than other players are. If that's not the case, then maybe there's something wrong with how that data is being synchronized. I believe some major cleanup is being done on entities for 1.9, so this issue may be addressed in the process. Jeff Bowman, what about the difference in squid behavior reported in the issue description? Is squid movement still handled in the client in 1.8?
This bug still exists in 1.5. I'm using a Radeon 5770. Using antialiasing after installing Optifine helps a little but not entirely, and unfortunately Optifine introduces its own issues as well for the time being so I removed it. The speckles are so distracting that I'm back on 1.4.7 for now.
This issue seems to have reverted in the 1.7 pre-release, as seen in the beginning of http://www.youtube.com/watch?v=TbrZPgpOCv8
I would like to point out that this particle issue was solved by Forge at some point as far back as 1.5. They simply moved the "litparticles" and "particles" rendering towards the bottom of the function which renders the world. Literally about eight lines worth of code moved into a different position seems to fix it without ill effect.
By default, the selection box, water, block destruction progress, weather, and hand are rendering on top of it, in that order. Forge positions it so that only the hand is rendered on top (as well as some Forge hooks, but that obviously doesn't apply to vanilla).
I realize that this is a trivial bug in the grand scheme of things, but I hope that this information will help put a quick end to this bug whenever someone can attend to it.
This has been the absolute most annoying bug for me in 1.8, and I've looked into finding the issue more than once. I finally found it.
Using MCP's mappings, go to EntityLivingBase.moveEntityWithHeading. Comment out the line "if (this.isServerWorld())". Fixed. Or at least fixed back to previous standards, complete with the minor stuttering of motion (probably caused by frequent position update packets, which should probably be tweaked to avoid that somewhat, but that's another issue).
But yeah, the movement wasn't being handled on the client like before, and was only happening through server-side packets, which completely loses the feel of the way the game used to work, and completely ruined it in my opinion.
EDIT: Here's a tweak class mod (compatible with Forge) to demonstrate: www.fybertech.net/minecraft/physicsfix-mc1.8-1.1.jar
It shouldn't make any difference, it's literally how 1.7.10 works. Previous versions all ran that block of code on both client and server.
The server sends periodic forced position updates anyway. And I played for quite a while and didn't see any adverse affects, other than the same issues it used to have of not being particularly smooth sometimes. I think even the rabbits work better.
The motion is different when it's only executed on the server because it goes through quite a different pathway of code before the changes are ever applied on the client, likely at least a tick later, and when they finally are, it's smoothed across 3 more ticks by default. I've disabled the smoothing before and it doesn't help; the severe stuttering between packets just looks even worse.
Squid are unaffected because they override moveEntityWithHeading and execute a single function (to directly apply movement). There is no server-side check here, which is why it's immediate for that particular mob. Either it was overlooked, or putting the check into EntityLivingBase's version was unintended.
Any advantages they gain by turning Minecraft into a dumb terminal are going to be negated by the resulting loss of response in the client, even in singleplayer, no matter how much they optimize the network code. The game has never had the same responsiveness as 1.2.5 because network packets are always trying to update position and velocity throughout the client's own animation. Although I do agree that some amount of update packets are still necessary to prevent them going out of sync altogether. Pre-1.8 felt like both systems were fighting one another, while 1.8 avoids the fight at the cost of response. There's got to be a better balance. But I'd take the moderate stutter from before than 1.8's solution any day.
Confirmed in 15w31c as well.
I think this bug should be marked as critical, because if you look at what's occurring in the code, it very much appears that the method is throwing the exception before it saves player or world data.
When the server shuts down normally then it's less of an issue because it also saves earlier in the shutdown process. But if a crash occurred elsewhere, this is supposed to be the last resort to preventing data loss, and yet it's crashing as well.
Confirmed in for 15w32a