How works Enum in newest 1.15.1?

[ScarlettSh0]

I'm not too new and not too old in modding. I remember I saw using Enum for making same tools but with different materials, adn I think it's easier to make one Enum with all COPPER, TIN and etc than adding it manually, but I haven't saw a lot mods for 1.15.1[1.14.4] so is it still working, and maybe you can help me understand it?

[TheGreenSquarez]

Are you a native English speaker?

[ScarlettSh0]

Nope, but trying to speak less shitty. It doesn't work, does it?)

[MartinTheDragon]

Well, you could use a gray texture for your tool and then color it in the corresponding color of the material you chose with your enum. So you would have to make an enum with a constructor that has a color as an argument. Then you could for each material you have in your enum register all the tools automatically with the texture colored in the color of the material. At least that is how I would do it.

Edited December 24, 2019 by MartinTheDragon

[ScarlettSh0]

4 minutes ago, MartinTheDragon said:

Well, you could use a gray texture for your tool and then color it in the corresponding color of the material you chose with your enum. So you would have to make an enum with a constructor that has a color as an argument. Then you could for each material you have in your enum register all the tools automatically with the texture colored in the color of the material. At least that is how I would do it.

I did something, now learning on code optimization and then I want to add example ore blocks through Enum. An I doing it right? Would be very thankfull if you help
https://github.com/ScarlettShooter/hier/blob/master/src/main/java/com/scrl0/hier/utility/MaterialType.java

[MartinTheDragon]

That is a way of doing it, but you would have to set so many parameters for every material you create. And if you just set the durability for the material and not for the tool itself, are you using a multiplier for the tool?

[ScarlettSh0]

1 minute ago, MartinTheDragon said:

That is a way of doing it, but you would have to set so many parameters for every material you create. And if you just set the durability for the material and not for the tool itself, are you using a multiplier for the tool?

Isn't maxUses that you exactly mean? I used some other's mod sources to understand how it works

[ScarlettSh0]

Also, I think I use this theme for questions. What is the best way to store blocks\items to array? I want to try making registration in loop to not spam cause I think it's not the best way to do it(check down). And it's not even item registration or other blocks, only ores...

	e.getRegistry().register(new ModBlocks().tin_ore);
	e.getRegistry().register(new ModBlocks().aluminium_ore);
	e.getRegistry().register(new ModBlocks().silver_ore);
	e.getRegistry().register(new ModBlocks().zinc_ore);
	e.getRegistry().register(new ModBlocks().chrome_ore);
	e.getRegistry().register(new ModBlocks().lead_ore);
	e.getRegistry().register(new ModBlocks().platinum_ore);
	e.getRegistry().register(new ModBlocks().titanium_ore);
	e.getRegistry().register(new ModBlocks().nickel_ore);

 

[DavidM]

3 hours ago, ScarlettSh0 said:

Nope, but trying to speak less shitty. It doesn't work, does it?)

Your English skill sounds pretty good to me.

 

34 minutes ago, ScarlettSh0 said:

Also, I think I use this theme for questions. What is the best way to store blocks\items to array? I want to try making registration in loop to not spam cause I think it's not the best way to do it(check down). And it's not even item registration or other blocks, only ores...

	e.getRegistry().register(new ModBlocks().tin_ore);
	e.getRegistry().register(new ModBlocks().aluminium_ore);
	e.getRegistry().register(new ModBlocks().silver_ore);
	e.getRegistry().register(new ModBlocks().zinc_ore);
	e.getRegistry().register(new ModBlocks().chrome_ore);
	e.getRegistry().register(new ModBlocks().lead_ore);
	e.getRegistry().register(new ModBlocks().platinum_ore);
	e.getRegistry().register(new ModBlocks().titanium_ore);
	e.getRegistry().register(new ModBlocks().nickel_ore);

 

If you are storing all your values in an enum, you can call

YourEnum.values()

to get a collection of all the values, which you could iterate through and initialize the block from. Simply create another list and store the initialized blocks into it during the iteration.

 

I would suggest to post more of your code, preferably as a GitHub repo. This allows other members to give more accurate suggestions on your code.

Edited December 24, 2019 by DavidM

[ScarlettSh0]

10 minutes ago, DavidM said:

Your English skill sounds pretty good to me.

 

If you are storing all your values in an enum, you can call

YourEnum.values()

to get a collection of all the values, which you could iterate through and initialize the block from. Simply create another list and store the initialized blocks into it during the iteration.

 

I would suggest to post more of your code, preferably as a GitHub repo. This allows other members to give more accurate suggestions on your code.

I already droped it, just uploaded a commit cause things changed a little. Also I didn't have moved to enums yet. I want, but I learning deeps now)

https://github.com/ScarlettShooter/hier

I'm in process of making code better, so you can see something that have no use now, I'm working only in ModItems now

Edited December 24, 2019 by ScarlettSh0
Explanation of so weird code

[Draco18s]

This is static so there is no reason to call new here or here.

But you should not be creating your items in a static location (common issues, problematic code #14).

 

The indentation levels in your ModSetup class are broken. What does this } close?

 

All three of these methods are empty.

 

Double cast. You're casting a BlockState to a BlockState and then to a BlockState. Same here.

[ScarlettSh0]

Ough...
I made it. I totally rewrote system to enums. It's amazing and both tiringly experience. But I want to know if it don't broke some features in future so it would be very pleasure if you could check if there is errors. Curently I'm using basic HiER and MaterialType classes, no ModBlocks/Items. Also, I get this in my Creative Tab(check image below). I saw somewhere that is how Forge works Block - Item - Blocks - Item, but maybe not?
 

Spoiler

Also, in respond I don't know  I was going through tutorials and there McJTY said it is for future. I want to do all the works with basic blocks and items in right way immediatly so here I am. Also what you said about static and #14 means if I add blocks I shouldn't make them static like "public static Block copper_ore;"? Sorry for that question, I need more practice in English to understand some sentences first time... If it is, the problem is that you actually gets memory for that blocks when you calling proper methods so making those blocks static only use more memory, does it? Anyway, thanks

 

2 hours ago, Draco18s said:

This is static so there is no reason to call new here or here.

But you should not be creating your items in a static location (common issues, problematic code #14).

 

The indentation levels in your ModSetup class are broken. What does this } close?

 

All three of these methods are empty.

 

Double cast. You're casting a BlockState to a BlockState and then to a BlockState. Same here.

 

[Draco18s]

3 hours ago, ScarlettSh0 said:

I add blocks I shouldn't make them static like "public static Block copper_ore;"? Sorry for that question, I need more practice in English to understand some sentences first time.

The field can be static, that's ok. You just can't call new there. This has to do with SetRegistryName and Forge needing to insure that the correct domain is applied, which is can only do if the constructor is called in a Forge-controlled event. static blocks can get executed at any time.

You should only call new Block() or new Item() in the registry event that registers them and use @ObjectHolder annotations to populate the static field with a value.

[ScarlettSh0]

9 hours ago, Draco18s said:

The field can be static, that's ok. You just can't call new there. This has to do with SetRegistryName and Forge needing to insure that the correct domain is applied, which is can only do if the constructor is called in a Forge-controlled event. static blocks can get executed at any time.

You should only call new Block() or new Item() in the registry event that registers them and use @ObjectHolder annotations to populate the static field with a value.

I think I understand what you mean. When I will be adding new blocks I'll do it like you said. Also do you know why in Tab items like saving theirs position from previos entrance?

 

Also I just did generator way you said(I think, but not sure). In ModBlocks class I have 

@ObjectHolder(MOD_ID + ":generator")
	public static Block generator;

In main class I have
 

/*Block register event*/
	ModBlocks.generator = new Generator("generator", 1, 4, 4);
	e.getRegistry().register(ModBlocks.generator);
/*Item register event*/
	e.getRegistry().register(new BlockItem(ModBlocks.generator, properties).setRegistryName(MOD_ID, "generator"));

Am I doing it right?

Edited December 25, 2019 by ScarlettSh0

[Draco18s]

12 hours ago, ScarlettSh0 said:

ModBlocks.generator = new Generator("generator", 1, 4, 4);

No. @ObjectHolder fields are final. You can't set them directly. Just do this:

 

Even.getRegistry().register(new Generator(...));

[ScarlettSh0]

57 minutes ago, Draco18s said:

No. @ObjectHolder fields are final. You can't set them directly. Just do this:

 

Even.getRegistry().register(new Generator(...));

Hm, okey. So this event "does it" instead of you? Didn't realize that. Seems McJTY tut's are a little bit outdated(or maybe he did that in last episodes which I didn't watched yet). Seems like if I do all work like this, I have no need for ModBlocks class. Thank you very much!

[Draco18s]

2 hours ago, ScarlettSh0 said:

So this event "does it" instead of you? Didn't realize that.

Not exactly, but yes, but also no.

 

ObjectHolder fields are populated with values by Forge after the event has called all of the handlers that listen for it. Blocks first (object holders for blocks are populated), then items (object holders for items are populated), then everything else, then all object holders are refreshed.

2 hours ago, ScarlettSh0 said:

Seems McJTY tut's are a little bit outdated

Yes, they are. And he probably won't update his practices, because like so many youtube tutorials before him, they regurgitate the same garbage they learned without seeing if there's a better way.

[ScarlettSh0]

10 hours ago, Draco18s said:

Not exactly, but yes, but also no.

 

ObjectHolder fields are populated with values by Forge after the event has called all of the handlers that listen for it. Blocks first (object holders for blocks are populated), then items (object holders for items are populated), then everything else, then all object holders are refreshed.

Yes, they are. And he probably won't update his practices, because like so many youtube tutorials before him, they regurgitate the same garbage they learned without seeing if there's a better way.

So is there something for what ObjectHolder will be better practice?

[Draco18s]

5 hours ago, ScarlettSh0 said:

So is there something for what ObjectHolder will be better practice?

ObjectHolders are what allows for mods to override items with their own version (e.g. "I want to make dirt a falling block" -> register your own block as "minecraft:dirt"). Because of the way Forge populates ObjectHolder fields with values, these replacement actions work even for items and blocks added by any mod.

[ScarlettSh0]

3 hours ago, Draco18s said:

ObjectHolders are what allows for mods to override items with their own version (e.g. "I want to make dirt a falling block" -> register your own block as "minecraft:dirt"). Because of the way Forge populates ObjectHolder fields with values, these replacement actions work even for items and blocks added by any mod.

So it's like forge does with bucket. Thanks again. It's important for me to understand why is it(abstract it, including all) working