Destroying Gas Pump crashes the game
Opened this issue · 14 comments
Please read the FAQ before submitting a bug report!
Bug description
Destroying the Gas Pump two-high block causes the top to break, but the moment the game attempts to break its second half, the game crashes.
Steps to reproduce the issue
- Set down a gas pump.
- break it.
Expected behavior
The block should break without problems.
Log files
https://drive.google.com/file/d/1-pMPvmA_B2r5anz9V37X7V5MzwP8IsKC/view?usp=sharing
Versions
- Minecraft version 1.16.2
- Forge version 33.0.22+
- Mod version 1.0.3
Other mods
Too many to list. However, the classpath pathtrace in the error log does not indicate external mod interference. Might this be an optifine collision?
This is a known issue in combination with OptiFine. Please report this error on the OptiFine issue tracker.
Actually, I'm fairly sure you can fix this yourself. You see, this issue is because you don't delete the text that resides at the top of the gas station before deleting the block itself. I can destroy the gas station from the bottom up just fine, but from the top down, it crashes. All other mods that have two-block-tall blocks can be destroyed just fine and they do not have text on the top half of the block.
Try adding it to your code where the text box object gets destroyed before the rest of the block (I notice the text kinda floats there if I break from the top down, which results in the game crash, as if optifine can no longer reference the text box to destroy it.)
I don't exactly know what you mean with text object. If you know the cause of the problem you can send me a permalink of the piece of code you mean.
The gas station has a visual text box similar to a sign that renders on the top half of the block. This text does not disappear if the top half of the block gets destroyed, which results in optifine losing track of the text box which causes the crash. However, if I destroy the block from the bottom up, the text disappears before the top half gets destroyed.
This means that the crash is caused by your code not destroying the text (usually it says stuff like "No car" on it) before the block gets destroyed. The text should be destroyed first before the block (this is the same for signs). I will search your code for the code that isn't doing this as well as attach a screenshot
See here how the text does not disappear/get destroyed? it should always be destroyed first, not the block.
I think you don't understand how text rendering works. The text is actually rendered by the bottom block. It the bottom block is there, the text is also there. There is no such thing as a text object that holds the text. It is just rendering code of the bottom block (Same used for chests, shulkerboxes, signs, banners etc.).
There is also no "keeping track" of text objects.
But maybe I am understanding you wrong. Let me know if you find something.
Then why is it that other mods can handle the same dual-block style with optifine whilst yours cannot? maybe it's a good idea to peek at another mod's dual-block code?
Every mod has its own multi block code. This one is really unique as it is a rotatable block that has a special renderer as well as a normal block model, is rotatable, has a GUI, is interactable and has a fluid interface.
I have notified optifine of the issue and will pass any messages along as necessary (although I still have reason to believe optifine is not at fault, even though their rendering code is included in the path trace)
I am pretty sure there is some mistake somewhere in my code, but the problem is, that I cant find out the problem if I don't have access to their source code.
Don't get your hopes too high on the optifine issue. I also reported some issues to them, and it seems they don't care about problems with other mods or forge in general.
With further investigation, I have a suspicion about fixTop(). Considering you do this every tick in the bottom block class of the gas station, this could cause the state of the top block to return null whilst it is being destroyed, causing fixTop to panic and cause this crash. since destroying the bottom block disables this code, this could explain why it does not crash when the gas station is destroyed bottom-up
if (world.getGameTime() % 100 == 0) {
fixTop();
}
why perform this every tick if the block gets oriented upon placement? it's not like it can suddenly change orientation after it is placed.
in fact, the debug log seems to say that is the issue. when top disappears before the bottom, your code panics over a null reference to it.
again, other modded two-high blocks do not experience this, this is an issue tied specifically to your mod and yours alone.
The fixTop() is used to re-add the top when upgrading from an older version, as earlier versions just used the bottom part of the gas station.
But this should not impact anything as I am checking if the top block is actually a gas station block:
And block states should never return null. It is always minecraft:air if there is no block.
in fact, the debug log seems to say that is the issue. when top disappears before the bottom, your code panics over a null reference to it.
This stack trace doesn't directly reference any of my classes. It seems that this problem is a little bit more complicated than that. Not only because the issue only occurs in combination with optifine.
But because optifine is closed source, I can't look into their code to see whats going on there.
java.lang.NullPointerException: Unexpected error
at net.minecraft.client.renderer.tileentity.TileEntityRendererDispatcher.func_228850_a_(TileEntityRendererDispatcher.java:97) ~[?:?] {re:classloading,pl:accesstransformer:B,xf:OptiFine:default,xf:Vivecraft:default}
at net.minecraft.client.renderer.WorldRenderer.func_228426_a_(WorldRenderer.java:1801) ~[?:?] {re:classloading,pl:accesstransformer:B,xf:OptiFine:default,xf:Vivecraft:default}
at net.minecraft.client.renderer.GameRenderer.func_228378_a_(GameRenderer.java:1022) ~[?:?] {re:classloading,pl:accesstransformer:B,xf:OptiFine:default,xf:Vivecraft:default}
at net.minecraft.client.renderer.GameRenderer.func_195458_a(GameRenderer.java:693) ~[?:?] {re:classloading,pl:accesstransformer:B,xf:OptiFine:default,xf:Vivecraft:default}
at net.minecraft.client.Minecraft.func_195542_b(Minecraft.java:1218) ~[?:?] {re:classloading,pl:accesstransformer:B,xf:Vivecraft:default}
at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:723) ~[?:?] {re:classloading,pl:accesstransformer:B,xf:Vivecraft:default}
at net.minecraft.client.main.Main.main(Main.java:184) ~[1.16.2.jar:?] {re:classloading,pl:runtimedistcleaner:A}
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?] {}
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?] {}
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?] {}
at java.lang.reflect.Method.invoke(Method.java:564) ~[?:?] {}
at net.minecraftforge.fml.loading.FMLClientLaunchProvider.lambda$launchService$0(FMLClientLaunchProvider.java:51) ~[forge-1.16.2-33.0.32.jar:33.0] {}
at cpw.mods.modlauncher.LaunchServiceHandlerDecorator.launch(LaunchServiceHandlerDecorator.java:37) [modlauncher-6.1.1.jar:?] {}
at cpw.mods.modlauncher.LaunchServiceHandler.launch(LaunchServiceHandler.java:54) [modlauncher-6.1.1.jar:?] {}
at cpw.mods.modlauncher.LaunchServiceHandler.launch(LaunchServiceHandler.java:72) [modlauncher-6.1.1.jar:?] {}
at cpw.mods.modlauncher.Launcher.run(Launcher.java:81) [modlauncher-6.1.1.jar:?] {}
at cpw.mods.modlauncher.Launcher.main(Launcher.java:65) [modlauncher-6.1.1.jar:?] {}
And as you see in your logs: pl:accesstransformer:B,xf:OptiFine:default
There is definitely optifine involved.
Then why is it that other mods can handle the same dual-block style with optifine whilst yours cannot? maybe it's a good idea to peek at another mod's dual-block code?
I have notified optifine of the issue and will pass any messages along as necessary (although I still have reason to believe optifine is not at fault, even though their rendering code is included in the path trace)