There's no reason to use either BlockContainer or ITileEntityProvider, these both give you the metadata instead of the IBlockState. What you should do is override Block#hasTileEntity(IBlockState) and Block#createTileEntity instead, these give you the IBlockState.
You should create a single IWorldGenerator that generates all of your ores (with a WorldGenMinable for each one). In the IWorldGenerator#generate implementation, decide which ores the chunk should contain and then generate those ores.
Why? I mean yeah using a hack like this is not good and unacceptable in any way because it works only because of the collective effort of every mod that uses it. But removed? No! Even minecraft needs it because of limitations of jsons!
A replacement/rework/redesign is needed, not a removal in my opinion.
I suspect it's because Forge expects people to use the baked model system instead of a per-frame renderer. You can suggest a replacement, but I doubt any form of IItemRenderer will be coming back.
You don't have to use JSON models, you can use OBJ/B3D or generate your model at runtime.
This will either be very difficult or simply not possible.
Items are only rendered using the baked model system, but entity renderers have full access to OpenGL. If you limit this to living entities, you may be able to get the entity's main model from RenderLivingBase#getMainModel and convert each ModelRenderer to a series of BakedQuads. This won't include any extra models, layers or effects that the entity would be rendered with.
You can register a TileEntitySpecialRenderer for an Item for full access to OpenGL, but this is deprecated and will removed as soon as possible.
Access the IBaublesItemHandlercapability from an EntityPlayer.
You can either use the Capability instance stored in the BaublesCapabilities.CAPABILITY_BAUBLES field or use the @CapabiltiyInject annotation on your own field/method.
Run it again with the --info command-line option and post the full output using Gist or Pastebin. Also post the version of Forge and the MCP mappings you're using (or your entire build.gradle and gradle.properties files).
The main change is that temStacks are no longer allowed to be null, the default value is now the empty ItemStack (ItemStack.EMPTY). Use ItemStack#isEmpty instead of checking if an ItemStack is null. Use a NonNullList rather than an array/ArrayList whenever you need a collection of ItemStacks.
Along with this change, most Item/Block interaction methods (e.g. Item#onItemRightClick, Block#onBlockActivated) no longer receive an ItemStack argument. Instead, they receive an EnumHand argument and use the ItemStack held in that hand.
Another major change is that ResourceLocation converts its path component to lowercase, so all resource file names must be lowercase.
You can see the changes I made to my mod during the initial 1.11 update here. You can see all the changed I've made in 1.11 here.
So I've have tried many times to install the forge workspace, with no luck. I do the whole ".//gradlew setupDecompWorkspace" command, but it always runs into the same error (I have added an image of the error).
Does anyone know why this happens? If so, is there a fix?
Oh also, Im on a mac.
Thanks,
Set3
Make sure you're running the setupDecompWorkspace task, not setup or setup DecompWorkspace.
For the record, that was posted before EntityRegistry had been fixed for 1.11. diesieben07 also mentions later in the thread that entities can be registered now.
Thanks @Choonster, guess I let my coding standards slip during my frustration... I should have also explained that the Block does need to implement ITileEntityProvider because it will have a TileEntity.
There's no reason to use BlockContainer or ITileEntityProvider, any Block can have a TileEntity if it overrides Block#hasTileEntity(IBlockState) and Block#createTileEntity.
There's also no reason to override a method (e.g. Block#getRenderType) if you're going to return the same value as the super method (e.g. EnumBlockRenderType.MODEL). The override was necessary when you were extending BlockContainer, but it's not now that you're extending Block.
Block#onBlockPlaced has been deprecated in favour of Block#getStateForPlacement.
I (think) I have implemented your suggestions, however the issue still remains. Any further assistance would be greatly appreciated! The links to the files in the OP should still work and be relevant.
[21:13:00] [Client thread/ERROR] [FML]: Exception loading model for variant plutomc_core:alloy_furnace#burning=false,facing=west for blockstate "plutomc_core:alloy_furnace[burning=false,facing=west]"
net.minecraftforge.client.model.ModelLoaderRegistry$LoaderException: Exception loading model plutomc_core:alloy_furnace#burning=false,facing=west with loader VariantLoader.INSTANCE, skipping
...
Caused by: net.minecraft.client.renderer.block.model.ModelBlockDefinition$MissingVariantException
"burning=false,facing=north" isn't the same as "facing=north,burning=false". Each variant in the blockstates file must match the variant that Minecraft looks for exactly (properties in alphabetical order, all lowercase).
You can also use Forge's blockstates format, which allows you to specify the effect of each property value on the model instead of specifying the model for every possible combination of property values.
0
There's no reason to use either BlockContainer or ITileEntityProvider, these both give you the metadata instead of the IBlockState. What you should do is override Block#hasTileEntity(IBlockState) and Block#createTileEntity instead, these give you the IBlockState.
1
You should create a single IWorldGenerator that generates all of your ores (with a WorldGenMinable for each one). In the IWorldGenerator#generate implementation, decide which ores the chunk should contain and then generate those ores.
0
It didn't change. If it's not working, you've done something wrong.
If you want more help post your code (using Gist/Pastebin or GitHub) and describe exactly what's not working.
0
You can suggest anything you want, but I'm not saying that it will be accepted; that's obviously up to the Forge team to decide.
0
I suspect it's because Forge expects people to use the baked model system instead of a per-frame renderer. You can suggest a replacement, but I doubt any form of IItemRenderer will be coming back.
You don't have to use JSON models, you can use OBJ/B3D or generate your model at runtime.
0
This will either be very difficult or simply not possible.
Items are only rendered using the baked model system, but entity renderers have full access to OpenGL. If you limit this to living entities, you may be able to get the entity's main model from RenderLivingBase#getMainModel and convert each ModelRenderer to a series of BakedQuads. This won't include any extra models, layers or effects that the entity would be rendered with.
You can register a TileEntitySpecialRenderer for an Item for full access to OpenGL, but this is deprecated and will removed as soon as possible.
0
Access the IBaublesItemHandler capability from an EntityPlayer.
You can either use the Capability instance stored in the BaublesCapabilities.CAPABILITY_BAUBLES field or use the @CapabiltiyInject annotation on your own field/method.
0
Run it again with the --info command-line option and post the full output using Gist or Pastebin. Also post the version of Forge and the MCP mappings you're using (or your entire build.gradle and gradle.properties files).
0
The main change is that temStacks are no longer allowed to be null, the default value is now the empty ItemStack (ItemStack.EMPTY). Use ItemStack#isEmpty instead of checking if an ItemStack is null. Use a NonNullList rather than an array/ArrayList whenever you need a collection of ItemStacks.
Along with this change, most Item/Block interaction methods (e.g. Item#onItemRightClick, Block#onBlockActivated) no longer receive an ItemStack argument. Instead, they receive an EnumHand argument and use the ItemStack held in that hand.
Another major change is that ResourceLocation converts its path component to lowercase, so all resource file names must be lowercase.
You can see the changes I made to my mod during the initial 1.11 update here. You can see all the changed I've made in 1.11 here.
0
There isn't. You may be able to insert a handler somewhere in the Netty stack, but it probably won't be easy.
What are you actually trying to achieve? There may be a better way than messing with packets directly.
0
http://www.minecraftforge.net/forum/index.php?topic=43330.msg231436#msg231436
0
Make sure you're running the setupDecompWorkspace task, not setup or setup DecompWorkspace.
setupDevWorkspace still exists in 1.11, but it's usually not the task you want to use.
0
For the record, that was posted before EntityRegistry had been fixed for 1.11. diesieben07 also mentions later in the thread that entities can be registered now.
0
If you want a page changed, you can submit a pull request to Forge's documentation on GitHub.
1
There's no reason to use BlockContainer or ITileEntityProvider, any Block can have a TileEntity if it overrides Block#hasTileEntity(IBlockState) and Block#createTileEntity.
There's also no reason to override a method (e.g. Block#getRenderType) if you're going to return the same value as the super method (e.g. EnumBlockRenderType.MODEL). The override was necessary when you were extending BlockContainer, but it's not now that you're extending Block.
Block#onBlockPlaced has been deprecated in favour of Block#getStateForPlacement.
"burning=false,facing=north" isn't the same as "facing=north,burning=false". Each variant in the blockstates file must match the variant that Minecraft looks for exactly (properties in alphabetical order, all lowercase).
You can also use Forge's blockstates format, which allows you to specify the effect of each property value on the model instead of specifying the model for every possible combination of property values.