MC 1.12. I'd forgotten that the uppercase thing was an issue, and hadn't renamed the file. My own code had it right, but not the 'copied' code.
I hadn't changed anything yet (including comments) because I've been focusing on making things work. I've now changed the name & everything over. I have the new code posted at https://github.com/TheWebExpert1/newplants.
I am initializing the items during registry; that much is clear. I *THINK* I'm initializing the blocks the right way, but I'm not certain.
The fruit shows up in the FOOD tab; the seeds in the MISC tab; both have their proper textures. The planted seeds give STAGE #0 (with correct texture), but the plant won't grow currently (i.e., go to stage1, stage2, etc.). This is working FAR better than before (with all that unnecessary code), and I'm beginning to understand more of WHY it wasn't working before.
Ok: So I changed the code back to the vanilla beetroot's 3 stages, and the plant grows perfectly. Visually, it's not what I want (yet) - but that's because my plant is designed around 7 stages. Since it's working, I think I can figure out how to make it BE seven stages. Anyway, thanks for your help!
PS. I'd appreciate your input on my code - if I'm getting things right, that'll help me proceed.
...and that's it! With the modification of the vanilla code using some of the code from the super-mess code I had posted originally, I was able to increase my crops to 7 stages.
...and that's it! With the modification of the vanilla code using some of the code from the super-mess code I had posted originally, I was able to increase my crops to 7 stages.
You're finally registering your blocks properly. But still you're not initializing the item/block filed during registry, you're initializing them as soon as the your class is created. Do you understand what field initialization means?
Not precisely. If you can SHOW me what you mean (i.e., initializing during registry, rather than as I'm currently doing it), plus an explanation of field initialization... I tried looking it up on google, but didn't find anything instructive.
First search result. You really need to tackle basic java before attempting modding a game made on java. By initializing a field during registry I mean initialize the field when the registry event is ran. I explained why this is better before.
1. Cool, why are you showing me this if even though I've seen what you've done already in your repo?
2. You don't need to call the RegistryEvent'sgetRegistry.register everytime, you can use the registerAll() for convenience.
3. Still not initializing correctly. I was trying to give you less examples so that you could learn (even though I actually did), but that seems pointless since you're not learning. What I meant is just create a new instance of your item/block inside of your register method before using getRegistry.registerAll. Literally provided you with an example yesterday.
Actually, I have all my "init" classes under a separate "initialization" package, which "feels" better to me. Ok, now that I finally understand what you've been talking about: Can you please explain the benefit of doing it this way? If you've already said so before, I'm sorry, but I'd really like to know. I mean, the other way (the wrong way) seemed to work... obviously, this is better in some way...
Actually, I have all my "init" classes under a separate "initialization" package, which "feels" better to me. Ok, now that I finally understand what you've been talking about: Can you please explain the benefit of doing it this way? If you've already said so before, I'm sorry, but I'd really like to know. I mean, the other way (the wrong way) seemed to work... obviously, this is better in some way...
As I already explained, some params, fields or methods can require the registered entry causing a crash if initialized before the required entry has been registered. I've personally had a problem with this before and I've been initializing my fields during registry since.
Ah. So if I've initialized things during registry, the program has everything it needs, and therefore can do whatever; if it's trying to grab a hold of something that hasn't been registered yet, it'll go bonkers. Thanks.
I am having one problem, though - converting my code from the way I used to do it to the new way. I have everything ported over EXCEPT for the blocks; you stated that it was wrong (unwise, or whatever) to use ForgeRegistries.BLOCKS.register(block); here's my original code:
public static void registerBlock(Block block)
{
ForgeRegistries.BLOCKS.register(block);
ItemBlock item = new ItemBlock(block);
item.setRegistryName(block.getRegistryName());
ForgeRegistries.ITEMS.register(item);
ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(block), 0, new ModelResourceLocation(block.getRegistryName(), "inventory"));
}
public static void registerBlock(Block block, ItemBlock itemblock)
{
ForgeRegistries.BLOCKS.register(block);
itemblock.setRegistryName(block.getRegistryName());
ForgeRegistries.ITEMS.register(itemblock);
ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(block), 0, new ModelResourceLocation(block.getRegistryName(), "inventory"));
}
public static void registerBlockWithVariants(Block block, ItemBlock itemblock)
{
ForgeRegistries.BLOCKS.register(block);
itemblock.setRegistryName(block.getRegistryName());
ForgeRegistries.ITEMS.register(itemblock);
}
I need to convert these functions over so that I can still call them -- but I'm stumbling over HOW to do it. For instance, on registerBlockWithVariants, I tried:
public static void registerBlockWithVariants(Block block, ItemBlock itemblock)
{
itemblock.setRegistryName(block.getRegistryName());
ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(block), meta, new ModelResourceLocation(block.getRegistryName(), "inventory")); ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(itemblock), 0, new ModelResourceLocation(block.getRegistryName(), "inventory"));
}
... but it caused all kinds of problems. I know there's a way -- I just want to do this RIGHT.
1. I register blocks and itemblocks for them separately in their relevant classes (for me it's ItemList and BlockList).
2. Same applies to models. I register them separately in their relevant classes inside a method for registering models that is called by the ModelRegistryEvent.
That makes sense. I think I've got it all now - I have everything working. Except: There are two blocks that are not registering at all in game, the Combiner and the Compressor. They simply don't exist. I'm not sure why. I was looking at the old code, to see if I could figure out what's missing, but haven't figured it out. The revised code is posted at https://github.com/TheWebExpert1/newplants. Can you figure out what's wrong?
ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(block), 0, new ModelResourceLocation(block.getRegistryName(), "inventory"));
}
Now, I had NO references to ForgeRegistries in my code - everything worked, except for this block. Now it works. I'm assuming there's a different way to do this - but I have working blocks now. I'll move the items; it's one thing I had planned to do, but hadn't done yet. The compressor and combiner (although similar) each have a separate main class, container class, tileentity class and gui class - they are intended to work very differently, so I created a set of code for each.
I put all of my "miscellaneous" code - config, handlers, initialization, etc. into the "support code" package, because a) it looks less cluttered in the hierarchical view; and b). they're grouped together (which makes SOME sense). I suppose I could leave them out with the other packages (items, blocks, armor, etc.) - it will still work the same - but...
2. You still didn't explain why you have and idle and active version of your blocks.
3. Things like tile entities, events, configs, handlers, proxies, gui and worldgen are NOT miscellaneous. Miscellaneous code would be helpers and utilities of sorts. Also gui belongs EXCLUSIVELY to the client side. Please move it to your client sub package,
MC 1.12. I'd forgotten that the uppercase thing was an issue, and hadn't renamed the file. My own code had it right, but not the 'copied' code.
I hadn't changed anything yet (including comments) because I've been focusing on making things work. I've now changed the name & everything over. I have the new code posted at https://github.com/TheWebExpert1/newplants.
I am initializing the items during registry; that much is clear. I *THINK* I'm initializing the blocks the right way, but I'm not certain.
The fruit shows up in the FOOD tab; the seeds in the MISC tab; both have their proper textures. The planted seeds give STAGE #0 (with correct texture), but the plant won't grow currently (i.e., go to stage1, stage2, etc.). This is working FAR better than before (with all that unnecessary code), and I'm beginning to understand more of WHY it wasn't working before.
Ok: So I changed the code back to the vanilla beetroot's 3 stages, and the plant grows perfectly. Visually, it's not what I want (yet) - but that's because my plant is designed around 7 stages. Since it's working, I think I can figure out how to make it BE seven stages. Anyway, thanks for your help!
PS. I'd appreciate your input on my code - if I'm getting things right, that'll help me proceed.
...and that's it! With the modification of the vanilla code using some of the code from the super-mess code I had posted originally, I was able to increase my crops to 7 stages.
...and that's it! With the modification of the vanilla code using some of the code from the super-mess code I had posted originally, I was able to increase my crops to 7 stages.
You're finally registering your blocks properly. But still you're not initializing the item/block filed during registry, you're initializing them as soon as the your class is created. Do you understand what field initialization means?
Not precisely. If you can SHOW me what you mean (i.e., initializing during registry, rather than as I'm currently doing it), plus an explanation of field initialization... I tried looking it up on google, but didn't find anything instructive.
First search result. You really need to tackle basic java before attempting modding a game made on java. By initializing a field during registry I mean initialize the field when the registry event is ran. I explained why this is better before.
I *THINK* I might have it. Ok, here's what I had:
and
And now I have this:
and
Have I *FINALLY* gotten it right? It seems (from the link you gave me) that THIS is what you were talking about...
1. Cool, why are you showing me this if even though I've seen what you've done already in your repo?
2. You don't need to call the RegistryEvent's getRegistry.register everytime, you can use the registerAll() for convenience.
3. Still not initializing correctly. I was trying to give you less examples so that you could learn (even though I actually did), but that seems pointless since you're not learning. What I meant is just create a new instance of your item/block inside of your register method before using getRegistry.registerAll. Literally provided you with an example yesterday.
This is it:
Yes?
Incredible! Now do the same with items.
EDIT: For organization purposes move your blocks init class to the Block package (OCD).
Actually, I have all my "init" classes under a separate "initialization" package, which "feels" better to me. Ok, now that I finally understand what you've been talking about: Can you please explain the benefit of doing it this way? If you've already said so before, I'm sorry, but I'd really like to know. I mean, the other way (the wrong way) seemed to work... obviously, this is better in some way...
As I already explained, some params, fields or methods can require the registered entry causing a crash if initialized before the required entry has been registered. I've personally had a problem with this before and I've been initializing my fields during registry since.
Ah. So if I've initialized things during registry, the program has everything it needs, and therefore can do whatever; if it's trying to grab a hold of something that hasn't been registered yet, it'll go bonkers. Thanks.
I am having one problem, though - converting my code from the way I used to do it to the new way. I have everything ported over EXCEPT for the blocks; you stated that it was wrong (unwise, or whatever) to use ForgeRegistries.BLOCKS.register(block); here's my original code:
I need to convert these functions over so that I can still call them -- but I'm stumbling over HOW to do it. For instance, on registerBlockWithVariants, I tried:
... but it caused all kinds of problems. I know there's a way -- I just want to do this RIGHT.
1. I register blocks and itemblocks for them separately in their relevant classes (for me it's ItemList and BlockList).
2. Same applies to models. I register them separately in their relevant classes inside a method for registering models that is called by the ModelRegistryEvent.
That makes sense. I think I've got it all now - I have everything working. Except: There are two blocks that are not registering at all in game, the Combiner and the Compressor. They simply don't exist. I'm not sure why. I was looking at the old code, to see if I could figure out what's missing, but haven't figured it out. The revised code is posted at https://github.com/TheWebExpert1/newplants. Can you figure out what's wrong?
1. I think I'm repeating myself like 4 times already. Please remove ForgeRegistries from your code.
2. Get rid of the "support_code" package. It makes no sense.
3. I'm not sure why these two aren't being registered. Maybe you just forgot to create their itemblocks?
4. Why are you creating separate blocks for your compressor's and combiner's states?
5. It's good practice to move any sub classe packages of Item (like your plants, food, etc) to the Item package.
The original block works as follows:
public static void register() public static void register()
{
registerComp(compressor_idle);
ForgeRegistries.BLOCKS.register(compressor_active);
}
private static void registerComp(Block block)
{
ForgeRegistries.BLOCKS.register(block);
ItemBlock item = new ItemBlock(block);
item.setRegistryName(block.getRegistryName());
ForgeRegistries.ITEMS.register(item);
ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(block), 0, new ModelResourceLocation(block.getRegistryName(), "inventory"));
}
Now, I had NO references to ForgeRegistries in my code - everything worked, except for this block. Now it works. I'm assuming there's a different way to do this - but I have working blocks now. I'll move the items; it's one thing I had planned to do, but hadn't done yet. The compressor and combiner (although similar) each have a separate main class, container class, tileentity class and gui class - they are intended to work very differently, so I created a set of code for each.
I put all of my "miscellaneous" code - config, handlers, initialization, etc. into the "support code" package, because a) it looks less cluttered in the hierarchical view; and b). they're grouped together (which makes SOME sense). I suppose I could leave them out with the other packages (items, blocks, armor, etc.) - it will still work the same - but...
1. Again, remove ForgeRegistries from your code.
2. You still didn't explain why you have and idle and active version of your blocks.
3. Things like tile entities, events, configs, handlers, proxies, gui and worldgen are NOT miscellaneous. Miscellaneous code would be helpers and utilities of sorts. Also gui belongs EXCLUSIVELY to the client side. Please move it to your client sub package,