[1.12.1] Client crash when interacting with scanables
JustJinxed opened this issue ยท 9 comments
Description
re: MightyPirates/BedrockOres#36
(DE is using a world.getBlockState instead of using the passed in state param.)
When using scanables block detection module on Draconic Ore, client crashes with a block state not found error.
I realize this is an interface issue and the failure from the error log is within Scannable itself, but fnuecke seems to think it has something to do with how DE chooses to set or gather block state information. (I'm not a wiz about state code, so please excuse me if I'm murdering the terminology)
Wasn't sure if you got the notification from his repo comment, or if he contacted you directly. Advanced apologies if this is already a known issue. (or if it's already been fixed, I see there's a newer version out)
Base information
- Minecraft version: 1.12.1
- Minecraft Forge version: 2469
- Mod Pack: None
- DE Version: 1.12-2.3.3.261
Crash report
Description: Rendering screen
java.lang.IllegalArgumentException: Cannot get property PropertyEnum{name=type, clazz=class com.brandon3055.draconicevolution.blocks.DraconiumOre$EnumType, values=[NORMAL, NETHER, END]} as it does not exist in BlockStateContainer{block=minecraft:air, properties=[]}
at net.minecraft.block.state.BlockStateContainer$StateImplementation.func_177229_b(BlockStateContainer.java:209)
at com.brandon3055.draconicevolution.blocks.DraconiumOre.getPickBlock(DraconiumOre.java:75)
at li.cil.scannable.common.item.ItemScannerModuleBlockConfigurable.getItemStackFromState(ItemScannerModuleBlockConfigurable.java:132)
at li.cil.scannable.common.item.ItemScannerModuleBlockConfigurable.func_77624_a(ItemScannerModuleBlockConfigurable.java:88)
at net.minecraft.item.ItemStack.func_82840_a(ItemStack.java:707)
at net.minecraft.client.gui.GuiScreen.func_191927_a(GuiScreen.java:143)
at net.minecraft.client.gui.GuiScreen.func_146285_a(GuiScreen.java:137)
at net.minecraft.client.gui.inventory.GuiContainer.func_191948_b(GuiContainer.java:175)
at net.minecraft.client.gui.inventory.GuiInventory.func_73863_a(SourceFile:79)
at net.minecraftforge.client.ForgeHooksClient.drawScreen(ForgeHooksClient.java:349)
at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at Reflector.callVoid(Reflector.java:549)
at net.minecraft.client.renderer.EntityRenderer.func_181560_a(EntityRenderer.java:1433)
at net.minecraft.client.Minecraft.func_71411_J(Minecraft.java:1117)
at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:397)
at net.minecraft.client.main.Main.main(SourceFile:123)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at net.minecraft.launchwrapper.Launch.launch(Launch.java:135)
at net.minecraft.launchwrapper.Launch.main(Launch.java:28)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.multimc.onesix.OneSixLauncher.launchWithMainClass(OneSixLauncher.java:236)
at org.multimc.onesix.OneSixLauncher.launch(OneSixLauncher.java:297)
at org.multimc.EntryPoint.listen(EntryPoint.java:162)
at org.multimc.EntryPoint.main(EntryPoint.java:53)
Heya, just to add to the above, while I acknowledge that this is basically my problem, it'd be very nice if this could be fixed by DE playing nice in getPickBlock; other mods would potentially benefit from this, too :-)
(By "playing nice" I mean using the passed-in block state instead of fetching it again; also better performance-wise.)
Alternatively, If that's not possible for technical reasons, I'm now trying to look up the item stack for a block via Item.getItemFromBlock + Block.damageDropped. However, that also doesn't work for anything but the first ore subtype, because damageDropped appears not to be implemented (always returns 0)? I'm validating those values by checking Item.getMetadata + Block.getStateFromMeta against the original block state. FTR, I've not used this approach originally (and won't over getPickBlock) because from my experience almost nobody implements these (correctly/as you'd expect).
I have no idea what you are doing but it is invalid to ask the block for its pick block and NOT provide the actual location of the block, that is trivial. Waila and TOP both handle this fine.
I'm doing black magic*, hence me acknowledging that it's kinda problem ;-) It'd just be nice not having to add special cases, in particular if there's no need to (and there isn't from what I can tell, but I might be missing something).
FWIW, I don't think this invalidates the point that it'd be good if the ores would properly implement damageDropped, and items getMetadata, no?
*) Bedrock Ores wraps other block states; so in the world the block state is that of the bedrock ore block, but most behavior is simply forwarded to the wrapped block. Think Carpenter's Blocks. So in this case, when getPickBlock is called, the actual block state in the world is that of the bedrock ore, but what I want to return is what the wrapped state would return if it were the one in the world instead.
I could fix this in DE but there is really no point because this will also crash with countless other mods that do the same thing. You can not fire getPickBlock without giving it the world and position.
Asking mods to make this change is like asking mods to stop using the world passed into onBlockActivated because you have some special case code that breaks because you are calling onBlockActivated with a null world.
Yes, I'm already catching that now, however I still stand by
FWIW, I don't think this invalidates the point that it'd be good if the ores would properly implement damageDropped, and items getMetadata, no?
Is there a reason not to implement damageDropped to not return 0 but the actual meta of the corresponding stack?
Damage dropped should be 0 block does not drop itself it drops a dist item who's meta is always 0. If you need the damage value for the block itself you can already get that using getMetaFromState.
block does not drop itself it drops a dist item who's meta is always 0
Are we talking about the same thing here? Ores clearly drop a shared item with varying item damage, as also evident in their getPickBlock.
I know that it's common to just have a 1-to-1 mapping of block meta to item damage (or item meta if you'd like to call it that, though I find that misleading because ItemStack.getMetadata can be overridden to mean something completely arbitrary). But I'd rather not rely on that when there's a vanilla API for mapping block meta to item damage and vice versa, those namely being Block.damageDropped and ItemStack.getMetadata. The latter of which having a sensible default implementation, returning the item damage, the former sadly not.
Unless I'm misunderstanding something here, but seeing as vanilla uses it this way, too (in BlockPlanks for example), I don't think I am? Sorry for bringing this back up, but I'd very much like to sort this out, in particular if I'm misinterpreting a vanilla mechanic here :)
Ahhhh, that's where the misunderstanding comes from. All right then. Thanks for taking the time to clear this up, I'll see what I'll do about it then.