if you create a spawner which spawns a mob with custom data, it will sometimes just spawn regular mobs around it, mostly on startup or when created if you use spawner to spawn the spawner!
EXAMPLE: Spawner should spawn a wither skeleton with armor on x 0, y 84, z 0, but it spawns regular skeletons around it before it can spawn the wither skeleton on x 0, y 84, z 0! I made some tests and realized, that the spawner will just show up the wither skeleton with armor after it spawned at least 1 skeleton! Until then is shows up a regular skeleton inside the spawner! So probably spawner containing zombies and skeletons will just load the spawner properties AFTER spawning at least 1 zombie or skeleton!
Comments 12
That's the problem, if you want to spawn an armored wither skeleton at special coordinates on time, you get a regular skeleton at the spawner. Problem: No wither skeleton, there where you need one, making things like redstone triggered boss spawner buggy and hard to make!
I've made redstone-triggered boss spawners before. You have a few options:
Have SpawnData, and do not have SpawnPotentials. This only works if you only wanted one potential spawn anyhow. The game will automatically generate SpawnPotentials based on your SpawnData and EntityId when it needs them, "upgrading" it to a proper spawner - the behavior will be consistent for all spawns. This is my method of choice.
Have both SpawnData and SpawnPotentials, where SpawnData is a copy of the Properties tag within your SpawnPotentials. This is the annoying method, as you have to make changes in two places every time you want to edit something - it's easy to mess up without knowing, and have dire consequences. At the same time, if you do everything correctly, you'll be creating a custom spawner in its "proper" final state, and it will be consistent.
Have SpawnPotentials but not SpawnData. This is what you're doing, and I somewhat recommend against it. To work around this method, you have to let it spawn at least once (and kill the vanilla-spawned mobs it creates) before the system 'decays' to the "proper" setup, where both SpawnData and SpawnPotentials exist. If you really want to use this method anyhow, I might recommend making EntityId something such as "Monster", which exists in the game but does not get spawned anyhow. This way, your first spawn will merely fail; there will be no mobs to clean up so the spawner can spawn again (and SpawnPotentials will change EntityId to the desired ID, also).
Note that the first two methods above (assuming you do them correctly) will spawn the desired mob every time - there will be no "oh, this time it just spawned a normal skeleton".
All of this is due to the meaning of SpawnData and EntityId. They are not deprecated or unused. They determine the next monster to spawn. They are what determine the monster you see spinning in the cage, also. Mojang can't just remove them, or it would break spawner consistency.
Is this still a concern in the current Minecraft version 1.6.2 / Launcher version 1.1.3 ? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
From what I can tell, this isn't a valid bug report. He was leaving SpawnData undefined, when SpawnData is what determines the properties of the next mob to be spawned. It's not "random" or "sometimes": If you don't define SpawnData, the next mob to spawn will not have custom data, because you never told it to.
I also found an easy way to avoid this issue: setting the Delay to -1 will cause SpawnData to be generated from SpawnPotentials the moment the chunk containing the spawner loads. Such a spawner will always spawn mobs with custom properties, as long as you've defined said properties.
I have been having this happen to me too, its pretty game-breaking for map makers and such.
Heres a video of it: http://youtu.be/O04rqD2nYTk
The bug here is that the game no longer serializes the "SpawnData" tag, but still requires its existence. As a result, it has become impossible to correctly configure a spawner: every time the NBT is loaded, SpawnData is ignored, and a mob will not have custom properties for its first spawn. Dandamannnnn's video demonstrates this well: each time the world is reloaded, a non-custom zombie spawns. This bug actually creates a very large number of issues and breaks many useful designs (ones which cannot be replaced with the /summon command).
The SpawnData tag is supposed to be serialized - the game still deserializes it and still requires it. The state of a spawner should not change upon world reload, and did not in prior versions. This is definitely a bug.
Can a mod please reopen this and confirm it for 13w39b? And also edit the description or title to include "SpawnData is no longer saved to disk"?
Alright, it seems Dandamannnnn made an open ticket for 13w39b: MC-33092
Anyone coming here experiencing this bug in the snapshots should go to that ticket instead - this one doesn't need reopening. (Also, mods, please don't close MC-33092 - it's not a duplicate if you leave this ticket "Invalid", because MC-33092 is valid).
This is because you have to specify SpawnData in addition to SpawnPotentials. The wiki's been having a bit of an edit war about these - I'm not sure whether it's a bug, but if you specify SpawnPotentials and not SpawnData, SpawnData is not initialized until the first spawn: the first spawn will use the default properties.