Snow layer minecraft ошибка

OTG Plugin or Mod

• OTG Mod for Forge

OTG Version

• 1.12.2_v8_r1

Forge or Spigot Versions

Forge 14.23.5.2847

What other plugins are you running?

• jei_1.12.2-4.15.0.291.jar
• ‘OpenTerrainGenerator-1.12.2 — v8.3.jar’
• ‘Vanilla_Vistas 1.1.jar’

and either

• TheCampingMod_2.4.3.jar
  • RikMuldsCore_1.3.3.jar

or

• pyrotech-1.12.2-1.4.16.jar
  • athenaeum-1.12.2-1.17.4.jar
  • dropt-1.12.2-1.16.1.jar

Description

minecraft:snow_layer gets generated on top of modded blocks that do not seem solid to me. In my full pack I’ve observed this behaviour with various blocks when generating custom structures via recurrent complex. For testing purposes I’ve only used the aforementioned mods, but the issue persists nonetheless. I have tried both Biome Bundle as well as Vanilla Vistas.

Pyrotech

The Camping Mod

The expected outcome is — of course — that snow is not generated on top of blocks that are not ‘full blocks’. I don’t know why only I seem to have this problem. With a mod like pyrotech installed, it is very easy to reproduce on my end by tping to a ‘Cold Taiga’ biome.

Here is one of the logs in case it helps.

OTG Plugin or Mod

• OTG Mod for Forge

OTG Version

• 1.12.2_v8_r1

Forge or Spigot Versions

Forge 14.23.5.2847

What other plugins are you running?

• jei_1.12.2-4.15.0.291.jar
• ‘OpenTerrainGenerator-1.12.2 — v8.3.jar’
• ‘Vanilla_Vistas 1.1.jar’

and either

• TheCampingMod_2.4.3.jar
  • RikMuldsCore_1.3.3.jar

or

• pyrotech-1.12.2-1.4.16.jar
  • athenaeum-1.12.2-1.17.4.jar
  • dropt-1.12.2-1.16.1.jar

Description

minecraft:snow_layer gets generated on top of modded blocks that do not seem solid to me. In my full pack I’ve observed this behaviour with various blocks when generating custom structures via recurrent complex. For testing purposes I’ve only used the aforementioned mods, but the issue persists nonetheless. I have tried both Biome Bundle as well as Vanilla Vistas.

Pyrotech

The Camping Mod

The expected outcome is — of course — that snow is not generated on top of blocks that are not ‘full blocks’. I don’t know why only I seem to have this problem. With a mod like pyrotech installed, it is very easy to reproduce on my end by tping to a ‘Cold Taiga’ biome.

Here is one of the logs in case it helps.

Вылетает при загрузке Индустриал Крафт 2

Логи индустриал крафта:

[23:19:41] [Client thread/ERROR]: IndustrialCraft 2 Error

The IC2 config file contains an invalid entry for balance/recyclerBlacklist.

Invalid value at line 191 (recyclerBlacklist = minecraft:glass_pane, minecraft:stick, minecraft:snowball, minecraft:snow_layer, minecraft:snow, IC2:scaffold).

There is no item matching IC2:scaffold.
[23:19:41] [Client thread/FATAL]: Exception caught while showing an error.
java.lang.IllegalStateException: From thread Thread[Client thread,5,main]: Thread[Thread-7,5,main] already has the context current
	at org.lwjgl.opengl.ContextGL.checkAccess(ContextGL.java:184) ~[lwjgl-2.9.1.jar:?]
	at org.lwjgl.opengl.ContextGL.forceDestroy(ContextGL.java:241) ~[lwjgl-2.9.1.jar:?]
	at org.lwjgl.opengl.DrawableGL.destroy(DrawableGL.java:130) ~[lwjgl-2.9.1.jar:?]
	at org.lwjgl.opengl.Display$5.destroy(Display.java:834) ~[lwjgl-2.9.1.jar:?]
	at org.lwjgl.opengl.Display.destroy(Display.java:1095) ~[lwjgl-2.9.1.jar:?]
	at ic2.core.PlatformClient.displayError(PlatformClient.java:112) [PlatformClient.class:?]
	at ic2.core.util.ConfigUtil.displayError(ConfigUtil.java:330) [ConfigUtil.class:?]
	at ic2.core.util.ConfigUtil.asRecipeInputList(ConfigUtil.java:44) [ConfigUtil.class:?]
	at ic2.core.block.machine.tileentity.TileEntityRecycler.initLate(TileEntityRecycler.java:51) [TileEntityRecycler.class:?]
	at ic2.core.IC2.modsLoaded(IC2.java:572) [IC2.class:?]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_51]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_51]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_51]
	at java.lang.reflect.Method.invoke(Method.java:497) ~[?:1.8.0_51]
	at cpw.mods.fml.common.FMLModContainer.handleModStateEvent(FMLModContainer.java:532) [FMLModContainer.class:?]
	at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) ~[?:?]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_51]
	at java.lang.reflect.Method.invoke(Method.java:497) ~[?:1.8.0_51]
	at com.google.common.eventbus.EventSubscriber.handleEvent(EventSubscriber.java:74) [guava-17.0.jar:?]
	at com.google.common.eventbus.SynchronizedEventSubscriber.handleEvent(SynchronizedEventSubscriber.java:47) [guava-17.0.jar:?]
	at com.google.common.eventbus.EventBus.dispatch(EventBus.java:322) [guava-17.0.jar:?]
	at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:304) [guava-17.0.jar:?]
	at com.google.common.eventbus.EventBus.post(EventBus.java:275) [guava-17.0.jar:?]
	at cpw.mods.fml.common.LoadController.sendEventToModContainer(LoadController.java:212) [LoadController.class:?]
	at cpw.mods.fml.common.LoadController.propogateStateMessage(LoadController.java:190) [LoadController.class:?]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_51]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_51]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_51]
	at java.lang.reflect.Method.invoke(Method.java:497) ~[?:1.8.0_51]
	at com.google.common.eventbus.EventSubscriber.handleEvent(EventSubscriber.java:74) [guava-17.0.jar:?]
	at com.google.common.eventbus.SynchronizedEventSubscriber.handleEvent(SynchronizedEventSubscriber.java:47) [guava-17.0.jar:?]
	at com.google.common.eventbus.EventBus.dispatch(EventBus.java:322) [guava-17.0.jar:?]
	at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:304) [guava-17.0.jar:?]
	at com.google.common.eventbus.EventBus.post(EventBus.java:275) [guava-17.0.jar:?]
	at cpw.mods.fml.common.LoadController.distributeStateMessage(LoadController.java:119) [LoadController.class:?]
	at cpw.mods.fml.common.Loader.initializeMods(Loader.java:742) [Loader.class:?]
	at cpw.mods.fml.client.FMLClientHandler.finishMinecraftLoading(FMLClientHandler.java:311) [FMLClientHandler.class:?]
	at net.minecraft.client.Minecraft.func_71384_a(Minecraft.java:552) [bao.class:?]
	at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:878) [bao.class:?]
	at net.minecraft.client.main.Main.main(SourceFile:148) [Main.class:?]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_51]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_51]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_51]
	at java.lang.reflect.Method.invoke(Method.java:497) ~[?:1.8.0_51]
	at net.minecraft.launchwrapper.Launch.launch(Launch.java:135) [launchwrapper-1.12.jar:?]
	at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.12.jar:?]

Minecraft Version: 1.12.2
Forge Version: 14.23.2.2654

I highly doubt anyone’s going to resolve this issue before Minecraft 1.15, but everyone I’ve spoken to about it says they have to deal with fixing the same issue on their projects and that it’s worth a shot.

So here’s the situation:
Say you have a mod where you want to add a custom block with the same behaviour as minecraft:snow_layer (a block with 8 layers that increases every time you right-click with that block’s item).

The obvious solution is to extend BlockSnow and use the ItemSnow as the item, expecting it should just work.

The block works fine, but here’s the issue: The item doesn’t. Every time you try to place the block down, you can right-click it once to get to 2 layers, and then it stops increasing.

What’s expected is that it would continue to increase to a full block, as per vanilla behaviour.

After some debugging and looking through the code, I eventuallt found the issue:
ItemSnow.java

public boolean canPlaceBlockOnSide(World world, BlockPos pos, EnumFacing side, EntityPlayer player, ItemStack stack)
{
    IBlockState state = world.getBlockState(pos);
    return (state.getBlock() != net.minecraft.init.Blocks.SNOW_LAYER || ((Integer)state.getValue(BlockSnow.LAYERS)) > 7) ? super.canPlaceBlockOnSide(world, pos, side, player, stack) : true;
}

Specifically, this part:

state.getBlock() != net.minecraft.init.Blocks.SNOW_LAYER || 

This is wrong, and judging by how the Blocks class is fully qualified, I’m led to believe this is not a vanilla issue, but some change that’s been brought in with forge’s patches.

What I ended up having to do is extend that class, and specifically undo the change (as best I can):

    @Override
public boolean canPlaceBlockOnSide(World world, BlockPos pos, EnumFacing side, EntityPlayer player, ItemStack stack) {
    IBlockState state = world.getBlockState(pos);

    // Check explicitly for the maximum layers.
    // Without this layered blocks get stuck on the second layer because of a change introduced with Forge's patches.
    if (state.getBlock() instanceof BlockSnow && state.getValue(BlockSnow.LAYERS) < 8) {
        return true;
    }

    // return (state.getBlock() != net.minecraft.init.Blocks.SNOW_LAYER || ((Integer)state.getValue(BlockSnow.LAYERS)) > 7) ? super.canPlaceBlockOnSide(world, pos, side, player, stack) : true;
    return super.canPlaceBlockOnSide(world, pos, side, player, stack);
}

And that works as expected.

You can draw your own conclusions from this, but my belief is that forge should not have touched that method in the first place.

#1

#2

Cyxapuk