Elf Elf

There is a logical continuity issue when "spawn chunks" are not at spawn. The command DOES NOT do what it is supposed to do; running this command will break the active spawn chunk region and make it work unreliably if a new player logs in after world spawn has been changed (this is an uncontrollable situation), or when a player happens to visit the new location (controllable, but an irritation). Until Mojang allows map makers to set the region of loaded chunks manually and independently of the world spawn, this is a real bug. I would appreciate it if you didn't inject your own personal opinion into someone else's bug reports.

As noted in duplicate bug report MC-42266, the world spawn coordinates are replicated to players upon respawn after death. The command needs to replicate the new coordinates immediately to all players in order to correct this bug.

A workaround to this problem is to append .0 to the X and Z coordinates, e.g. "/setblock -1.0 50 -1.0 stone". This ultimately makes no sense, since the block coordinate system should only take whole integers, but there is obviously something wrong with the algorithm they're using to convert negative integers.

Confirmed. Attached a screen shot with the output of a say command, with a clip of the NBT data of the command block. The formatting still works properly elsewhere in the game, such as in CustomName strings, but is broken in chat.

Formatting still works as it should outside of text chat, such as in the Command Block's "CustomName" NBT tag.

Confirmed, the crash is being caused by correctly-formed, vanilla ActiveEffects.

Try removing any UUIDLeast and UUIDMost tags from SpawnData and any Properties tags in SpawnPotentials.

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

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

Added 13w21a to list of affected versions.

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.

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.

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.

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 forgot to note that the spawn coordinates for the items are -95.5, 4.5, 581.5.

It was corrected the same night I told Dinnerbone about it on Twitter; this bug report was submitted at his request. As it's fixed, this report should be resolved.