Roadhog360
- Roadhog360
- roadhog360
- America/Indiana/Tell_City
- Yes
- No
![[Mojang] Cory Scheviak](../../../data/avatars/users/92893.png){kind=small}
MC-217834
Sorry, should've said all of that is what the console is doing when I try to start the server.
ERROR StatusLogger Unrecognized format specifier [d]
ERROR StatusLogger Unrecognized conversion specifier [d] starting at position 16 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [thread]
ERROR StatusLogger Unrecognized conversion specifier [thread] starting at position 25 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [level]
ERROR StatusLogger Unrecognized conversion specifier [level] starting at position 35 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [logger]
ERROR StatusLogger Unrecognized conversion specifier [logger] starting at position 47 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [msg]
ERROR StatusLogger Unrecognized conversion specifier [msg] starting at position 54 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [n]
ERROR StatusLogger Unrecognized conversion specifier [n] starting at position 56 in conversion pattern.
ERROR StatusLogger No log4j2 configuration file found. Using default configuration: logging only errors to the console. Set system property 'org.apache.logging.log4j.simplelog.StatusLogger.level' to TRACE to show Log4j2 internal initialization logging.
ERROR StatusLogger Unrecognized format specifier [d]
ERROR StatusLogger Unrecognized conversion specifier [d] starting at position 16 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [thread]
ERROR StatusLogger Unrecognized conversion specifier [thread] starting at position 25 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [level]
ERROR StatusLogger Unrecognized conversion specifier [level] starting at position 35 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [logger]
ERROR StatusLogger Unrecognized conversion specifier [logger] starting at position 47 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [msg]
ERROR StatusLogger Unrecognized conversion specifier [msg] starting at position 54 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [n]
ERROR StatusLogger Unrecognized conversion specifier [n] starting at position 56 in conversion pattern.EDIT: This is what the message was in the console.
Server did not start on my host machine.
ERROR StatusLogger Unrecognized format specifier [d]
ERROR StatusLogger Unrecognized conversion specifier [d] starting at position 16 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [thread]
ERROR StatusLogger Unrecognized conversion specifier [thread] starting at position 25 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [level]
ERROR StatusLogger Unrecognized conversion specifier [level] starting at position 35 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [logger]
ERROR StatusLogger Unrecognized conversion specifier [logger] starting at position 47 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [msg]
ERROR StatusLogger Unrecognized conversion specifier [msg] starting at position 54 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [n]
ERROR StatusLogger Unrecognized conversion specifier [n] starting at position 56 in conversion pattern.
ERROR StatusLogger No log4j2 configuration file found. Using default configuration: logging only errors to the console. Set system property 'org.apache.logging.log4j.simplelog.StatusLogger.level' to TRACE to show Log4j2 internal initialization logging.
ERROR StatusLogger Unrecognized format specifier [d]
ERROR StatusLogger Unrecognized conversion specifier [d] starting at position 16 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [thread]
ERROR StatusLogger Unrecognized conversion specifier [thread] starting at position 25 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [level]
ERROR StatusLogger Unrecognized conversion specifier [level] starting at position 35 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [logger]
ERROR StatusLogger Unrecognized conversion specifier [logger] starting at position 47 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [msg]
ERROR StatusLogger Unrecognized conversion specifier [msg] starting at position 54 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [n]
ERROR StatusLogger Unrecognized conversion specifier [n] starting at position 56 in conversion pattern.EDIT: This is what the message was in the console.
Server did not start on my host machine.
17w14a worked, so I know it's probably a problem with the jar that was distributed.
ERROR StatusLogger Unrecognized format specifier [d]
ERROR StatusLogger Unrecognized conversion specifier [d] starting at position 16 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [thread]
ERROR StatusLogger Unrecognized conversion specifier [thread] starting at position 25 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [level]
ERROR StatusLogger Unrecognized conversion specifier [level] starting at position 35 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [logger]
ERROR StatusLogger Unrecognized conversion specifier [logger] starting at position 47 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [msg]
ERROR StatusLogger Unrecognized conversion specifier [msg] starting at position 54 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [n]
ERROR StatusLogger Unrecognized conversion specifier [n] starting at position 56 in conversion pattern.
ERROR StatusLogger No log4j2 configuration file found. Using default configuration: logging only errors to the console. Set system property 'org.apache.logging.log4j.simplelog.StatusLogger.level' to TRACE to show Log4j2 internal initialization logging.
ERROR StatusLogger Unrecognized format specifier [d]
ERROR StatusLogger Unrecognized conversion specifier [d] starting at position 16 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [thread]
ERROR StatusLogger Unrecognized conversion specifier [thread] starting at position 25 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [level]
ERROR StatusLogger Unrecognized conversion specifier [level] starting at position 35 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [logger]
ERROR StatusLogger Unrecognized conversion specifier [logger] starting at position 47 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [msg]
ERROR StatusLogger Unrecognized conversion specifier [msg] starting at position 54 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [n]
ERROR StatusLogger Unrecognized conversion specifier [n] starting at position 56 in conversion pattern.EDIT: This is what the message was in the console.
Server did not start on my host machine.
17w14a worked, so I know it's probably a problem with the jar that was distributed.
However, I've seen other issues fighting over this just being an eula.txt problem and such. eula=true. I ran this on an existing 17w14a server, upgrading it. People say it only happens on existing worlds but I have not tried it yet.
Trying to connect to outdated server crashes game after backing to the server list.Server list crashes.
Title.
Trying to connect to outdated server crashes game after backing to the server list.
Also, the list randomly crashes if you scroll down a bit.
For some reason I can't get this to work again, but here's a crash log.
crash-2017-04-12_09.03.29-client.txtBacking out from outdated client message. (Might also happen on kicks, but only confirmed for outdated client)
crash-2017-04-12_09.06.50-client.txt
Trying to connect to outdated server crashes game after backing to the server list.
Also, the list randomly crashes if you scroll down a bit.EDIT:
For some reason I can't get this to work again, but here's a crash log.
crash-2017-04-12_09.03.29-client.txt
crash-2017-04-12_09.06.50-client.txt
crash-2017-04-12_09.01.38-client.txt
NOT a duplicate. This does NOT happen then I refresh the list, did you even read my issue?!
And before we are told to make a mod for it... While that is a somewhat viable idea, I do believe this issue with the core of Beta versions and other legacy builds should be addressed officially and be downloadable for everyone who has the Minecraft launcher, instead of through a mod.
The top and bottom sides of the wall all have the same texture as the other four sides, instead of their respective top and bottom textures.
Apologies if this is a duplicate, I have used the search function and found no similar issues.
Apologies if this is a duplicate. I searched and found no similar issues.
Some sandstone components seem to mine slower than others.Video for regular Sandstone: https://streamable.com/llyt7
Video for red sandstone:[#https://streamable.com/t9amu]Apologies if this is a duplicate. I searched and found no similar issues.
Some sandstone components seem to mine slower than others.Video for regular Sandstone: https://streamable.com/llyt7
Video for red sandstone: https://streamable.com/t9amu
Apologies if this is a duplicate. I searched and found no similar issues.
Some sandstone components seem to mine slower than others.Video for regular Sandstone: https://streamable.com/llyt7
Video for red sandstone: https://streamable.com/t9amuNo, this is not because of my resource pack.
The title is basically the whole issue. If you use a command to equip an item to a spectator's offhand, other players can hear a noise, despite the fact spectators essentially aren't supposed to exist, let alone make noises.
It also happens for other game modes, but I'd assume it's intended to happen to non-spectators.
Sorry if this is a duplicate, I tried to use more basic searches this time like 'spectator noise' and other simple terms, and found no related issues still.
The title is basically the whole issue. If you use a command to equip an item to a spectator's offhand, other players can hear a noise, despite the fact spectators essentially aren't supposed to exist, let alone make noises.
It also happens for other game modes, but I'd assume it's intended to happen to non-spectators.
So yeah, if there's a command block constantly modifying a spectator's offhand, it'll make really loud noises, and so I think this is a pretty bad bug.Sorry if this is a duplicate, I tried to use more basic searches this time like 'spectator noise' and other simple terms, and found no related issues still.
Ominous Banners from previous versions do not stack with ones from the current version.
Ominous Banners from previous versions do not stack with ones from the current version.
Additionally, banners dropped from captain Illagers will not stack from banners that have been broken from the ground, including if you place and break a captain banner.
Ominous Banners from different versions do not stack with each other/Captain banners not stacking with ones from the structure
Ominous Banners from different versions do not stack with each other/Captain banners not stacking with ones from the structureOminous Banner stacking issues
Various Ominous Banner stacking issues
Piglinsalwayslook at their left handLeft-handed Piglins look at the wrong hand when given gold
Sorry if this is a duplicate, I made sure to search through issues about the Piglin and didn't find anything related to this.
Even if a Piglin spawns left-handed, giving it gold will still cause it to look into its left hand, as if it were a right-handed Piglin. Happens for both sword and crossbow Piglins. Since the Piglins are supposed to look like they're gazing at the gold, I'm lead to believe this is an unintentional side-effect of some being left-handed.
I actually found this one by mistake; I was showing a friend all the ins and outs of the Piglin and I happened to notice this when one of the Piglins I was showing him was left-handed and did this, leading me to further testing.
The moral of the story is sometimes we don't find these, sometimes they find us!
It crashed in the server list of the game, is that not a bug? This makes no sense, what entirely is the difference between what you sent me and this Jira? Are there now two places to report bugs and I have to guess which one to use?
I would really like to know how this is not a bug and how this is invalid.
All is good now, but I would've liked to know that from the first comment. Thanks.
Hello! It's been a while. Sorry if this feature has already been reported, but the search feature isn't very good and I also had a hard time coming up with a good brief keyword to search this by
As we know, copper has been changed to oxidize based on random ticks, and Mojang cleverly implemented a system to keep the "wave" effect the old oxidizing system had, by pausing copper oxidation to let others "catch up". But if you place many copper blocks next to each other, it takes much longer than one copper block on its lonesome, even if they all are on the same level and shouldn't pause each other.
HOW TO REPRODUCE
Take one copper block, place it on the ground
Place a large cube of copper blocks using /fill or by hand. Do something 4x4x4 or larger.
Set random tick speed to 5000Observe: The singular block oxidizes immediately but the ones in the cube take a very, very long time even though the random tick speed is up.
Now let's look at the code.
default void tryDegrade(BlockState state, ServerWorld world, BlockPos pos, Random random) { int i = this.getDegradationLevel().ordinal(); int j = 0; int k = 0; Iterator var8 = BlockPos.iterateOutwards(pos, 4, 4, 4).iterator(); while(var8.hasNext()) { BlockPos blockPos = (BlockPos)var8.next(); int l = blockPos.getManhattanDistance(pos); if (l > 4) { break; } if (!blockPos.equals(pos)) { BlockState blockState = world.getBlockState(blockPos); Block block = blockState.getBlock(); if (block instanceof Degradable) { Enum<?> enum_ = ((Degradable)block).getDegradationLevel(); if (this.getDegradationLevel().getClass() == enum_.getClass()) { int m = enum_.ordinal(); if (m < i) { return; } if (m > i) { ++k; } else { ++j; } } } } } float f = (float)(k + 1) / (float)(k + j + 1); float g = f * f * this.getDegradationChanceMultiplier(); if (random.nextFloat() < g) { world.setBlockState(pos, this.getDegradationResult(state)); } } > Code provided from the Fabric Loom decompiled codeAs we can see, this code gets all blocks within 4 blocks of each direction. We can see if any copper that can degrade is in a lower stage, "return;" is called to stop the oxidizing process so it can wait for the other blocks to catch up.
If another copper is in a higher stage, K is added to, meaning the float value that stores the final chance of it oxidizing to the next stage, "g", becomes higher, effectively speeding up the oxidizing a little. However, if neither conditions are met for that copper block, that means the copper block being checked is in the same copper oxidation stage. We can see it then adds to the value "j". This causes the chance to get divided downwards for every copper block in the same stage that is nearby in the 4x4x4 radius, making the copper oxidize exponentially slower for every copper block in that range that's in the same oxidizing stage.
This doesn't seem quite right, this seems like an oversight to me.
Hello! It's been a while. Sorry if this feature has already been reported, but the search feature isn't very good and I also had a hard time coming up with a good brief keyword to search this by
As we know, copper has been changed to oxidize based on random ticks, and Mojang cleverly implemented a system to keep the "wave" effect the old oxidizing system had, by pausing copper oxidation to let others "catch up". But if you place many copper blocks next to each other, it takes much longer than one copper block on its lonesome, even if they all are on the same level and shouldn't pause each other.
HOW TO REPRODUCE
Take one copper block, place it on the ground
Place a large cube of copper blocks using /fill or by hand. Do something 4x4x4 or larger.
Set random tick speed to 5000Observe: The singular block oxidizes immediately but the ones in the cube take a very, very long time even though the random tick speed is up.
I know why this happens, so if it's a bug the devs know exactly where to go to fix it. Let's look at the code.
default void tryDegrade(BlockState state, ServerWorld world, BlockPos pos, Random random) { int i = this.getDegradationLevel().ordinal(); int j = 0; int k = 0; Iterator var8 = BlockPos.iterateOutwards(pos, 4, 4, 4).iterator(); while(var8.hasNext()) { BlockPos blockPos = (BlockPos)var8.next(); int l = blockPos.getManhattanDistance(pos); if (l > 4) { break; } if (!blockPos.equals(pos)) { BlockState blockState = world.getBlockState(blockPos); Block block = blockState.getBlock(); if (block instanceof Degradable) { Enum<?> enum_ = ((Degradable)block).getDegradationLevel(); if (this.getDegradationLevel().getClass() == enum_.getClass()) { int m = enum_.ordinal(); if (m < i) { return; } if (m > i) { ++k; } else { ++j; } } } } } float f = (float)(k + 1) / (float)(k + j + 1); float g = f * f * this.getDegradationChanceMultiplier(); if (random.nextFloat() < g) { world.setBlockState(pos, this.getDegradationResult(state)); } } > Code provided from the Fabric Loom decompilerAs we can see, this code gets all blocks within 4 blocks of each direction. We can see if any copper that can degrade is in a lower stage, "return;" is called to stop the oxidizing process so it can wait for the other blocks to catch up.
If another copper is in a higher stage, K is added to, meaning the float value that stores the final chance of it oxidizing to the next stage, "g", becomes higher, effectively speeding up the oxidizing a little. However, if neither conditions are met for that copper block, that means the copper block being checked is in the same copper oxidation stage. We can see it then adds to the value "j". This causes the chance to get divided downwards for every copper block in the same stage that is nearby in the 4x4x4 radius, making the copper oxidize exponentially slower for every copper block in that range that's in the same oxidizing stage.
This doesn't seem quite right, this seems like an oversight to me.
Copper takes longer to oxidize when other copper in the same stage is around it
Hello! It's been a while. Sorry if this feature has already been reported, but the search feature isn't very good and I also had a hard time coming up with a good brief keyword to search this by
As we know, copper has been changed to oxidize based on random ticks, and Mojang cleverly implemented a system to keep the "wave" effect the old oxidizing system had, by pausing copper oxidation to let others "catch up". But if you place many copper blocks next to each other, it takes much longer than one copper block on its lonesome, even if they all are on the same level and shouldn't pause each other.
HOW TO REPRODUCE
Take one copper block, place it on the ground
Place a large cube of copper blocks using /fill or by hand. Do something 4x4x4 or larger. Make sure the cube is at least 4 blocks away from the single copper.
Set random tick speed to 5000Observe: The singular block oxidizes immediately but the ones in the cube take a very, very long time even though the random tick speed is up.
I know why this happens, so if it's a bug the devs know exactly where to go to fix it. Let's look at the code.
default void tryDegrade(BlockState state, ServerWorld world, BlockPos pos, Random random) { int i = this.getDegradationLevel().ordinal(); int j = 0; int k = 0; Iterator var8 = BlockPos.iterateOutwards(pos, 4, 4, 4).iterator(); while(var8.hasNext()) { BlockPos blockPos = (BlockPos)var8.next(); int l = blockPos.getManhattanDistance(pos); if (l > 4) { break; } if (!blockPos.equals(pos)) { BlockState blockState = world.getBlockState(blockPos); Block block = blockState.getBlock(); if (block instanceof Degradable) { Enum<?> enum_ = ((Degradable)block).getDegradationLevel(); if (this.getDegradationLevel().getClass() == enum_.getClass()) { int m = enum_.ordinal(); if (m < i) { return; } if (m > i) { ++k; } else { ++j; } } } } } float f = (float)(k + 1) / (float)(k + j + 1); float g = f * f * this.getDegradationChanceMultiplier(); if (random.nextFloat() < g) { world.setBlockState(pos, this.getDegradationResult(state)); } } > Code provided from the Fabric Loom decompilerAs we can see, this code gets all blocks within 4 blocks of each direction. We can see if any copper that can degrade is in a lower stage, "return;" is called to stop the oxidizing process so it can wait for the other blocks to catch up.
If another copper is in a higher stage, K is added to, meaning the float value that stores the final chance of it oxidizing to the next stage, "g", becomes higher, effectively speeding up the oxidizing a little. However, if neither conditions are met for that copper block, that means the copper block being checked is in the same copper oxidation stage. We can see it then adds to the value "j". This causes the chance to get divided downwards for every copper block in the same stage that is nearby in the 4x4x4 radius, making the copper oxidize exponentially slower for every copper block in that range that's in the same oxidizing stage.
This doesn't seem quite right, this seems like an oversight to me.
Hello! It's been a while. Sorry if this feature has already been reported, but the search feature isn't very good and I also had a hard time coming up with a good brief keyword to search this by
As we know, copper has been changed to oxidize based on random ticks, and Mojang cleverly implemented a system to keep the "wave" effect the old oxidizing system had, by pausing copper oxidation to let others "catch up". But if you place many copper blocks next to each other, it takes much longer than one copper block on its lonesome, even if they all are on the same level and shouldn't pause each other.
HOW TO REPRODUCE
Take one copper block, place it on the ground
Place a large cube of copper blocks using /fill or by hand. Do something 4x4x4 or larger. Make sure the cube is at least 4 blocks away from the single copper.
Set random tick speed to 5000Observe: The singular block oxidizes immediately but the ones in the cube take a very, very long time even though the random tick speed is up.
I know why this happens, so if it's a bug the devs know exactly where to go to fix it. Let's look at the code.
default void tryDegrade(BlockState state, ServerWorld world, BlockPos pos, Random random) { int i = this.getDegradationLevel().ordinal(); int j = 0; int k = 0; Iterator var8 = BlockPos.iterateOutwards(pos, 4, 4, 4).iterator(); while(var8.hasNext()) { BlockPos blockPos = (BlockPos)var8.next(); int l = blockPos.getManhattanDistance(pos); if (l > 4) { break; } if (!blockPos.equals(pos)) { BlockState blockState = world.getBlockState(blockPos); Block block = blockState.getBlock(); if (block instanceof Degradable) { Enum<?> enum_ = ((Degradable)block).getDegradationLevel(); if (this.getDegradationLevel().getClass() == enum_.getClass()) { int m = enum_.ordinal(); if (m < i) { return; } if (m > i) { ++k; } else { ++j; } } } } } float f = (float)(k + 1) / (float)(k + j + 1); float g = f * f * this.getDegradationChanceMultiplier(); if (random.nextFloat() < g) { world.setBlockState(pos, this.getDegradationResult(state)); } } > Code provided from the Fabric Loom decompilerAs we can see, this code gets all blocks within 4 blocks of each direction. We can see if any copper that can degrade is in a lower stage, "return;" is called to stop the oxidizing process so it can wait for the other blocks to catch up.
If another copper is in a higher stage, K is added to, meaning the float value that stores the final chance of it oxidizing to the next stage, "g", becomes higher, effectively speeding up the oxidizing a little. However, if neither conditions are met for that copper block, that means the copper block being checked is in the same copper oxidation stage. We can see it then adds to the value "j". This causes the chance to get divided downwards for every copper block in the same stage that is nearby in the 4x4x4 radius, making the copper oxidize exponentially slower for every copper block in that range that's in the same oxidizing stage.
This doesn't seem quite right, this seems like an oversight to me.
Hello! It's been a while. Sorry if this feature has already been reported, but the search feature isn't very good and I also had a hard time coming up with a good brief keyword to search this by
As we know, copper has been changed to oxidize based on random ticks, and Mojang cleverly implemented a system to keep the "wave" effect the old oxidizing system had, by pausing copper oxidation to let others "catch up". But if you place many copper blocks next to each other, it takes much longer than one copper block on its lonesome, even if they all are on the same level and shouldn't pause each other.
HOW TO REPRODUCE
Take one copper block, place it on the ground
Place a large cube of copper blocks using /fill or by hand. Do something 4x4x4 or larger. Make sure the cube is at least 4 blocks away from the single copper.
Set random tick speed to 5000Observe: The singular block oxidizes immediately but the ones in the cube take a very, very long time even though the random tick speed is up. According to the code, the copper should go a little faster to "keep up" with the block which oxidized, but due to the missing checks for copper in the same stage, it takes much longer instead.
I know why this happens, so if it's a bug the devs know exactly where to go to fix it. Let's look at the code.
default void tryDegrade(BlockState state, ServerWorld world, BlockPos pos, Random random) { int i = this.getDegradationLevel().ordinal(); int j = 0; int k = 0; Iterator var8 = BlockPos.iterateOutwards(pos, 4, 4, 4).iterator(); while(var8.hasNext()) { BlockPos blockPos = (BlockPos)var8.next(); int l = blockPos.getManhattanDistance(pos); if (l > 4) { break; } if (!blockPos.equals(pos)) { BlockState blockState = world.getBlockState(blockPos); Block block = blockState.getBlock(); if (block instanceof Degradable) { Enum<?> enum_ = ((Degradable)block).getDegradationLevel(); if (this.getDegradationLevel().getClass() == enum_.getClass()) { int m = enum_.ordinal(); if (m < i) { return; } if (m > i) { ++k; } else { ++j; } } } } } float f = (float)(k + 1) / (float)(k + j + 1); float g = f * f * this.getDegradationChanceMultiplier(); if (random.nextFloat() < g) { world.setBlockState(pos, this.getDegradationResult(state)); } } > Code provided from the Fabric Loom decompilerAs we can see, this code gets all blocks within 4 blocks of each direction. We can see if any copper that can degrade is in a lower stage, "return;" is called to stop the oxidizing process so it can wait for the other blocks to catch up.
If another copper is in a higher stage, K is added to, meaning the float value that stores the final chance of it oxidizing to the next stage, "g", becomes higher, effectively speeding up the oxidizing a little. However, if neither conditions are met for that copper block, that means the copper block being checked is in the same copper oxidation stage. We can see it then adds to the value "j". This causes the chance to get divided downwards for every copper block in the same stage that is nearby in the 4x4x4 radius, making the copper oxidize exponentially slower for every copper block in that range that's in the same oxidizing stage.
This doesn't seem quite right, this seems like an oversight to me.
Hello! It's been a while. Sorry if this feature has already been reported, but the search feature isn't very good and I also had a hard time coming up with a good brief keyword to search this by
As we know, copper has been changed to oxidize based on random ticks, and Mojang cleverly implemented a system to keep the "wave" effect the old oxidizing system had, by pausing copper oxidation to let others "catch up". But if you place many copper blocks next to each other, it takes much longer than one copper block on its lonesome, even if they all are on the same level and shouldn't pause each other.
HOW TO REPRODUCE
Take one copper block, place it on the ground
Place a large cube of copper blocks using /fill or by hand. Do something 4x4x4 or larger. Make sure the cube is at least 4 blocks away from the single copper.
Set random tick speed to 5000Observe: The singular block oxidizes immediately but the ones in the cube take a very, very long time even though the random tick speed is up. According to the code, the copper should go a little faster to "keep up" with the block which oxidized, but due to the missing checks for copper in the same stage, it takes much longer instead.
I know why this happens, so if it's a bug the devs know exactly where to go to fix it. Let's look at the code.
default void tryDegrade(BlockState state, ServerWorld world, BlockPos pos, Random random) { int i = this.getDegradationLevel().ordinal(); int j = 0; int k = 0; Iterator var8 = BlockPos.iterateOutwards(pos, 4, 4, 4).iterator(); while(var8.hasNext()) { BlockPos blockPos = (BlockPos)var8.next(); int l = blockPos.getManhattanDistance(pos); if (l > 4) { break; } if (!blockPos.equals(pos)) { BlockState blockState = world.getBlockState(blockPos); Block block = blockState.getBlock(); if (block instanceof Degradable) { Enum<?> enum_ = ((Degradable)block).getDegradationLevel(); if (this.getDegradationLevel().getClass() == enum_.getClass()) { int m = enum_.ordinal(); if (m < i) { return; } if (m > i) { ++k; } else { ++j; } } } } } float f = (float)(k + 1) / (float)(k + j + 1); float g = f * f * this.getDegradationChanceMultiplier(); if (random.nextFloat() < g) { world.setBlockState(pos, this.getDegradationResult(state)); } } > Code provided from the Fabric Loom decompilerAs we can see, this code gets all blocks within 4 blocks of each direction. We can see if any copper that can degrade is in a lower stage, "return;" is called to stop the oxidizing process so it can wait for the other blocks to catch up.
If another copper is in a higher stage, K is added to, meaning the float value that stores the final chance of it oxidizing to the next stage, "g", becomes higher, effectively speeding up the oxidizing a little. However, if neither conditions are met for that copper block, that means the copper block being checked is in the same copper oxidation stage. We can see it then adds to the value "j". This causes the chance to get divided downwards for every copper block in the same stage that is nearby in the 4x4x4 radius, making the copper oxidize exponentially slower for every copper block in that range that's in the same oxidizing stage.
This doesn't seem quite right, this seems like an oversight to me.
Hello! It's been a while. Sorry if this feature has already been reported, but the search feature isn't very good and I also had a hard time coming up with a good brief keyword to search this by
As we know, copper has been changed to oxidize based on random ticks, and Mojang cleverly implemented a system to keep the "wave" effect the old oxidizing system had, by pausing copper oxidation to let others "catch up". But if you place many copper blocks next to each other, it takes much longer than one copper block on its lonesome, even if they all are on the same level and shouldn't pause each other.
Yes, I know that copper in a different stage nearby directly speeds up the copper. This is NOT what I am referring to. I'm specifically referring to copper in the same stage nearby causing a slowdown, which makes no sense. I analyze the code later and determine there is definitely something missing.
HOW TO REPRODUCE
Take one copper block, place it on the ground
Place a large cube of copper blocks using /fill or by hand. Do something 4x4x4 or larger. Make sure the cube is at least 4 blocks away from the single copper.
Set random tick speed to 5000Observe: The singular block oxidizes immediately but the ones in the cube take a very, very long time even though the random tick speed is up. According to the code, the copper should go a little faster to "keep up" with the block which oxidized, but due to the missing checks for copper in the same stage, it takes much longer instead.
I know why this happens, so if it's a bug the devs know exactly where to go to fix it. Let's look at the code.
default void tryDegrade(BlockState state, ServerWorld world, BlockPos pos, Random random) { int i = this.getDegradationLevel().ordinal(); int j = 0; int k = 0; Iterator var8 = BlockPos.iterateOutwards(pos, 4, 4, 4).iterator(); while(var8.hasNext()) { BlockPos blockPos = (BlockPos)var8.next(); int l = blockPos.getManhattanDistance(pos); if (l > 4) { break; } if (!blockPos.equals(pos)) { BlockState blockState = world.getBlockState(blockPos); Block block = blockState.getBlock(); if (block instanceof Degradable) { Enum<?> enum_ = ((Degradable)block).getDegradationLevel(); if (this.getDegradationLevel().getClass() == enum_.getClass()) { int m = enum_.ordinal(); if (m < i) { return; } if (m > i) { ++k; } else { ++j; } } } } } float f = (float)(k + 1) / (float)(k + j + 1); float g = f * f * this.getDegradationChanceMultiplier(); if (random.nextFloat() < g) { world.setBlockState(pos, this.getDegradationResult(state)); } } > Code provided from the Fabric Loom decompilerAs we can see, this code gets all blocks within 4 blocks of each direction. We can see if any copper that can degrade is in a lower stage, "return;" is called to stop the oxidizing process so it can wait for the other blocks to "catch up".
If another copper is in a higher stage, K is added to, meaning the float value that stores the final chance of it oxidizing to the next stage, "g", becomes higher, effectively speeding up the oxidizing a little. However, if neither conditions are met for that copper block, that means the copper block being checked is in the same copper oxidation stage. We can see it then adds to the value "j". This causes the chance to get divided downwards for every copper block in the same stage that is nearby in the 4x4x4 radius, making the copper oxidize exponentially slower for every copper block in that range that's in the same oxidizing stage, which makes no sense.
This doesn't seem quite right, this seems like an oversight to me.
So if this is invalid, why hasn't the issue this duplicates also been marked as such? Because it isn't...!
Why is this intended?
If any individual sounds should be WAI or duplicate, let me know and I'll cross them off this ticket. If it's all WAI or duplicate, well, oops! Sorry. I hope this doesn't sound like a feature request, because I do legitimately believe this is an oversight.
Jukebox:
MC-200484
Weighted pressure plates:MC-689
Redstone: Uses the sound of solid stone, despite being a powder. It seems this one should use the sand sound
Redstone comparator, repeater, and lever: Uses the wood sound, despite the base being made of stone and cobblestone, respectively.
Cauldron: Uses the stone sounds, despite metal blocks using the metal sound, and hoppers, a very similar block, also using the metal sound
Cobwebs: Stone? That doesn't seem right. I think wool sounds would fit.
Tripwire hook: Sounds like stone despite the base being made of wood.
End rod: Sounds like wood, despite blocks made of its base (popped chorus fruit) using the stone sound, implying popped chorus fruit is very hard. Also blaze rods strike me as pretty hard too.
String: It uses the stone sounds. It's a little piece of string....Will update if I find any more blocks that use an objectively incorrect sound.
If any individual sounds should be WAI or duplicate, let me know and I'll cross them off this ticket. If it's all WAI or duplicate, well, oops! Sorry. I hope this doesn't sound like a feature request, because I do legitimately believe this is an oversight.
Jukebox:
MC-200484
Weighted pressure plates:MC-6897
Redstone: Uses the sound of solid stone, despite being a powder. It seems this one should use the sand sound
Redstone comparator, repeater, and lever: Uses the wood sound, despite the base being made of stone and cobblestone, respectively.
Cauldron: Uses the stone sounds, despite metal blocks using the metal sound, and hoppers, a very similar block, also using the metal sound
Cobwebs: Stone? That doesn't seem right. I think wool sounds would fit.
Tripwire hook: Sounds like stone despite the base being made of wood.
End rod: Sounds like wood, despite blocks made of its base (popped chorus fruit) using the stone sound, implying popped chorus fruit is very hard. Also blaze rods strike me as pretty hard too.
String: It uses the stone sounds. It's a little piece of string....Will update if I find any more blocks that use an objectively incorrect sound.
![[Mod] LateLag](../../../data/avatars/users/92884.png){kind=small}
Roadhog360 - But the block never had that texture ingame. It's like asking them to put in the pack internal textures that were never released.
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
What Roadhog360 said. Any "bump" comments will be removed. As [Mojang] Wenlan Yang said above, they don't have an ETA yet.
Still happens in 17w15a. This problem drives me insane with OCD. Please fix it.
This is real. Just tried it.
Nope. Not a duplicate.
The Linux take on this issue wasn't really touched too hard. It was mentioned to not work, but that's about it, and it was because of eula.txt, not this.
Also, I collected information from that issue you marked so everything you currently know is in one place and not scattered in a comments debate. This issue is barely a duplicate. Please read more into my issue before marking.
Additionally, this isn't resolved.
Sorry, noticed your comment on my phone, but the touchscreen was too hectic to delete my comment or say that I didn't try that. Sorry about that.
(By hectic, sometimes it'll just spazz out and start mashing random characters and doing random things, today it was so extreme I could barely type. Now I have my computer.)
Yeah, sorry. Jira's search function really isn't great. I promise I'm making an effort to find other tickets before my duplicates, lol.
Yeah, I did, as mentioned in my ticket. I literally searched 'Sandstone', but unfortunately Jira's search is really bad and barely even gave me anything sandstone-related to work with.
If you know of better ways to search, please let me know.
Confirmed for 20w06a.
All of it still is prevalent in 20w06a
Comment 1: I searched "Unable to modify player data" before posting this ticket. Annoyingly, Jira didn't even return any related search results to what I searched no matter how I worded it
Comment 2: That makes so much sense, than you so much. So... with that being said, how am I supposed to sync a player inventory?
Still happens in 20w07a.
It's not just banners from previous versions. Here's steps to reproduce my end of the banner stacking, bdm68.
1. Kill a captain Illager to get his banner. It can be any type of captain, to my knowledge all of the captain banners will stack together.
2. Collect some of the banners from an outpost.
Despite the fact they're supposed to be the same exact banner, ones that are dropped from captains, and broken blocks are different in that the block drop versions do not stack because they don't have their banner info hidden, whilist captain banners do.
Another thing to note; if you place a captain banner and break it, it will stack with banners from the outposts.
If the original submitter of this is no longer active, I'd like to request ownership of this issue.
Can we get any insight on when it might be looked into?
As stated in the description, I have already used the search feature. It is not very good.
Still in 20w07a.
Still happens in the latest snapshots.
Leo, why do you keep commenting this on every single ticket?
I made a temporary fix for this. I attached it to the post, but accidentally attached it twice. (Since I thought dragging it over would attach it to my own post, and it didn't work so I tried again and then noticed after that it was being put on the main post)
If a moderator could remove one I'd appreciate it.
Basically it's a simple sounds.json fix to make it play the other sound events for now, until Mojang fixes the blocks to use the correct sound events.
Should still happen in 20w08a.
This happened to me when I upgraded my world from 20w06a to 20w08a, ominous banners that were generated in the previous version didn't stack with ominous banners from the new version. Both banner stacking issues are still present.
I get new textures won't be added, but stuff like this would take mere minutes to add to the actual game. I don't get why simple things like this cannot be edited to preserve the old art style. It makes Programmer Art feel incomplete, and like the new textures are seeping into what should be the old block.
@Greymagic27
That ticket states that new textures won't be added. However, crying obsidian has existed in the past, and is not new. The logic behind the supplied ticket is that Mojang will not create new texture and only apply them to old blocks, and crying obsidian is both a block that already existed and won't need a new texture. The only difference is it was removed at one point, unlike the other programmer art blocks.
I do not believe that ticket should apply to crying obsidian.
MC-173154is wrongly marked as a duplicate of this, I've explained why in the comments of that ticket.This has been fixed in the latest snapshot anyways.
Can you guys please stop spamming 'bump'? It's spamming my E-Mails.
If there's no ETA I doubt they even knowif they'd have any other plans.
Thank you for posting. Due to moving process I recently haven't been able to post updates.
What do you mean? I thought these servers were permanently offline.
Hello Chandler. I see you have edited my ticket. Did the bug change, last time I checked it was offhand only.
Thank you for coming through, I haven't been able to test in a very long time.
Thank you so much to Mojang for fixing this!!!
It works with un-dyed candles too.
Is it a coincidence that your idea is exactly like what I had in mind or did you see my Reddit post?
This was marked as "Works as Intended". Why is this intended? This mechanic doesn't make much sense, why should copper take longer because other is around it?
I think it should be slowed down based on the amount of exposed faces, if anything. Even if you space out all copper within the detection zone to not touch, it takes a very long time compared to a lone block even if all faces are exposed, which seems pretty silly.
As no answer as been given on how this bug-like behaviour is intended, I'd like to offer a solution in the case it was incorrectly marked. If the mark is still someow correct, then ignore this, I guess.
if (m == i) {
continue;
}
Could be added below the brackets with m < i, which would keep the chance the same instead of making oxidation slower for every copper block in the same stage. Other blocks that are below or ahead would still affect the chance.
They indeed are different. Ones on outposts show their banner patterns while ones dropped by captains havw it hidden.
Still no words on why this is intended? I still can't think of a single reason this makes sense at all.
Yes, the whole area would take longer mathematically, but why should one block be affected? It's EXPONENTIALLY slower which makes no sense. Also all blocks, even in the same stage are slowed. Thus a cube takes so much longer when one block takes just under an hour usually. If the simple line of code I posted above was added it'd fix the issue entirely, as those first bits of oxidation would appear at the same speed on one block for blocks in the same stage around it, but after that the "spreading" effect would stay because copper doesn't oxidize until blocks around it are also on the same stage if there are blocks nearby which are in a newer stage.
I'm still going to believe this is a bug and share my opinions until a developer themselves confirms to me this is indeed intended.
How can we confirm every part of that equation functions as intended? Getting developer confirmation of course.
I agree. If no changes are actually planned, why do we have to be left in the dark speculating if anything is actually planned contrary to the "Work planned" comment? I mean, you can say that, but then proceeding to say literally nothing else, no updates on priority, nothing makes us think that was simply a lie.
Why should we be left guessing? Is communication not a priority especially when this could potentially bring in new customers for your brand AND satisfy some existing ones? The suggested changes are mutually benificial on both sides, so if they aren't planned why is there basically no communication?
Still awaiting developer response.
Very well put. This would be a mutually beneficial fix for Mojang and us.
If even. I am starting to think these previous developer comments were lies.
Still awaiting developer confirmation, added further explanation to clarify that a missing check is probably needed.
While there is nothing to imply this is intentional, there is nothing that implies it isn't either. This is not a lack of feature, but clearly missing functionality if you read my thorough explanation and realize this has nothing to do with exposed faces too.
Oh, I didn't know that, I only knew about changelogs which mentioned if the copper was in the further stage, or lower stage affecting the rates. Can I please see where this is documented?
Is this still going to happen? We have reached the projected deadline. Any updates?
And just like that, I have lost faith in Mojang's truthfulness about this. For a moment I believed it was actually going to be changed thanks to a community effort, but I believe now the deadline was just to silence the active discussion and keep old versions abandoned.
I would be more than happy to be proven wrong.
Server owners only run cracked Beta servers because they have no choice. If there was any official auth it would force their players to buy the game.
I would say it takes more effort to put up this ruse or even make these fake plans to show us than just... adding the redirect to the launcher. I'm sure even that Mr. Unpaid Intern could do it.
While the end of summer is still a fair bit away, I'd like to quickly inquire if this is planned for later this summer, the end, or soon?
Given the recent attempt at quietly adding a reporting system, I am starting to think Mojang is just pushing back the deadline on this simple fix to keep us quiet. Surely there's no way they'd want these ancient versions to be fixed when they want even more authentication on new versions...
Requesting the wording of "Rhys B was removed as reporter because they added an official-looking notice without consent from bug tracker staff. If they want to add anything to the bug report they can still comment and we will add it to the bug report if appropriate." in the pinned comment to be updated.
It heavily comes off that the current banner is not official, I am just now learning that there was a different banner (that was not official looking at all IMO) that was added, and then subsequently removed. The wording of this phrase makes it sound like the currently displayed notice is unofficial, when it in fact is official. I suggest this comment's wording be updated to clarify this is referring to a banner that was removed and is no longer exist, and is NOT about the current red banner that is visible on the issue.
This appears to be about the spelling of "snort" instead of "snout". "sherd" vs "shard" is not mentioned, so I think this should be re-opened.