Ioan Vira

The bug description seems ok for me. No need to be updated.

Also I've seen moderators updating descriptions by adding references to relevant comments. So bug descriptions do not need to be managed by the reporter. Changing it may even cause confusion.

I agree with Kademlia. Numeric precision is an important issue which is taken into account by experienced developers. Now that Kademlia warned about this problem it is a matter of software analysis which can be done by any developer and maybe tested with junit.

Hi killerpommes,
You are dropping spawn eggs?
What happens if you make the walls 4 block high?
What happens if you make the walls 4 block high and you drop mobs instead of eggs?
In your screenshot, do I see a pig in the sheep area? It is interesting because no pig escaped into the "freedom".
Thanks.

Thanks for fixing the bug ProfMobius and thanks to the moderators who do a great work.
Special regards to Kumasasa and Mustek 🙂

Affects Version: 15w42a

So Mojang solved the desync boat issue by making the boat behave like all other entities which have no desync 🙂
They might have to redesign how entities turn to eliminate the slowdown in the first place. The max speed of boats is high enough to escape the "filter" loop. The slowdown is irritating.

If they change this behavior, a new one might be more realistic...
A turn of 180 degrees with a realistic algorithm is supposed to slow down gradually the entities to 0 and speed up in the opposite direction.
But this was I guess the former behavior with desync... Isn't it? 🙂 🙂

With such a behavior, the mobs will get stuck again nevertheless, but less often.
I seen zombies which rotate 180 degrees to chose a different path, seemingly shorter.

I was watching yesterday a let's play video and I noticed that boats too are now influenced by this problem.
https://www.youtube.com/watch?v=6ERbgU-ZBzM&t=1319

Please add my above comment into the description. Thanks 🙂

I made some research based on the latest Forge.
The problem is located in class EntityLivingBase method onLivingUpdate

Here is a pseudo-code:

/**onLivingUpdate is called frequently so the entity can update its state every tick as required.*/
call onLivingUpdate 
    if motionX < 0.005 set motionX = 0
    if motionY < 0.005 set motionY = 0
    if motionZ < 0.005 set motionZ = 0

    call moveEntityWithHeading(float strafe=0, float forward=0.0067620003)
        if entity is in water then set friction = 0.02
        call moveFlying(float strafe, float forward, float friction)
            motionX = motionX + something what depends on strafe forward friction
            motionZ = motionZ + something what depends on strafe forward friction
        end moveFlying
        // for a normal zombie which is turning in water, motionX and motionZ will be approximately 0.0045.
        // this value will be reset to 0 at the next onLivingUpdate call
        // therefore entities will never be able to speed up in water if they make the mistake to stop and turn around

        // moveEntity tries to move the entity by the passed in displacement
        call moveEntity(motionX, motionY, motionZ)
    end moveEntityWithHeading
end onLivingUpdate

Note: moveFlying is called always. The name chosen by Forge guys is misleading.

A friction value = 0.03 would solve the problem. To be tested with diagonal movement!!
On ground covered by snow, the friction is 0.23.
The "friction" name for this coeficient may also be misleading.
Another parameter with the same purpose is jumpMovementFactor (also 0.02). It is applied when the entity is jumping in the water and for a short time is above the water (if is a zombie, will burn a little bit)

@Jill S Try Y33. I guess the spawning will be low.
I will stop following this issue. Good luck.

@Sonic You are correct. They just made some changes in that release which seem related to spawn : "Update: Snapshot 14w20b has been released to fix mobs not spawning naturally." I think they unintentionally fixed this bug or made it harder to reproduce.

@People: The original description is "When I updated to the new 1.7.4 version of Minecraft It seemed normal. At first I had reasonable spawn rates, but for some reason after a night or two in game I got 5 mobs at most.".
The problem was not occurring fast and was not easy to reproduce. You had to play the game for awhile and maybe it was happening, maybe not.

I think this bug as originally described vanished in
https://mojang.com/2014/05/minecraft-snapshot-14w20a/

A new bug should be opened for other occurrences.

@Jill S : mob spawners ignore the maximum mob cap.

As stated on wiki, game tries to spawn mobs 20 times per second.
http://minecraft.gamepedia.com/Spawn#Mob_spawning

"If the pack location is suitable, [...]"

But the game will not calculate for each chunk 20 times per second the altitude. It somehow knows the altitude where it should test for suitable locations. Possibly the altitude is calculated

• at chunk load (here MCEdit I guess may disturb things)

• and should be adjusted during the day-night cycle or light update

If mobs spawn fine on a new survival mode map, you can assume you have found no bug.

Add screenshots with F3 info to show the mob count as proof.
Else developers will not believe you.

If anyone knows how the game find the altitude, please share some info 🙂

I find the MCEdit hint interesting.
@Jill S : On the MCEdit modified platform, where the altitude is 238, can you please try placing some blocks in the area where you expect mobs to spawn? Just to see if the game behavior changes after you modified the chunk manually.
And another thing you can try is to increase the altitude gradually to see where the problem starts to occur. Maybe you notice something interesting during these experiments.
Add some screenshots too 🙂

It would be nice if you attach screenshots with F3 info.

@Jill S: " especially for mob traps built at high altitudes" ? If altitude is low, what happens?

" I seem to remember a server setting for this"
See http://minecraft.gamepedia.com/Spawn#Mob_spawning

In multiplayer, if the server.properties file has "view-distance=9" or below, mob spawning is severely reduced (or they de-spawn too quickly), and may result in the player encountering no mobs at all. Set the view distance to 10 or higher to ensure mobs spawn correctly.

The solution is poor as a concept but is not a bug. You can close the issue. It works as intended. (the reporter)

The spawning algorithm as described on http://minecraft.gamepedia.com/Spawn had small changes between 1.6.4 and later versions, tweaks or bug fixes.
The part "In single player mode, the chunk count is 17×17 = 289" was not changed.

I made some tests on 1.6.4, 1.7.2, 1.7.4 and 1.8.1 pre3 on render distance 2 or tiny.
Since 1.7.4 the render distance will limit the MultiplayerChunkCache to 49 (7x7). Before used to be 225 (15x15) or greater.
As a consequence, since 1.7.4, on render distance 2, the maximum allowed mob cap is much lower.

The bug which I noticed initially was about mobs not spawning at all:
I prepared in creative mode a platform, for a witch farm, and after awhile I noticed that mobs stopped spawning not only on the platform but everywhere.
Later in several survival worlds, mobs were not spawning during night or the number was very low.
The spawning rate was not restored by changing the render distance.
It was restored by exit and loading the map again. I was watching the almost empty desert from a top of a mountain and after reload it was filled with mobs.
This bug I think was fixed.

@Matthew: check you are on hard difficulty and then press F3 to see how many mobs are around you and be sure you have a rendering distance 8 or grater than 8.
Then type:
/tp @e[type=Zombie] ~ ~ ~
It will show you the coordinates of each zombie.

The actual behavior is too complicated to be a bug.
One could argument that the speed was decreased by mistake but a timer which changes the behavior seems to be a new feature or a fix of a previously not working one.