Ok. I've eliminated "miscellaneous." I've moved the GUI to the client side package. I've eliminated the "support code" package, and moved everything up one level. I removed ALL references to ForgeRegistries. However, NONE of my blocks is in game - and they were there before I removed ForgeRegistries. Obviously, there's a way to get them in game without ForgeRegistries, but I haven't figured it out yet.
Here's my code:
public static void registerBlocks(RegistryEvent.Register<Block> event)
{
glass_stairs = new Glass_Stairs("glass_stairs", Blocks.GLASS.getDefaultState());
event.getRegistry().register(glass_stairs);
blok = new Custom_Block("blok");
registerBlockWithVariants(blok, new ItemBlockVariants(blok));
compressor_idle = new Compressor("compressor_idle", 2.5F, 4.5F, false);
event.getRegistry().register(compressor_idle);
compressor_active = new Compressor("compressor_active", 2.5F, 4.5F, true);
event.getRegistry().register(compressor_active);
}
@SubscribeEvent
@SideOnly(Side.CLIENT)
public static void registerModels(ModelRegistryEvent event)
{
registerBlocks(glass_stairs);
registerBlocks(compressor_idle);
registerBlocks(compressor_active);
registerBlocks(blok);
for(int i = 0; i < EnumHandler.BlokTypes.values().length; i++)
{
registerRender(blok, i, "blok_" + EnumHandler.BlokTypes.values()[i].getName());
}
}
public static void registerBlocks(Block block)
{
ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(block), 0, new ModelResourceLocation(block.getRegistryName(), "inventory"));
}
private static void registerBlocks(Block block, int meta, String name)
{
ResourceLocation registryName = new ResourceLocation(Reference.MOD_ID, name);
ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(block), meta, new ModelResourceLocation(registryName, "inventory"));
}
public static void registerRender(Block block, int meta, String filename)
{
ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(block), meta, new ModelResourceLocation(new ResourceLocation(Reference.MOD_ID, filename), "inventory"));
}
public static void registerBlocks(Block block, ItemBlock itemblock)
{
itemblock.setRegistryName(block.getRegistryName());
ModelLoader.setCustomModelResourceLocation(itemblock, 0, new ModelResourceLocation(block.getRegistryName(), "inventory"));
}
public static void registerBlockWithVariants(Block block, ItemBlock itemblock)
{
itemblock.setRegistryName(block.getRegistryName());
ModelLoader.setCustomModelResourceLocation(itemblock, 0, new ModelResourceLocation(block.getRegistryName(), "inventory"));
}
Finally, I have an idle and active version of the compressor and combiner block because that's the way the furnace is initated in Vanilla. It has a furnace_active and a furnace_inactive (or whatever name they used) to hold the models (because it's a different model for the "on" version than the "off" version. Since these are essentially modified furnaces, I have the same.
I need a way to get block singletons into the game. I also need a way to get the blocks with subtypes into the game, and I need a way to get the compressor/combiner blocks into the game. In my version (which works), all three use some variation of ForgeRegistries. Please give me SOME kind of clue as to how to replace the code I've removed with code that will bring these blocks back.
1. The clue is to use the RegistryEvent. However, it seems that you're already doing that. Why are you so sure that your blocks aren't being registered? Perhaps you're not registering their ItemBlocks correctly. Show where and how you register their ItemBlocks.
2. I'd have states for idle and active blockstates instead of making separate blocks, but that's doesn't matter too much.
Understanding comes slowly, but at least it's coming. In the previous version, I was using ForgeRegistries.ITEMS.register(itemblock) in my registration functions to create the ItemBlock for each block. Now, I'm currently doing it within the Init_Items class; I'm not sure that's the best place, per se, but at least it's functioning... to a point.
I'm getting errors (posted at https://pastebin.com/TSyAL7Rw); also, my subitem blocks aren't working properly. The ore blocks are BOTH named tile.ore.name and the bloks are all named tile.blok.name - instead of the correct name, which appends _copper, _silver, etc. Obviously, these blocks aren't being dealt with correctly; I'm just not sure what to do to fix it... yet.
In the original, I called registerRenders() during the Init portion of my CommonProxy; this sets the subtype names. Then, during Init_Blocks, I call to the registerBlockWithVariants, which uses ForgeRegistries to register both the block and the ItemBlock.
Obviously, I'm not getting the subtype names. The code which USED to be in registerRenders is now inside the registerModels section, which is called in the Client_Event_Registry. The textures are right - it's just the names which aren't getting in there (they're correct in the lang file).
Just 'cause you said it doesn't mean I got it. You'd said a LOT of things it took me a while to understand. Sorry it took so long, but I'm progressing! Anyway, my code is now up at https://github.com/TheWebExpert1/newplants.
1. What exactly is your problem? What do you mean by "subitem blocks"? I only see you registering one ore block and one "blok" block. What do you mean by setting the subtype names?
2. If you look closely at the log you will that the errors are about missing item models.
Both the ore type and the blok type have multiple subtypes. These types are defined in the EnumHandler. Originally, the program called registerRenders() during the Init portion of my CommonProxy; this was setting the subtype names:
public static void registerRenders()
{
for(int i = 0; i < EnumHandler.BlokTypes.values().length; i++)
{
registerRender(blok, i, "blok_" + EnumHandler.BlokTypes.values()[i].getName());
}
for(int i = 0; i < EnumHandler.OreTypes.values().length; i++)
{
registerRender(ore, i, "ore_" + EnumHandler.OreTypes.values()[i].getName());
}
}
public static void registerRender(Block block, int meta, String filename)
{
ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(block), meta, new ModelResourceLocation(new ResourceLocation(Reference.MOD_ID, filename), "inventory"));
}
Then, during Init_Blocks, the program called registerBlockWithVariants, which used ForgeRegistries to register both the block and the ItemBlock:
Currently the code is as you see it in the github. For whatever reason, the program isn't adding the proper names to the blocks. The blocks should be ore_copper and ore_silver, not just ore. The reason the error is coming up is because there is no block called "ore." There's not supposed to be. Likewise, the program should be generating Beet Block, Bone Block, Ceramic Block, Copper Block, Crystal Block, Flint Block, Flower Bed Soil Block, Gourd Block, Hellstone Block, Honey Block, Honey Hex, Honeycomb, Powered Crystal Block, Silver Block and Steel Block - not just "blok."
The code WAS working properly (as far as having the blocks, in the world, with their proper names & textures). You said I should *NEVER* use ForgeRegistries; I'm taking you at your word - it's quite obvious that you know more about Java coding in general and Minecraft coding specifically than I do; I've learned a lot thus far from you. Having taken out the ForgeRegistries, and rearranged things so that the blocks are being initialized properly and so on, I just need the one "last" thing on this, which is to make the subtype blocks work properly again. The issue is that the names (registry names??) aren't being assigned.
I tried adding code similar to the "registerRenders" to the Init_Items section, where the ItemBlocks are being generated, but THAT was a mistake (unless there's a different way to do that). I need subtypes. I'm missing somethinghere, but I'm not sure what it is.
Can you explain why you're trying to create sub types for completely unrelated blocks? That's not what sub types are for. Having most of your blocks be a sub type can cause unwanted issues.
Obviously, ore_copper and ore_silver ARE related (they're both ores). I had a "custom block" class and figured it would be cool to do it as subtypes - rather than cluttering up the code with a dozen or so classes which were fundamentally identical. I'm still left with the question of how to fix this.
If you look at how vanilla does it you will see they have separate blocks for each ore. You don't need dozens of classes, just create a reusable class for basic blocks and instantiate it with different params for each block. Minecraft should treat sub types identically (if I'm not forgetting something) which can cause issues (think of all your sub blocks as different colored wool).
I guess I should do the same with my items, then; I simply made a "food" item and iterated through the Enums for it to register them all; the class is reusable, so I guess I should initialize & register them separately, rather than as "subtypes."
That's what I mean about moving things around to the line-by-line method. In one sense, the "enum" method was 'shorter' (just a simple loop to register everything) - but then, the code itself is actually longer (and more complicated). Sigh.
Ok, I have everything moved around - one class, multiple variations of the class, reusing it; however, I'm getting errors (posted at https://pastebin.com/BwCXsDBC). The updated code is posted at https://github.com/TheWebExpert1/newplants. I saw an error in one of the recipe files; that's been corrected, but I doubt that's the cause of the problem.
Also, before the error, I was having trouble with the double_slabs causing errors (they really shouldn't have ItemBlocks, as they're not supposed to render in the Inventory); plus, similar errors with the compressor_active and condenser_active models. Again, these were working in the prior version (done with ForgeRegistries), but are giving me problems now. Minecraft needs to be able to switch between the two "versions" of the blocks, so they both need to be registered as blocks, but they don't need to be items as well.
I'm not quite sure what's causing the error. Can you show the full log?
Also, here's a few tips for cleaner code:
1. As I said before, you do not need to call event.getRegistry.register every time, you can use event.getRegistry.registerAll which registers all entries passed into it. registerAll takes a varags param which means you can pass an unspecified amount of fields in.
2. You don't have to call setRegistryName on every instance of your items, easier to call it from a base class constructor. I usually set both the registry and unlocalized name to a string passed to the constructor (much like you're doing with your blocks).
Is this right?? I tried it, but got worse errors than before. I put back in the lines for the double_slab, so you could see what was happening in the errors.
1. I highly recommend using registerAll() as it's much cleaner. What you're doing looks correct, but why did you copy the code two times?
2. Again, why do you need so much useless code? Why do you have separate classes for the glass, end and wart slabs? Create reusable code. Also why do you have so many indetical methods in your blocks initialization class (registerBlocks, etc)?
3. You're not even creating slabs correctly. Look closely at the ItemSlab class.
4. It's really not hard to read a log. Usually the error is described by forge and you can see what code causes it in the stack trace.
5. As for the recipe, you're specifying an item that doesn't exist in one of your jsons.
1. I think I just pasted it 2x by accident in the topic window.
2. I had separate classes originally because I thought I had to - with the materials being different, different hardness, etc.; I found later that I could do the same by just passing parameters in. Yes, I know I can do it with reusable code. Again, it's something I already knew, but just hadn't gotten around to doing; I've been focusing on other things.
The "identical" methods in the blocks initialization were there originally to handle the different ways of registering blocks - i.e., singletons vs. sub-blocks; I just hadn't removed them.
3. You're probably right; my slabs are based entirely on a tutorial; I'll look again at the slab class & see what's different.
4. I read the log, but can't figure out what's causing the error.
5. The recipe: newmod:beet_block DOES exist... or it should. I've done all the initialization, registration, etc. the same as every other block. It existed properly before I made these changes; therefore, there shouldn't be any problems now.
I'll go ahead & make these changes, then repost the code, along with any errors.
Ok. I've eliminated "miscellaneous." I've moved the GUI to the client side package. I've eliminated the "support code" package, and moved everything up one level. I removed ALL references to ForgeRegistries. However, NONE of my blocks is in game - and they were there before I removed ForgeRegistries. Obviously, there's a way to get them in game without ForgeRegistries, but I haven't figured it out yet.
Here's my code:
Finally, I have an idle and active version of the compressor and combiner block because that's the way the furnace is initated in Vanilla. It has a furnace_active and a furnace_inactive (or whatever name they used) to hold the models (because it's a different model for the "on" version than the "off" version. Since these are essentially modified furnaces, I have the same.
I need a way to get block singletons into the game. I also need a way to get the blocks with subtypes into the game, and I need a way to get the compressor/combiner blocks into the game. In my version (which works), all three use some variation of ForgeRegistries. Please give me SOME kind of clue as to how to replace the code I've removed with code that will bring these blocks back.
1. The clue is to use the RegistryEvent. However, it seems that you're already doing that. Why are you so sure that your blocks aren't being registered? Perhaps you're not registering their ItemBlocks correctly. Show where and how you register their ItemBlocks.
2. I'd have states for idle and active blockstates instead of making separate blocks, but that's doesn't matter too much.
Understanding comes slowly, but at least it's coming. In the previous version, I was using ForgeRegistries.ITEMS.register(itemblock) in my registration functions to create the ItemBlock for each block. Now, I'm currently doing it within the Init_Items class; I'm not sure that's the best place, per se, but at least it's functioning... to a point.
I'm getting errors (posted at https://pastebin.com/TSyAL7Rw); also, my subitem blocks aren't working properly. The ore blocks are BOTH named tile.ore.name and the bloks are all named tile.blok.name - instead of the correct name, which appends _copper, _silver, etc. Obviously, these blocks aren't being dealt with correctly; I'm just not sure what to do to fix it... yet.
In the original, I called registerRenders() during the Init portion of my CommonProxy; this sets the subtype names. Then, during Init_Blocks, I call to the registerBlockWithVariants, which uses ForgeRegistries to register both the block and the ItemBlock.
Obviously, I'm not getting the subtype names. The code which USED to be in registerRenders is now inside the registerModels section, which is called in the Client_Event_Registry. The textures are right - it's just the names which aren't getting in there (they're correct in the lang file).
1. I told you in post #36 how I register ItemBlocks. Not sure why you took so long to understand.
2. I can't help you much without code/updated repo.
Just 'cause you said it doesn't mean I got it. You'd said a LOT of things it took me a while to understand. Sorry it took so long, but I'm progressing! Anyway, my code is now up at https://github.com/TheWebExpert1/newplants.
1. What exactly is your problem? What do you mean by "subitem blocks"? I only see you registering one ore block and one "blok" block. What do you mean by setting the subtype names?
2. If you look closely at the log you will that the errors are about missing item models.
Both the ore type and the blok type have multiple subtypes. These types are defined in the EnumHandler. Originally, the program called registerRenders() during the Init portion of my CommonProxy; this was setting the subtype names:
Then, during Init_Blocks, the program called registerBlockWithVariants, which used ForgeRegistries to register both the block and the ItemBlock:
Currently the code is as you see it in the github. For whatever reason, the program isn't adding the proper names to the blocks. The blocks should be ore_copper and ore_silver, not just ore. The reason the error is coming up is because there is no block called "ore." There's not supposed to be. Likewise, the program should be generating Beet Block, Bone Block, Ceramic Block, Copper Block, Crystal Block, Flint Block, Flower Bed Soil Block, Gourd Block, Hellstone Block, Honey Block, Honey Hex, Honeycomb, Powered Crystal Block, Silver Block and Steel Block - not just "blok."
The code WAS working properly (as far as having the blocks, in the world, with their proper names & textures). You said I should *NEVER* use ForgeRegistries; I'm taking you at your word - it's quite obvious that you know more about Java coding in general and Minecraft coding specifically than I do; I've learned a lot thus far from you. Having taken out the ForgeRegistries, and rearranged things so that the blocks are being initialized properly and so on, I just need the one "last" thing on this, which is to make the subtype blocks work properly again. The issue is that the names (registry names??) aren't being assigned.
I tried adding code similar to the "registerRenders" to the Init_Items section, where the ItemBlocks are being generated, but THAT was a mistake (unless there's a different way to do that). I need subtypes. I'm missing something here, but I'm not sure what it is.
Can you explain why you're trying to create sub types for completely unrelated blocks? That's not what sub types are for. Having most of your blocks be a sub type can cause unwanted issues.
Obviously, ore_copper and ore_silver ARE related (they're both ores). I had a "custom block" class and figured it would be cool to do it as subtypes - rather than cluttering up the code with a dozen or so classes which were fundamentally identical. I'm still left with the question of how to fix this.
If you look at how vanilla does it you will see they have separate blocks for each ore. You don't need dozens of classes, just create a reusable class for basic blocks and instantiate it with different params for each block. Minecraft should treat sub types identically (if I'm not forgetting something) which can cause issues (think of all your sub blocks as different colored wool).
I guess I should do the same with my items, then; I simply made a "food" item and iterated through the Enums for it to register them all; the class is reusable, so I guess I should initialize & register them separately, rather than as "subtypes."
Why do you need so much useless code? You don't need any enums when you can simply initialize the item in one line and register it.
That's what I mean about moving things around to the line-by-line method. In one sense, the "enum" method was 'shorter' (just a simple loop to register everything) - but then, the code itself is actually longer (and more complicated). Sigh.
Ok, I have everything moved around - one class, multiple variations of the class, reusing it; however, I'm getting errors (posted at https://pastebin.com/BwCXsDBC). The updated code is posted at https://github.com/TheWebExpert1/newplants. I saw an error in one of the recipe files; that's been corrected, but I doubt that's the cause of the problem.
Also, before the error, I was having trouble with the double_slabs causing errors (they really shouldn't have ItemBlocks, as they're not supposed to render in the Inventory); plus, similar errors with the compressor_active and condenser_active models. Again, these were working in the prior version (done with ForgeRegistries), but are giving me problems now. Minecraft needs to be able to switch between the two "versions" of the blocks, so they both need to be registered as blocks, but they don't need to be items as well.
I'm not quite sure what's causing the error. Can you show the full log?
Also, here's a few tips for cleaner code:
1. As I said before, you do not need to call event.getRegistry.register every time, you can use event.getRegistry.registerAll which registers all entries passed into it. registerAll takes a varags param which means you can pass an unspecified amount of fields in.
2. You don't have to call setRegistryName on every instance of your items, easier to call it from a base class constructor. I usually set both the registry and unlocalized name to a string passed to the constructor (much like you're doing with your blocks).
I know about the setRegistryName; it's something I meant to do, but hadn't gotten around to changing yet.
event.getRegistry().registerAll(glass_stairs, endbrick_stairs, nether_wart_block_stairs, glass_half_slab, endbrick_half_slab, nether_wart_block_half_slab, combiner_idle, combiner_active, compressor_idle, compressor_active, ore_copper, ore_silver, beet_block, ceramic_block, copper_block, crystal_block, flint_block, flower_bed_soil_block, gourd_block, hellstone_block, honey_block, honey_hex_block, honeycomb_block, powered_crystal_block, silver_block, steel_block); event.getRegistry().registerAll(glass_stairs, endbrick_stairs, nether_wart_block_stairs, glass_half_slab, endbrick_half_slab, nether_wart_block_half_slab, combiner_idle, combiner_active, compressor_idle, compressor_active, ore_copper, ore_silver, beet_block, ceramic_block, copper_block, crystal_block, flint_block, flower_bed_soil_block, gourd_block, hellstone_block, honey_block, honey_hex_block, honeycomb_block, powered_crystal_block, silver_block, steel_block);
Is this right?? I tried it, but got worse errors than before. I put back in the lines for the double_slab, so you could see what was happening in the errors.
I have the paste at https://pastebin.com/k77xUDvm.
1. I highly recommend using registerAll() as it's much cleaner. What you're doing looks correct, but why did you copy the code two times?
2. Again, why do you need so much useless code? Why do you have separate classes for the glass, end and wart slabs? Create reusable code. Also why do you have so many indetical methods in your blocks initialization class (registerBlocks, etc)?
3. You're not even creating slabs correctly. Look closely at the ItemSlab class.
4. It's really not hard to read a log. Usually the error is described by forge and you can see what code causes it in the stack trace.
5. As for the recipe, you're specifying an item that doesn't exist in one of your jsons.
1. I think I just pasted it 2x by accident in the topic window.
2. I had separate classes originally because I thought I had to - with the materials being different, different hardness, etc.; I found later that I could do the same by just passing parameters in. Yes, I know I can do it with reusable code. Again, it's something I already knew, but just hadn't gotten around to doing; I've been focusing on other things.
The "identical" methods in the blocks initialization were there originally to handle the different ways of registering blocks - i.e., singletons vs. sub-blocks; I just hadn't removed them.
3. You're probably right; my slabs are based entirely on a tutorial; I'll look again at the slab class & see what's different.
4. I read the log, but can't figure out what's causing the error.
5. The recipe: newmod:beet_block DOES exist... or it should. I've done all the initialization, registration, etc. the same as every other block. It existed properly before I made these changes; therefore, there shouldn't be any problems now.
I'll go ahead & make these changes, then repost the code, along with any errors.
The revised code is at https://github.com/TheWebExpert1/newplants and the pastebin is at https://pastebin.com/Zzy7jY9X.
Good, the code looks better now.
Now the error is different. I've never encountered such an error, however it seems to me that there is a problem during your registry.
I can't help you at the moment (it's quite late here) so in the meantime you can try debugging your code.