Vanhart

Lately I've been playing with the Feed the Beast modpack, and finding a gradual buildup of poor FPS and randomly spiking fps.

I got fairly desperate with it, as the random nature of the fps falloff (F3 reporting single digit FPS around the 1-4 fps mark, with occasional 0 fps and sometimes upto 9 FPS) made the game unplayable due to its inconsistent responses to input.

I decided to try the current version of Optifine for minecraft 1.4.7. Having installed that and used, granted, minimal settings, the Optifine rendering engine delivers a stable, steady and thus playable FPS of about 15, using the same world that was unplayable under the default "randomly spiky" rendering engine.

While this doesn't necessarily point the finger firmly anywhere special, its does confirm that for the same (singleplayer) world and same computer hardware running it, there are some issues with the default rendering engine.

I know that isn't tons of help, after all, but it is a strong hint 😉

Hey tails. Sorry for the lack of updates.

The current release version of Minecraft, 1.4.7, no longer has this issue. I think it was actually resolved by a prior version, possibly 1.4.5.

I can confirm that it is definitely resolved under 1.4.7, however, and my world saves appear to persist almost immediately 😉

Just try not to loose the fix in a stray code branch 😉

On first glance, this looks like a "chunk loader fault" : a transient condition where a section of map (a chunk) doesn't appear properly client side (minecraft has a client-server setup even playing single player since a couple of versions ago).

If you place a torch at the edge of the "hole" to provoke a lighting update, this will often prompt the client to attempt to reload the chunk from the server. On SMP you can try relogging. Attempting to enter the chunk will cause your position to stutter, making movement almost impossible.

Note : this is a sneaky way of prospecting ore by sight 😉

Update :

Note : it was possible to get reasonably reliable persistence behaviour under 1.4.2 hitting ESC, waiting 30 sec, clicking save, waiting 30 sec and going back into the game. However the reliability of this was only about 75%.

Under the just-released version 1.4.4 the behaviour is still occasionally reproducible, especially when saving the diggings of just a few blocks. The game save behaviour is now about 90% reliable without waiting for the "silent save" to complete.

Clearly whatever it was, it got improved by the 1.4.4 release, but the underlying cause is still lurking about.

The "Saving game..." message is still conspicuously absent.

Fixed? No.

More reliable? Yes.

Please keep this issue on the front burner 😉

I am also experiencing this issue since the 1.4.2 live release on previously generated and newly generated worlds.

The behaviour is duplicated under both java 6.0 and the most recent Java 7 update 9 release. (tried updating, made no difference).

The behaviour is duplicated wether minecraft is running in the standalone launcher or the applet on minecraft.net/play.

OS : WinXP
CPU: Singlecore Athlon FX64
JRE: V7 Update 9 (build 1.7.0_09-b05)
Browser : Firefox 16.0.2

Notable behaviour:

The saved game appears to act as if there are two conflicting versions of the saved block state, which are persisted or loaded at random, depending on some unknown factor.

Nothing I've tried so far appears to give stable saved results, however once a set of blocks changes in "both" versions, the loaded results are consistent.

The versions don't appear to "toggle" between consecutive loads, but seem to depend on some random factor.

More info to follow as I go...