Black Railings crash client and server when placed stacked 3 to a wall
Synxhronize opened this issue · 14 comments
Im not sure how this happens or why it's so specific, but when the black railings are placed against a wall and stacked on top of eachother 3 blocks tall, both the client and server crash. Im unsure if this is related to mod compatibility on the server this happened on or is a part of changed mc as a whole
I've tested this on entirely vanilla with only changed, it is not related to other mods.
Okay, this is definitely the weirdest crash I've seen. The client hangs and no crash log is produced.
I can confirm this happens without any mods, the only log output I can get is from my modded instance which throws watchdog errors (https://mclo.gs/JKgqmap).
dafuq.mp4
Okay, this is definitely the weirdest crash I've seen. The client hangs and no crash log is produced. I can confirm this happens without any mods, the only log output I can get is from my modded instance which throws watchdog errors (https://mclo.gs/JKgqmap).
dafuq.mp4
is that the fucking Prydwen from Fo4 in the background
Okay, this is definitely the weirdest crash I've seen. The client hangs and no crash log is produced. I can confirm this happens without any mods, the only log output I can get is from my modded instance which throws watchdog errors (https://mclo.gs/JKgqmap).
dafuq.mp4is that the fucking Prydwen from Fo4 in the background
Maybe... or maybe it's When Dungeons Arise.
[13:08:25] [Server thread/INFO] [minecraft/MinecraftServer]: [Dev: �ѿ�ʼ�̷���]
[13:08:25] [Render thread/INFO] [minecraft/ChatComponent]: [CHAT] �ѿ�ʼ�̷���
[13:08:30] [Server thread/WARN] [minecraft/MinecraftServer]: Can't keep up! Is the server overloaded? Running 2110ms or 42 ticks behind
[13:09:12] [Worker-ResourceReload-4/DEBUG] [ModernFix/]: Worker-ResourceReload-4 shutdown
[13:09:13] [spark-java-sampler-0-2/WARN] [spark/]: Timed out waiting for world statistics
[13:09:15] [ModernFix integrated server watchdog/ERROR] [or.em.mo.wo.IntegratedWatchdog/]: A single server tick has taken 40001, more than 40000 milliseconds
[13:09:38] [ModernFix integrated server watchdog/ERROR] [or.em.mo.wo.IntegratedWatchdog/]: Thread Dump:
"Render thread" prio=10 Id=1 RUNNABLE
at TRANSFORMER/[email protected]/net.ltxprogrammer.changed.block.RailingBlock.computeState(RailingBlock.java:305)
at TRANSFORMER/[email protected]/net.ltxprogrammer.changed.block.RailingBlock.updateShape(RailingBlock.java:366)
at TRANSFORMER/[email protected]/net.minecraft.world.level.block.state.BlockBehaviour$BlockStateBase.updateShape(BlockBehaviour.java:713)
at TRANSFORMER/[email protected]/net.minecraft.world.level.block.state.BlockBehaviour$BlockStateBase.updateNeighbourShapes(BlockBehaviour.java:654)
at TRANSFORMER/[email protected]/net.minecraft.world.level.Level.markAndNotifyBlock(Level.java:247)
at TRANSFORMER/[email protected]/net.minecraft.world.level.Level.setBlock(Level.java:214)
at TRANSFORMER/[email protected]/net.minecraft.world.level.block.Block.updateOrDestroy(Block.java:164)
at TRANSFORMER/[email protected]/net.minecraft.world.level.block.state.BlockBehaviour$BlockStateBase.updateNeighbourShapes(BlockBehaviour.java:655)
......
That means that the latex block refreshes after the other latex blocks are updated.
To put it simply: a stack trace indicates that your Minecraft module entered a recursive loop while processing a block update (markAndNotifyBlock or updateShape), which ultimately resulted in a “Stack Overflow” or Watchdog timeout.
@Override
public BlockState updateShape(BlockState state, Direction direction, BlockState otherState, LevelAccessor level, BlockPos pos, BlockPos otherPos) {
if (state.getValue(WATERLOGGED)) {
level.scheduleTick(pos, Fluids.WATER, Fluids.WATER.getTickDelay(level));
}
BlockState newState = super.updateShape(state, direction, otherState, level, pos, otherPos);
//newly added
// If the state has not changed, return directly
if (newState == state) {
return state;
}
//newly added
boolean fullyConnected = newState.getValue(SHAPE).getConnectionDirections(newState.getValue(FACING))
.filter(connectionDirection -> connectionDirection != direction)
.map(connectionDirection ->
canConnect(level, newState, connectionDirection, level.getBlockState(pos.relative(connectionDirection)), pos.relative(connectionDirection)).strength)
.filter(strength -> strength == ConnectionStrength.STRONG).count() == 2;
if (fullyConnected) {
return newState;
}
return computeState(level, pos, newState);
}
Thanks, but can you not spam my email please...
You could have put this all in one message.
Thanks, but can you not spam my email please... You could have put this all in one message.
I'll take care of it next time.
BlockState newState = super.updateShape(state, direction, otherState, level, pos, otherPos);
//newly added
// If the state has not changed, return directly
if (newState == state) {
return state;
}
//newly addedThis code will break the railing from connecting, as it will always early out even when the block should be updated. super.updateShape(state) in this context always returns state, but the notation is case anyone modifies the super function.
computeState(level, pos, newState); is doing all of the heavy lifting for deciding what state should be placed.
I suspect what's happening is that the block is updating when unrelated directions are updated (UP, DOWN).