Marios

I'm not playing minecraft anymore so I don't keep track of the bugs I submitted but I checked this one and it is still affecting the game (1.7.10 and 14w31a).

which you should link to where he is saying so

I didn't say it's confirmed by Etho. But...

Thing to note here is if you start the server up while night it will spawn a healthy amount of mobs but as the days go on it will get to a point where you wont see any.

...this is exactly what happens with 2 Etho's traps I've built in 2 worlds that run as SSP only. Entities inside it slowly become lower and lower until spawning stops and there are none left and they will never spawn again (unless I increase render distance again).

A big problem is that, like you said, it requires a considerable amount of time to observe this happening and thus it can go unnoticed and easily labeled as "cannot reproduce".

I can confirm this in 1.7.4
On my dual core I usually have 45-60% total cpu usage while being inside spawn chunks. I noticed that when I'm exploring away from spawn chunks there is a great chance that total cpu usage will go up to 95-100% and stick there irreversibly. Staying still, waiting for all chunks to load (and chunk updates to drop to 0) does not make any difference. Nor does game restart. When this behavior is triggered I also experience severe server-client desync and I'm playing vanilla SSP on SSD. The only way to make this behavior go away is to go back to spawn chunks. Today I've even seen for the first time the "Out of memory" error message while experiencing this bug. Allocating more RAM does not solve the lag/desync issue either (I've even tried 4GB).
With this bug I'm forced to stay near spawn chunks. Otherwise with such long lag spikes and desync the game is unplayable.

I was very surprised to see that this even happens on core i7's. I hope this might help catch developers' attention.

I noticed that performance has noticeably decreased in 1.7.4 so I tried to search if any similar issues are already reported. I found that any issue similar to what I'm experiencing is linked to this one as duplicate. I still don't understand how performance issues are connected to this one which I didn't have the chance to observe yet (unless it is the same issue as MC-858).

Very nice post Jarod. You convinced me about the block tick issue being a different issue. But I got a little bit confused about this one.

Are you sure that in SSP, render distance and loaded chunks are tied together? Exactly for the reasons you described, meaning the problems that this would cause with mob spawning (for example), I always thought that render distance wouldn't affect loaded chunks or at least loaded chunks would never be less than 8x8 for the sake of proper mob spawning behavior. I thought that they are loaded but not rendered in order to decrease the load in gpu.

And if SSP is not affected by this bug how do you explain that mob spawning stops in Etho's simple mob trap (built at the highest chunk sections above an ocean) with render distance smaller than 8?

I do not get lower spawn rates while playing SSP, I do not know how you confirmed it being lower in SSP

I don't know what about my writings made you think that I said so.

Reading my answer I understand that it might be very confusing. By "lower" I mean lower than expected, lower than the limit of 79 when render distance is set low, not lower spawn rates in SSP (with low render distance) in comparison to SMP (with low render distance).

Confirmed with 1.7.4

The "Open LAN" feature is not affected by this bug

I know. This is why I wrote that the title could cause confusion. The title was "Server: View distance affects mob spawning". A more appropriate title would be "Server's viewing distance..."

Really this only does affect the server

Of course. What else could it affect? The client is not responsible for mob spawning.

The main problem is not about the ticks

How can you tell? Can you read Minecraft's code? I can't and I am not arguing with you, just asking.

I do not get lower spawn rates while playing SSP, I do not know how you confirmed it being lower in SSP

I don't know what about my writings made you think that I said so.

when you activated Open to lan then that is classed as SMP not SSP.

I didn't imply the opposite.

To make myself clear, I thought that the reporter with the title he used, he meant that this behavior only occurs in SMP. All I said was that, because SSP is in fact a local server with just one player connected, I can confirm this in SSP and I find the title confusing.

I've just realized that render distance does not only affect mob spawning but block tick in general. I was afk close to my ice farm and I noticed that water blocks beyond render distance wouldn't freeze. I uploaded a screenshot.

I think this is a duplicate of MC-2536. With render distance below 8-10 (I can't remember exactly) spawning is like its been disabled. It's clear by the screenshots that the selected render distance is lower than that.

This is exactly why I think the "server" should be omitted. I'm afraid that the way this bug is described currently could cause the confusion that this behavior starts to occur only after the world is being opened to lan. But I see you edited it. Thanks.

Guys why does the title, labels and description read "Server" ? Does this report only apply to SMP? What about SSP? I can confirm this behavior in SSP too. Does there have to be a different report for SSP?

On 1.7.2 SMP I noticed that the block disappears for the client but it is actually there, not allowing the player to move through it. I don't know about SSP.

You are using as an example an impossible scenario.
Maps on item frames won't update their content/image unless the player removes it from the item frame and holds it in hand. Also it takes the same amount of time for a 1:1 and a 1:16 framed map to load. So as long as it is framed, it is a non-changing image. I don't see how it would affect performance (bandwidth or cpu usage).

Thumbs down for resolving this as intended. Very disappointing.

@ [Mod] Ezekiel:
It happened twice while I was playing survival. First time the portal was partially broken by a ghast as shown in the screenshot. The second time it was partially broken by a creeper explosion.

What the hell? This is fixed for me on 1.7.2. I uploaded 2 screenshots, fixed_1.png and fixed_2.png
edit: Sorry I've just realized the fix only works with 16 chunks render distance setting (which is also bugged).

Fixed in 1.7

Zombie hunter, it's only now that I understand what you meant. You are right, the outline is shown behind water in occasions where it should be drawn in front of it. And that is indeed an issue that belongs in MC-9553. It just hadn't occurred to me yet, so I misinterpreted your words. I'll upload a screenshot in your report.

Have you set the frame limiter to 80 fps? In 1.7 versions I noticed (probably due to new rendering) that fps fluctuate a lot before stabilizing to a maximum, compared to previous versions of Minecraft.

It also occurs when achievements are shown in the chat box.

As long as a very simple thing like showing a link causes performance drop (13% on my rig), does it matter? I think not. I don't see why should we discuss whether one should want more than 60 fps or not. It's a feature of the game and players are not forced to play capped at their monitor's max refresh rate anyway.

I didn't and I still don't see why the outline (hitbox) should be treated as a particle or as a part of the in-game world. The outline is there to show the player which block/object he/she is pointing at, its dimensions (hitbox), and which side exactly he/she is pointing at. It shows which block/object the player is about to interact with. It's a tool. It has a purpose and a function, it is not part of the world.

In other words, I don't see how hitbox being visible behind water could be included in MC-9553. Also for the reasons I explained above I consider what is depicted in "expected_behavior_1.png" and "expected_behavior_2.png" to be the expected behavior.