Stacked Entity Spawner creating mass duplicate ghost entities

I forgot to note that the spawn coordinates for the items are -95.5, 4.5, 581.5.

Alright I did a bit of testing with this. Basically a spawner spawning a stacked item entity spawner is bugged.
Here's what it does:

-Spawner1 is spawning Spawner2.
-Spawner2 is spawning an Item Entity that's riding an Item Entity at X

-Every time Spawner1 tries to spawn Spawner2, Spawner1 ALSO uses the "Riding" data that's in Spawner2, and spawns a phantom item at X

None of the SpawnData/SpawnPotentials stuff has to do with it.

Able to reproduce in 13w19a with the file you attached.

However, your schematic has some severe malformatting. It seems inconsequential here, but your last item has an empty riding tag, and your first item has tags which belong to a FallingSand.

More importantly, you're making the critical mistake of setting the Pos tag of the highest entity in a stack. In the NBT format, when an entity has a "Riding" tag, it is riding on top of another entity. In the game, it is illegal for an entity to assume its own position when it is riding on another entity - this is why endermen cannot teleport out of minecarts. The phantom bug occurs because the game is attempting to set the Pos of the top entity, when the actual position is determined by the bottom entity. This bug could perhaps remain open as phantoms should not be generated in any case, malformatted NBT or not, but it has no bearing on a map maker's ability to spawn stacked entities.

I have attached a schematic with correct formatting - you'll notice that the Pos tag is in the bottom-most entity, which also has no Riding tag. I am unable to reproduce the bug with this setup - please correct me if I'm wrong, but from what I can see it behaves exactly as it should.

That is arguably somewhat incorrect. All of the riding entities will be populated with position tags upon loading by Minecraft, but only the top-most entity's position tag exists in the base root of the entity. This is the entity that is serialized to disk upon world saving, and all of the other entities are merely appendages of it. You are correct that Minecraft will correctly populate the position fields when the base riding entity's position is set, however. This is a good work-around that I will implement in my filters. It should be noted that the base spawner was creating the phantom entities, and not the minecart spawner that is supposed to spawn it. The base spawner should not even attempt to spawn the stacked entities.

I find it incredibly strange that the base spawner would even attempt to spawn items at all - clientside or otherwise - when it's merely meant to spawn a spawnercart which spawns said items. How does one even go about testing that?

As for why it's incorrect to specify Pos in the top entity of a stack when dealing with spawners, you have to consider that spawners do not actually spawn the entity in with all the tags we specify in SpawnData/Properties. Instead, the entity is spawned as a default entity, and the properties are subsequently applied. There's no guarantee that the Pos property is applied before the Riding property. The sequence of events spawning a stack of entities with Pos tags may well be the following:

1. Spawn ItemA at default coordinates randomly chosen by Spawner.

2. Apply Pos tag to ItemA, moving it to these coordinates.

3. ItemA is riding ItemB, so spawn ItemB at default coordinates randomly chosen by Spawner.

4. Attach ItemA to ItemB, updating its position. ItemA's true position is now on top of ItemB and not where Pos specified.

The alternative:

1. Spawn ItemA at default coordinates randomly chosen by Spawner.

2. ItemA is riding ItemB, so spawn ItemB at default coordinates randomly chosen by Spawner.

3. Attach ItemA to ItemB, updating its position.

4. Apply Pos tag to ItemA, moving it to these coordinates. The server will consider this an invalid movement, as ItemA is riding ItemB and should not move independently of it.

Unfortunately, what may work for entities serialized in the world doesn't necessarily work for entities created by a spawner - I'd imagine that although it's correct for the top entity to have Pos during serialization, as the game is programmed to handle this formatting correctly at deserialization time, the same does not necessarily apply when entities are created by spawners. If so, it would be nice if Mojang could change the behavior to be more consistent, and you're right in saying the current phantom behavior remains a bug.

One thing I don't want them to do, of course, is to change the current behavior of "apply properties after spawning", as this would prevent mapmakers from doing things such as having a spawner in a dark room create a capped number of monsters in a light room.

After some testing with the "No phantom schematic" attached to this bug report, it appears that setting the Pos tag in the very base Riding tag will cause the entity to spawn where the MinecartSpawner entity is. Using a Pos tag in the root of the SpawnData tag will make the stacked entity spawn in the proper location, but with phantom entities. Using both will default to the stacked entity being spawned at the MinecartSpawner entity. It appears that the Pos tag has to be in the root level of the entity in order for it to appear in the desired location.

EBWOP: I wrote this before your most recent post.

I did a lot of testing, and I'm afraid I'm wrong - my workaround doesn't actually work. It seems the top entity is the proper one to get the Pos tag. If the bottom one gets it, the Pos tag has no effect.

Interestingly, the results I get when modifying your spawner setup seem to indicate that it's alright to have SpawnPotentials in the spawnercart with Pos and Riding tags - no phantoms are created in this case. However, regardless of what entityID you use, if SpawnData contains Riding entity information (regardless of whether or not Pos is present!) the phantoms are generated. Furthermore, the same happens if the spawner directly attempts to spawn Riding entities - in this case, since it'll eventually get sent to SpawnData, using only SpawnPotentials is not a workaround. Another very important thing to note - the set of phantom entities actually omits the topmost entity.

I think your theory that these phantoms are generated for the spinning caged entity are right on the mark. If you omit the Pos tag, phantoms are still generated, at 0,0,0. If you have a spawner spawn a spawnercart which spawns a spawnercart which has SpawnData containing a stacked entity, phantoms are still generated! You'll notice that the cage contains, peculiarly, a spinning miniature of a spawnercart, and within that is another, smaller spawnercart, and within that is the topmost entity of the stack. Regardless of how many layers you nest, this bug will occur.

This bug afflicts every form of stacked entity spawner, whether or not Pos tags or spawner minecarts are involved - and the only workaround is to use a spawnercart and involve absolutely zero spawner blocks, as spawnercarts do not attempt to render a specific entity inside themselves - just a pig, regardless of what is spawned. So there is a workaround, but it's an annoying one, particularly since a spawnercart which spawns spawnercarts will detect itself when checking MaxNearbyEntities.

There are two bugs at hand here - The major one is that the spawnerblock is attempting to render stacked entities, but ends up generating phantoms because it does not properly connect the ridden entities. The ideal fix would likely be to just render the topmost entity and not attempt to generate the remaining ones whatsoever - after all, it'd be hard to hide a stacked entity spawner if a gigantic pillar of entities would jut out of it! The second, lesser bug is that a spawnerblock which spawns spawnercarts will actually render what entities those spawnercarts would spawn, rather than rendering a pig, which better reflects the cart's actual appearance. Both of these bugs are wasteful of CPU.

Either way, update your ticket to specify that this bug indeed exists in 13w19a. Further, I'd recommend changing the title to something Mojang may consider a priority. Perhaps something like "Stacked/riding entity spawners generate countless duplicate ghost entities due to attempting to render entities spinning in spawnercage".

I just did a some testing, and setting the DisplayTile, DisplayData, DisplayOffset, and CustomDisplayTile tags prevents the phantom entities from being created. These display tiles override the rendering of the mob spawner, which confirms that this is a rendering bug. Since it's easy to implement those tags, this can be regarded as a minor bug.

This is anything but a minor bug, because this only works if you are spawning spawnercarts. Many people (Hypixel and Vechs aren't the only ones) spawn stacked entities directly, and there are no display tile functions which fix this for them. Furthermore, I just found out that the phantoms are as permanent as ever - I watched a phantom zombie train fall to extremely negative coordinates, and they simply will not disappear. As the spawner continues going, the client's performance continuously drops until they relog.

I have prepared some screenshots and a comprehensive test world of this bug; I'll upload them shortly.

Also, could you please update Versions to include 13w19a? I'd imagine Mojang is more likely to look for bugs confirmed in the latest version when considering things to fix.

Nevertheless, thank you for this elegant workaround!

Oops, I forgot that the problem originates from the mob spawner block itself! I've added the last two or three snapshots, along with 1.5.2, as these are all affected versions.

The test world I have attached provides a more-or-less comprehensive demonstration of the bug.

The stacked skeleton-on-zombie spawner, without a Pos tag, spawns a stack of phantoms at 0,0,0, which proceed to fall to negative infinity and are never deleted.

The spawnercart spawns the same entity set, with a Pos tag, in a small cage - this one causes no bugs.

The rightmost spawner is an example of the minor rendering issue: it's a spawnercart spawner, but it shows what the spawnercarts spawn (recursively!) rather than merely showing a pig-in-spawnercart as the spawned entity would appear.

You can press the "Permanent Peace of Mind" button to switch to peaceful - note that the phantoms are still generated on Peaceful but not at daytime. This is because the phantoms regenerate any time the spawner references/refreshes its SpawnData.

You can also take a ride down into the bowels of the void - just let yourself fall after you press the button, and you'll fall faster than the phantoms and eventually pass them. Note that they exist no matter how far down you go.

Thankfully, of course, this is an entirely client-side bug and the phantoms vanish upon relogging. If you do not relog, however, you may notice a significant performance drop over time.

Confirmed

Confirmed for 13w21a.

Added 13w21a to list of affected versions.

It should be noted that Vechs is using stacked mob spawners in his latest maps.

(Don't mind Spam Golem, that was me.)

Oh, awesome. Thanks, Dinnerbone!

No! I was making a map entirely dependent on this bug.
Does anyone know another way of achieving this 'ghost mobs effect'?

You mean, mobs without any sort of behavior, which cannot be destroyed?

You can sort of approximate it using Attributes - if a mob has a FollowRange of 0 and MovementSpeed of 0, they won't aggro against players (except possibly if the player comes in direct contact with the mob) and also will not move on their own. If they still have a walking animation, Slowness 8 will stop that too (have it set to Ambient to make the particles barely visible). The Invulnerable property will make them indestructable, and also make it so no interactions with them produce knockbacks or particles.

EDIT: and as an added benefit since you're using real mobs, it's possible to get rid of them by changing the difficulty to Peaceful or having them ride invisible entities riding minecart rails (and thus you can move them out of a player's sight). Also, since this bug is fixed, your map won't gradually overload your players' RAM if they don't relog 😉

Adam made this video. But I didn't want to use this because you can still trade with villagers. The overloading RAM wasn't really a problem, because I set the spawnradius to 0 so they would only spawn once. I guess I'll give your way a try. I don't think trading with villagers is such a problem. The despawning and setting the game to peacefull is a bigger problem, but I think I can use spawners to create them.

Well, if you don't want your ghosts to despawn when the player wanders far, make sure you set PersistenceRequired to 1. It won't stop Peaceful from deleting Hostiles, however.

As for trading with villagers, you could edit their available trade offers - I personally use some offer slots to communicate with the player, by creating an offer which is fully expired (red X on the trading arrow), where the villager's dialogue is on a renamed/loretext'd sign in the output slot, and the player's dialogue is on a similar sign in the input slot. If either participant has no dialogue, I instead make their item a Cauldron (Block ID, not Item ID), which just looks like an empty black square, similar to an empty item slot.

Also, since you're using real entities, you could also have custom names over their heads if you wanted.

Ah, yes PersistenceRequired. I've heard of that. I knew about the custom trades, but the trading is not a big deal. The player doesn't have items in my map anyway. It's just that I don't like the possibility to trade.
The biggest problem I'm having now is that there isn't a way of creating these entities like Adam did using the NBTedit mod (as far as I know) I'm using, so I'm going to have to use mcedit or an NBTeditor wich is a pain in the *** if you ask me.

Please move your conversation to someplace designed for map making discussions. Perhaps http://www.reddit.com/r/Minecraftmapmakers/ ; this site is for bug tracking.

Why are you at Y=-1827?