The bug
The problem is that you are unable to tell from the NBT data whether the SpawnData
entity is the same entity object also stored in the SpawnPotentials
which would cause both to be overridden when using a spawn egg. In this case you would be as well unable to tell which of the SpawnPotentials
entries get overridden in case there are mutliple entries with the same tags and values. If the SpawnData
entity is not in the SpawnPotentials
list then only the SpawnData
entity gets modified.
|
| Changed tag |
---|---|---|
✔ | ❓ |
|
❌ | ✔ |
|
❌ | ❌ |
|
Key
SpawnData
spawned = Spawner spawned the entity provided in theSpawnData
tag alreadySpawnPotentials
set =SpawnPotentials
tag was set by a command, else the game adds this tagChanged tag = The tag that is changed
✔ = Yes
❌ = No
❓ = Does not matter
Note
For all the different situations listed above it does not matter if the SpawnData
tag is set
Possible reason
|
| Possible reason |
---|---|---|
✔ | ❓ | Next |
❌ | ✔ | Changing the entity stored as |
❌ | ❌ | Same entity object of |
Possible solution
One way to solve this would be to have a tag called SpawnIndex
(Integer) with these values:
Value | Situation |
---|---|
-1 |
|
0 to ... |
|
How to reproduce
|
| Spawner command |
---|---|---|
✔ | ❓ |
|
❌ | ✔ |
|
❌ | ❌ |
|
Use the respective spawner command
Right click with a Sheep spawn egg
Inspect the NBT data of the spawner, for example with the following command (while standing on top of the spawner)
/blockdata ~ ~-1 ~ {}
Linked issues
is duplicated by 2
Comments 10
I am unclear what the expected/desired behavior ought to be, and what makes this a bug. This just sounds like a (somewhat interesting and possibly useful to mapmakers) specification of the existing behavior.
@unknown, the bug is described in the first sentence but maybe a little bit too less in detail:
When you use a spawn egg on a spawner you are unable to tell which tag will change based on the NBT data of the spawner:
The problem is basically that you are unable to tell from the NBT data whether the SpawnData
entity is the same entity object also stored in the SpawnPotentials
which would cause both to be overridden. In this case you would be as well unable to tell which of the SpawnPotentials
entries get overridden in case there are mutliple entries with the same tags and value. If the SpawnData
entity is not in the SpawnPotentials
list then only the SpawnData
entity gets modified.
But the current behaviour is probably intended, you just need to know about it.
Is this still an issue in the latest snapshot 16w44a? If so please update the affected versions.
This is an automated comment on any open or reopened issue with out-of-date affected versions.
I am not sure I understand this ticket correctly, but the following bug can be reproduced easily on MC 1.12.1, both on a server and client world, and I assume it relates to this issue:
Give yourself a mob_spawner item and place it: Initially it will have SpawnData for 'Pig' and an empty list of SpawnPotentials internally. (Note: If you run /blockdata ~ ~-1 ~ {} it will report that the SpawnPotentials list contains an entry for 'Pig', however, internally, it actually doesn't. Reason for that mentioned below.)
Go far away in order to trigger saving of the BlockEntity. Or stop/start the server/world. When saved and having an empty list of SpawnPotentials, it will add an entry corresponding to its SpawnData to that SpawnPotentials list in its saving output. (That's also the reason why the /blockdata ~ ~-1 ~ {} command shows that entry: The command shows the saving output of the BlockEntity, not the actual data currently in use, at least not for the mob_spawner BlockEntity..)
Come back to the mob-spawner / load the world again: This will load the mob-spawner from the saved data. It now actually contains a 'Pig' entry in its internal SpawnPotentials list.
Get yourself a spawn_egg, for example of type zombie from the creative menu.
Make sure to get in survival mode. Not sure if creative mode has this issue as well.
Right-click the mob-spawner with the spawn_egg. This will set the entity type of the SpawnData.
Expected result: The mob-spawner will now spawn zombies instead of pigs.
Actual result: The mob-spawner will spawn one (wave of) zombie(s), and then switch back to spawning pigs. Reason: After each spawn wave the mob-spawner checks its SpawnPotentials (if it isn't empty) for the next entity to spawn, and replaces the SpawnData with the picked entity. And this list only contains 'Pig' after the save-load-cycle and even after changing the SpawnData with the spawn_egg.
Possible fix: Maybe clear the internal SpawnPotentials of the mob-spawner after the mob type was changed via a spawn_egg.
And / Or: Don't include the SpawnsData in the SpawnPotentials when being saved and having an empty SpawnPotentials list. So the blockdata-command will report correct (the actual) data, and the data doesn't change after a save-load-cycle.
I am sure and I know what the bug is. They don't delete the spawn potentials and current spawndata they get mobspawner logic and change a string that's it. It doesn't work they need to create method to reset both spawndata and spawnpotentials when right click on egg. Whether it be from the eggs fix which it should have to be a couple lines edited or they choose to add a reset mob spawner mobs method it needs to get fixed. Either way the ItemMonsterPlacer.class needs edits
Please provide some textual description of this issue. Based on your tables alone it is very hard to figure out the problem.