draconicus
- draconicus
- draconicus
- America/Havana
- Yes
- No
MC-91827![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
A moot point now...
There appears to be an issue with UUID creation involving scoreboards. This may apply to mobs spawned without scoreboards, but I was not able to test for this. Below are my steps to reproduce the problem in two scenarios:
Create team ABC
This scoreboard is used for all tests below:/scoreboard teams add ABC
Test 1: Friendly and Neutral mobs
Create a spawner for Chicken on team "ABC":/setblock ~ ~ ~ minecraft:mob_spawner 0 replace {SpawnData:{id:"Chicken",Team:"ABC"}}
Result: One or two Chicken entities will spawn (random?), while Team "ABC" is populated with four (4) UUIDs for each visible Chicken spawn.
(reset Team "ABC" for next test)
Create a spawner for Wolf on team "ABC":
/setblock ~ ~ ~ minecraft:mob_spawner 0 replace {SpawnData:{id:"Wolf",Team:"ABC"}}
Result: One Wolf entity will spawn, while Team "ABC" is populated with four (4) UUIDs.
(reset Team "ABC" for next test)
Create a spawner for Horse on team "ABC":
/setblock ~ ~ ~ minecraft:mob_spawner 0 replace {SpawnData:{id:"EntityHorse",Team:"ABC"}}
Result: One or two EntityHorse entities will spawn (random?), while Team "ABC" is populated with four (4) UUIDs for each visible EntityHorse spawn.
ALSO, Team "ABC" seems to randomly populate with additional UUIDs not correlating to the visible spawning of visible EntityHorse. Always in multiples of four, suggesting that EntityHorse is periodically attempting and failing to spawn.
(reset Team "ABC" for next test)
Test 2: Hostile mobs
The symptoms of the problem are more serious with all Hostile mobs that were tested.Create a spawner for Zombie on team "ABC":
/setblock ~ ~ ~ minecraft:mob_spawner 0 replace {SpawnData:{id:"Zombie",Team:"ABC"}}
Result: No Zombie entities ever spawn. Scoreboard constantly fills with UUIDs under Team ABC. This appears to be four per tick.
Conclusion
It is apparent that Mob Spawners are making multiple attempts to spawn the subject entity, at least four times per successful "cycle". This has only been tested for entities with Team applied to SpawnData, but it may also apply to ALL Mob Spawner scenarios.With Team applied to SpawnData, hostile mobs seem completely unable to spawn. Despite this, there are constant attempts made (many per tick) to create the entity. Regardless of success, in all cases a very large number of UUIDs are written to scoreboard.dat under the Team and can only be removed via:
/scoreboard teams empty ABC
In the case of a hostile mob, if the Mob Spawner is left visibly idle, the scoreboard will fill up rapidly until a server failure occurs, at which point this netty error will appear for any player attempting to connect:
[19:47:22] [Server thread/INFO]: draconicus lost connection: TranslatableComponent{key='disconnect.genericReason', args=[Internal Exception: io.netty.handler.codec.EncoderException: java.lang.IllegalArgumentException: unable to fit 3372107 into 3], siblings=[], style=Style{hasParent=false, color=null, bold=null, italic=null, underlined=null, obfuscated=null, clickEvent=null, hoverEvent=null, insertion=null}}
This results in either an ambiguous "Disconnected" message for players attempting to join the server, or more commonly this message:
{/quote}
Internal Exception: java.io.IOException: Error while read(...): Connection reset by peerDuring the discovery of this problem, server failure occurred when a Team reached 158,728+ entries after the Mob Spawner went unnoticed for approximately 15 minutes.
Unrelated note: When the failure occurred, existing players were able to maintain connection despite being part of the scoreboard data. Only new connections failed.
There appears to be an issue with UUID creation involving scoreboards. This may apply to mobs spawned without scoreboards, but I was not able to test for this. Below are my steps to reproduce the problem in two scenarios:
Create team ABC
This scoreboard is used for all tests below:/scoreboard teams add ABC
Test 1: Friendly and Neutral mobs
Create a spawner for Chicken on team "ABC":/setblock ~ ~ ~ minecraft:mob_spawner 0 replace {SpawnData:{id:"Chicken",Team:"ABC"}}
Result: One or two Chicken entities will spawn (random?), while Team "ABC" is populated with four (4) UUIDs for each visible Chicken spawn.
(reset Team "ABC" for next test)
Create a spawner for Wolf on team "ABC":
/setblock ~ ~ ~ minecraft:mob_spawner 0 replace {SpawnData:{id:"Wolf",Team:"ABC"}}
Result: One Wolf entity will spawn, while Team "ABC" is populated with four (4) UUIDs.
(reset Team "ABC" for next test)
Create a spawner for Horse on team "ABC":
/setblock ~ ~ ~ minecraft:mob_spawner 0 replace {SpawnData:{id:"EntityHorse",Team:"ABC"}}
Result: One or two EntityHorse entities will spawn (random?), while Team "ABC" is populated with four (4) UUIDs for each visible EntityHorse spawn.
ALSO, Team "ABC" seems to randomly populate with additional UUIDs not correlating to the visible spawning of visible EntityHorse. Always in multiples of four, suggesting that EntityHorse is periodically attempting and failing to spawn.
(reset Team "ABC" for next test)
Test 2: Hostile mobs
The symptoms of the problem are more serious with all Hostile mobs that were tested.Create a spawner for Zombie on team "ABC":
/setblock ~ ~ ~ minecraft:mob_spawner 0 replace {SpawnData:{id:"Zombie",Team:"ABC"}}
Result: No Zombie entities ever spawn. Scoreboard constantly fills with UUIDs under Team ABC. This appears to be four per tick.
Conclusion
It is apparent that Mob Spawners are making multiple attempts to spawn the subject entity, at least four times per successful "cycle". This has only been tested for entities with Team applied to SpawnData, but it may also apply to ALL Mob Spawner scenarios.With Team applied to SpawnData, hostile mobs seem completely unable to spawn. Despite this, there are constant attempts made (many per tick) to create the entity. Regardless of success, in all cases a very large number of UUIDs are written to scoreboard.dat under the Team and can only be removed via:
/scoreboard teams empty ABC
In the case of a hostile mob, if the Mob Spawner is left visibly idle, the scoreboard will fill up rapidly until a server failure occurs, at which point this netty error will appear for any player attempting to connect:
[19:47:22] [Server thread/INFO]: draconicus lost connection: TranslatableComponent{key='disconnect.genericReason', args=[Internal Exception: io.netty.handler.codec.EncoderException: java.lang.IllegalArgumentException: unable to fit 3372107 into 3], siblings=[], style=Style{hasParent=false, color=null, bold=null, italic=null, underlined=null, obfuscated=null, clickEvent=null, hoverEvent=null, insertion=null}}
This results in either an ambiguous "Disconnected" message for players attempting to join the server, or more commonly this message:
Internal Exception: java.io.IOException: Error while read(...): Connection reset by peer
During the discovery of this problem, server failure occurred when a Team reached 158,728+ entries after the Mob Spawner went unnoticed for approximately 15 minutes.
Unrelated note: When the failure occurred, existing players were able to maintain connection despite being part of the scoreboard data. Only new connections failed.
There appears to be an issue with UUID creation involving scoreboards. This may apply to mobs spawned without scoreboards, but I was not able to test for this. Below are my steps to reproduce the problem in two scenarios:
Create team ABC
This scoreboard is used for all tests below:/scoreboard teams add ABC
Test 1: Friendly and Neutral mobs
Create a spawner for Chicken on team "ABC":/setblock ~ ~ ~ minecraft:mob_spawner 0 replace {SpawnData:{id:"Chicken",Team:"ABC"}}
Result: One or two Chicken entities will spawn (random?), while Team "ABC" is populated with four (4) UUIDs for each visible Chicken spawn.
(reset Team "ABC" for next test)
Create a spawner for Wolf on team "ABC":
/setblock ~ ~ ~ minecraft:mob_spawner 0 replace {SpawnData:{id:"Wolf",Team:"ABC"}}
Result: One Wolf entity will spawn, while Team "ABC" is populated with four (4) UUIDs.
(reset Team "ABC" for next test)
Create a spawner for Horse on team "ABC":
/setblock ~ ~ ~ minecraft:mob_spawner 0 replace {SpawnData:{id:"EntityHorse",Team:"ABC"}}
Result: One or two EntityHorse entities will spawn (random?), while Team "ABC" is populated with four (4) UUIDs for each visible EntityHorse spawn.
ALSO, Team "ABC" seems to randomly populate with additional UUIDs not correlating to the visible spawning of visible EntityHorse. Always in multiples of four, suggesting that EntityHorse is periodically attempting and failing to spawn.
(reset Team "ABC" for next test)
Test 2: Hostile mobs
The symptoms of the problem are more serious with all Hostile mobs that were tested.Create a spawner for Zombie on team "ABC":
/setblock ~ ~ ~ minecraft:mob_spawner 0 replace {SpawnData:{id:"Zombie",Team:"ABC"}}
Result: No Zombie entities ever spawn. Scoreboard constantly fills with UUIDs under Team ABC. This appears to be four per tick.
Conclusion
It is apparent that Mob Spawners are making multiple attempts to spawn the subject entity, at least four times per successful "cycle". This has only been tested for entities with Team applied to SpawnData, but it may also apply to ALL Mob Spawner scenarios.With Team applied to SpawnData, hostile mobs seem completely unable to spawn. Despite this, there are constant attempts made (many per tick) to create the entity. Regardless of success, in all cases a very large number of UUIDs are written to scoreboard.dat under the Team and can only be removed via:
/scoreboard teams empty ABC
In the case of a hostile mob, if the Mob Spawner is left visibly idle, the scoreboard will fill up rapidly until a server failure occurs, at which point this netty error will appear for any player attempting to connect:
[19:47:22] [Server thread/INFO]: draconicus lost connection: TranslatableComponent{key='disconnect.genericReason', args=[Internal Exception: io.netty.handler.codec.EncoderException: java.lang.IllegalArgumentException: unable to fit 3372107 into 3], siblings=[], style=Style{hasParent=false, color=null, bold=null, italic=null, underlined=null, obfuscated=null, clickEvent=null, hoverEvent=null, insertion=null}}
This results in either an ambiguous "Disconnected" message for players attempting to join the server, or more commonly this message:
Internal Exception: java.io.IOException: Error while read(...): Connection reset by peer
During the discovery of this problem, server failure occurred when a Team reached 158,728+ entries after the Mob Spawner went unnoticed for approximately 15 minutes.
Unrelated note: When the failure occurred, existing players were able to maintain connection despite being part of the scoreboard data. Only new connections failed.
There appears to be an issue with UUID creation involving scoreboards. This may apply to mobs spawned without scoreboards, but I was not able to test for this. Below are my steps to reproduce the problem in two scenarios:
Create team ABC
This scoreboard is used for all tests below:/scoreboard teams add ABC
Test 1: Friendly and Neutral mobs
Create a spawner for Chicken on team "ABC":/setblock ~ ~ ~ minecraft:mob_spawner 0 replace {SpawnData:{id:"Chicken",Team:"ABC"}}
Result: One or two Chicken entities will spawn (random?), while Team "ABC" is populated with four (4) UUIDs for each visible Chicken spawn.
(reset Team "ABC" for next test)
Create a spawner for Wolf on team "ABC":
/setblock ~ ~ ~ minecraft:mob_spawner 0 replace {SpawnData:{id:"Wolf",Team:"ABC"}}
Result: One Wolf entity will spawn, while Team "ABC" is populated with four (4) UUIDs.
(reset Team "ABC" for next test)
Create a spawner for Horse on team "ABC":
/setblock ~ ~ ~ minecraft:mob_spawner 0 replace {SpawnData:{id:"EntityHorse",Team:"ABC"}}
Result: One or two EntityHorse entities will spawn (random?), while Team "ABC" is populated with four (4) UUIDs for each visible EntityHorse spawn.
ALSO, Team "ABC" seems to randomly populate with additional UUIDs not correlating to the visible spawning of visible EntityHorse. Always in multiples of four, suggesting that EntityHorse is periodically attempting and failing to spawn.
(reset Team "ABC" for next test)
Test 2: Hostile mobs
The symptoms of the problem are more serious with all Hostile mobs that were tested.Create a spawner for Zombie on team "ABC":
/setblock ~ ~ ~ minecraft:mob_spawner 0 replace {SpawnData:{id:"Zombie",Team:"ABC"}}
Result: No Zombie entities ever spawn. Scoreboard constantly fills with UUIDs under Team ABC. This appears to be four per tick.
Conclusion
It is apparent that Mob Spawners are making multiple attempts to spawn the subject entity, at least four times per successful "cycle". This has only been tested for entities with Team applied to SpawnData, but it may also apply to ALL Mob Spawner scenarios.With Team applied to SpawnData, hostile mobs seem completely unable to spawn. Despite this, there are constant attempts made (many per tick) to create the entity. Regardless of success, in all cases a very large number of UUIDs are written to scoreboard.dat under the Team and can only be removed via:
/scoreboard teams empty ABC
In the case of a hostile mob, if the Mob Spawner is left visibly idle, the scoreboard will fill up rapidly until a server failure occurs, at which point this netty error will appear for any player attempting to connect:
[19:47:22] [Server thread/INFO]: draconicus lost connection: TranslatableComponent{key='disconnect.genericReason', args=[Internal Exception: io.netty.handler.codec.EncoderException: java.lang.IllegalArgumentException: unable to fit 3372107 into 3], siblings=[], style=Style{hasParent=false, color=null, bold=null, italic=null, underlined=null, obfuscated=null, clickEvent=null, hoverEvent=null, insertion=null}}
This results in either an ambiguous "Disconnected" message for players attempting to join the server, or more commonly this message:
Internal Exception: java.io.IOException: Error while read(...): Connection reset by peer
During the discovery of this problem, server failure occurred within 15 minutes of a Mob Spawner in this condition going unnoticed.
When the failure occurred, existing players were able to maintain connection despite being part of the scoreboard data. Only new connections failed.
After around 30 minutes, the Mob Spawner was destroyed as server administrators looked for the source of the connection problem.
When the scoreboard was recovered and examined, the Team had reached 158,728+ entries.
Kumasasa, each screenshot is showing a different version of the game with the same condition.
Grum, I appreciate your response. I'm afraid I don't understand what you mean.
The neighboring-block attribute called "up" refers to having a block above, yes?
Why is it being flagged under the described conditions, with no block above?
If this issue exists, I also worry about texture culling on north/south sides of other blocks.
To be clear: This is NOT a bug report about model implementation.
This is all about detecting neighboring blocks and correctly identifying those neighbors in block data.
I suppose it would be appropriate to rename it to "has a pole" or something then.
Previously it was possible for "up" to be false while "west" and "east were true.
My resource pack (and others I've seen) will depend on being able to control models based on whether or not "up" is true without compromising on other directions.
This feels very much like a regression to an older format. In pre-1.8 implementation, an early version of the cobblestone wall model could not support unique "up" variants on corners.
Mustek, redstonehelper: Please tell me what "up" was supposed to mean in 1.8.x.
redstonehelper: It's notable that any block above activated the "up" attribute previously. I would suggest consulting with person who first implemented these models to get clarification about the intended context. It seems consistent with context used for stairs and other neighbor-dependent objects.
You can see the problem I'm having with my resource pack as a result of this change. Any suggestions? I'm not willing to give up on the design.
Well thank you very much for showing me that code, Grum.
I'm a little surprised though. It looks like "UP" is now the "unless it's straight" choice.
I find it most interesting that it specifically is set ONLY when "!level.isEmptyBlock(pos.above()))", as in "isEmptyBlock" (air/null block), is NOT true.
If I'm interpreting that correctly, the following conditions make it a pole:
So how, exactly, does the pole show up in situations where the empty block is true, as in "level.isEmptyBlock(pos.above()))"?
I'm not 100% familiar with the syntax, but I suspect that would be:
This seems more likely also because putting a non-empty block above the "straight" segment adds a pole.
How are "air" tiles handled these days? Would "isEmptyBlock" match for "air" or only "null"? I think "null" tiles don't exist in the chunk format, so "isEmptyBlock" must mean "minecraft:air". We know it can't mean "any transparent block" because things like glass and vines also trigger the pole.
I greatly respect your position on the matter, and your cooperation in helping me understand has been wonderful.
It would be a clearer picture for me if I also understood the criteria for "isEmptyBlock".
Okay, so it's a globally inclusive statement. Anything that is not straight triggers it. Gotcha.