When configuring custom spawners, the "MaximumNearbyEntity" tag which is intended to set a cap for the spawner in relation only appears to have a vertical range of 4 above the spawner and 4 below the spawner. The Wiki states that the y range should be '"SpawnRange" +1 centred around the spawner block'. However, setting the "SpawnRange" tag to anything will still result in a above and below value of 4. This also means that if the position data of the spawned entities is above or below the vertical limits, the cap won't work correctly and they will continue to spawn until the game crashes. I am unsure if this is a bug however it seems desperately lacking as a feature if not in that the horizontal cap range can be made to be much larger than this.
Attachments
Comments 21
I'm having this issue. I have tested this in 1.6.1. I'll include some photos to explain the problem. But maxnearbyenemies does not appear to follow the setting over 5 blocks from the SpawnData.
Both monster spawners share the same properties. The left spawner is 5 blocks higher than the SpawnData position but the right spawner is 6 blocks higher than SpawnData position. The higher one will constantly spawn. The height is not affected but the MaxNearbyEnemies setting.
I should clarify that I set the Spawn position of the silverfish to where that glowstone is.
confirmed for 1.6.1
btw minecraft wiki says the height is always 8, but I still think this should be fixed yes.
Is this still a concern in the current Minecraft version 1.7.2 / Launcher version 1.3.4 ? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
I could not find a mention of spawnrange + 1, let alone that for vertical direction, in the wiki, but only constant values for each. (Am I missing something?)
In any case, the code in version 1.4.7 has the horizontal spawn and check ranges both based on spawn range, while the vertically both have constant values (-1 to +1 for spawning, -4 to +5 for checking). In all directions, the check range is at least twice as large as the spawning range. Thus, the described bug should not be possible.
Without proof for otherwise, I'd say "invalid".