Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ClassCastException: newBiospheresMod.BlockDome cannot be cast to net.minecraft.block.BlockAnvil #15

Open
TheLoneWolfling opened this issue Apr 13, 2015 · 5 comments · May be fixed by #27

Comments

@TheLoneWolfling
Copy link
Contributor

java.lang.ClassCastException: newBiospheresMod.BlockDome cannot be cast to net.minecraft.block.BlockAnvil
  at net.minecraft.client.renderer.RenderBlocks.func_147800_a(RenderBlocks.java:8083)
  at net.minecraft.client.renderer.entity.RenderItem.renderItemIntoGUI(RenderItem.java:446)
  at net.minecraft.client.renderer.entity.RenderItem.func_82406_b(RenderItem.java:565)
  at net.minecraft.client.gui.inventory.GuiContainer.func_146977_a(GuiContainer.java:271)
  at net.minecraft.client.gui.inventory.GuiContainer.func_73863_a(GuiContainer.java:99)
  at net.minecraft.client.renderer.InventoryEffectRenderer.func_73863_a(InventoryEffectRenderer.java:38)
  at net.minecraft.client.gui.inventory.GuiContainerCreative.func_73863_a(GuiContainerCreative.java:638)
  at net.minecraft.client.renderer.EntityRenderer.func_78480_b(EntityRenderer.java:1061)
  at net.minecraft.client.Minecraft.func_71411_J(Minecraft.java:989)
  at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:887)
  at net.minecraft.client.main.Main.main(SourceFile:148)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
  at java.lang.reflect.Method.invoke(Unknown Source)
  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(Unknown Source)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
  at java.lang.reflect.Method.invoke(Unknown Source)
  at org.multimc.onesix.OneSixLauncher.launchWithMainClass(OneSixLauncher.java:286)
  at org.multimc.onesix.OneSixLauncher.launch(OneSixLauncher.java:376)
  at org.multimc.EntryPoint.listen(EntryPoint.java:165)
  at org.multimc.EntryPoint.main(EntryPoint.java:54)

Happens every time I search for an anvil in the creative menu with 0.85.

@BrainSlugs83
Copy link
Owner

Ooh. Ouch. Will make this a high priority fix.

@BrainSlugs83
Copy link
Owner

Should be fixed in latest -- didn't remove the block dome yet -- but for now, I made it just so that anvil isn't a valid blockdome (if you try to use it, it will just use the regular anvil block instead).

@TheLoneWolfling
Copy link
Contributor Author

This hack does not fix the issue for any other (i.e. mod) blocks that use custom renderers and (rightfully) assume that if they're being called to render a block it's the type of block they executed to render.

I'm also wondering about hoppers,

A better method would be to have a config option to enable / disable BlockDome for a given block.

Alternatively, designate your own rendering handler (an instance of ISimpleBlockRenderingHandler), that tries to call the delegated handler, with a fallback.

I may do up a pull request that does exactly this.

@TheLoneWolfling TheLoneWolfling linked a pull request Apr 22, 2015 that will close this issue
@BrainSlugs83
Copy link
Owner

Still haven't had a chance to look at that pull request (will take a look this weekend). -- Doesn't the current BlockDome class call the original class (for things like material and renderer) and return them properly?

It seems like this is a lot of extra work that we're doing manually where we should just be letting the original class handle it itself.

Also, I was thinking about the race-condition solution you mentioned before (i.e. set the block to the correct one, before calling the original method, then setting it back to the BlockDome in a finally/etc. before returning).

What if -- instead of that -- we just passed in a different IWorld object -- one that just wrapped the actual IWorld object for all interface calls, except for getBlock (or whatever it's named) -- where if the object was a BlockDome -- we pass back the BlockDome's imitated object instead -- then when we call those methods, and they check the type of the current block (via our passed in IWorld object) or try to perform a cast, etc. -- they behave correctly.

It still wouldn't work for server / client (since you need extra blocks), but it's a thought.

@BrainSlugs83 BrainSlugs83 reopened this May 1, 2015
@BrainSlugs83
Copy link
Owner

(Re-opening this -- thought it was open. -- since I haven't done the pull request yet.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants