Elf Elf
- texelelf
- texelelf
- Europe/Stockholm
- Yes
- No
MC-4232![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Mojang] Searge (Michael Stoyke)](../../../data/assets/gravatar/searge.png){kind=small}
The new FireworksRocketEntity for fireworks don't save all of their properties to the Anvil Entity NBT list; this makes them non-persistent across world closing loading. There is an additional issue that since there are no tags to use, Spawners that spawn fireworks don't work properly.
The FireworksRocketEntities and their accompanying particles exist briefly before despawning, preventing FireworksRocketEntity spawners from working.The new FireworksRocketEntity for fireworks don't save all of their properties to the Anvil Entity NBT list; this makes them non-persistent across world closing and loading. There is an additional issue that since there are no tags to use, Spawners that spawn fireworks don't work properly. When spawned from spawners, FireworksRocketEntities and their accompanying particles exist briefly before despawning, preventing FireworksRocketEntity spawners from working.
Spawner creating massive numbers ofduplicate ghost entitiesStacked Entity Spawner creating mass duplicate ghost entities
I'm attempting to create a "Quest Marker" in Minecraft to guide players to new objectives using the needle on a compass. I would use the setworldspawn command to move the world spawn to the new objective's location, and thereby move the compass needle as well. However, the needle does not move from the previous position. The only thing that makes the compass update the world spawn location is player death; Minecraft does not replicate the new world spawn location to players until after they've respawned. It would seem best that the server would replicate the new coordinates to players after the command is executed. This may also be useful for SMP map authors in debugging circuits that use setworldspawn.
Obviously this isn't a huge issue, but it is an incongruity that make this and similar mechanics impossible.
I'm attempting to create a "Quest Marker" in Minecraft to guide players to new objectives using the needle on a compass. I would use the setworldspawn command to move the world spawn to the new objective's location, and thereby move the compass needle as well. However, the needle does not move from the previous position. The only thing that makes the compass update the world spawn location is player death; Minecraft does not replicate the new world spawn location to players until after they've respawned. It would seem best that the server would replicate the new coordinates to players after the command is executed. This may also be useful for SMP map authors in debugging circuits that use setworldspawn.
Obviously this isn't a huge issue, but it is an incongruity that make this and similar mechanics impossible.
To reproduce:
1. Create Superflat world.
2. /tp 0 60 0
3. /setworldspawn 0 60 0
4. /give @a compass
5. /kill
(Note that after respawning, the needle will point towards 0,0)
6. /tp 10000 60 10000
7. /setworldspawn 10000 60 10000
(Note that the needle still points at 0,0)
8. /kill
(Needle now points at 10000,10000)
After setting a new world spawn point, it is impossible to set blocks or summon entities there until the spawn point has been visited by a player. If the area is visited and then left, then it is possible to setblock and summon to those locations. To reproduce:
1. Create Superflat world.
2. /tp 0 60 0
3. /setworldspawn 10000 60 10000
4. /setblock 10000 60 10000 stone
("Cannot place block outside of the world" [if the region has never been loaded] or "The block couldn't be placed" [if it has])
5. /tp 10000 60 10000
6. /tp 0 60 0
7. /setblock 10000 60 10000 stone
(Block placed)You can continue to see this behavior if:
8. /tp 10000 60 10000
9. /setworldspawn 0 60 0
10. /setblock 0 60 0 stone
("Cannot place block outside of the world")Setworldspawn should actively move spawn chunks to the new location and load/generate it; as it is currently working, the command is only useful for avoiding using an NBT editor for moving the world spawn coordinates.
After setting a new world spawn point, it is impossible to set blocks or summon entities there until the spawn point has been visited by a player. If the area is visited and then left, then it is possible to setblock and summon to those locations. To reproduce:
1. Create Superflat world.
2. /tp 0 60 0
3. /setworldspawn 10000 60 10000
4. /setblock 10000 60 10000 stone
("Cannot place block outside of the world" if the region has never been loaded or "The block couldn't be placed" if it has)
5. /tp 10000 60 10000
6. /tp 0 60 0
7. /setblock 10000 60 10000 stone
(Block placed)You can continue to see this behavior if:
8. /tp 10000 60 10000
9. /setworldspawn 0 60 0
10. /setblock 0 60 0 stone
("Cannot place block outside of the world")Setworldspawn should actively move spawn chunks to the new location and load/generate it; as it is currently working, the command is only useful for avoiding using an NBT editor for moving the world spawn coordinates.
When trying to use testfor to detect an item entity with a specific name, the game fails to correctly parse the testfor command. The command in question is:
/testfor @e[type=Item,r=5] {OnGround:1b,Item:{id:"minecraft:bow",tag:{display:{Name:"Reds Bow"}}}}
For testing purposes, you can give yourself a bow to test this with using:
/give @p minecraft:bow 1 0 {display:{Name:"Reds Bow"}}Running the testfor command above returns:
"/testfor <player> [dataTag]"
...which means that it did not correctly parse the NBT and is telling you the proper parameters for the command. If you remove the "tag" tag, and use the following command:
/testfor @e[type=Item,r=5] {OnGround:1b,Item:{id:"minecraft:bow"}}
The game will output:
"Found item.item.bow"Curiously the command will work if you expand it as far as:
/testfor @e[type=Item,r=5] {OnGround:1b,Item:{id:"minecraft:bow",tag:{display:{}}}}
But as soon as the Name tag is added, the game fails to parse the command.UPDATE:
It looks like the problem is actually being caused by the space inside of the string. Other commands that also parse NBT strings, such as "clear," have this same behavior.
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.
I forgot to note that the spawn coordinates for the items are -95.5, 4.5, 581.5.
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.
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.
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.
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.
Added 13w21a to list of affected versions.
It should be noted that Vechs is using stacked mob spawners in his latest maps.
Please move your conversation to someplace designed for map making discussions. Perhaps http://www.reddit.com/r/Minecraftmapmakers/ ; this site is for bug tracking.
Try removing any UUIDLeast and UUIDMost tags from SpawnData and any Properties tags in SpawnPotentials.
Confirmed, the crash is being caused by correctly-formed, vanilla ActiveEffects.
Formatting still works as it should outside of text chat, such as in the Command Block's "CustomName" NBT tag.
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.
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.
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.
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.