I hear that I should definitely be using it, but I don't really understand what it is. I read the forge documentation on it and registries (because i'm also trying to get rid of static instantiations) but I'm still kind of confused.

Is it basically just a way to access object from another class? You would do @ObjectHolder("domain:object_your_overridding") unless you already specified the domain above the class, and that would allow you to overwrite that object, correct?

On the forge page it has this in its example:

    @ObjectHolder("ender_eye")
    public static final Item eye_of_ender = null;   // Type Item means that the Item registry will be queried.
                                                    // As the annotation has the value "ender_eye", that overrides the field's name.
                                                    // As the domain is not explicit, "minecraft" is inherited from the class.
                                                    // Object to be injected: "minecraft:ender_eye" from the Item registry.

Would that override/overwrite (is there a difference?) minecraft's ender_eye object (I'm assuming the Ender Eye item) with whatever you set eye_of_ender to?

 

Or do i have this totally wrong?

5 minutes ago, TheGoldenProof said:

Or do i have this totally wrong?

The @ObjectHolder annotation populates a static final field that exists in one of the forge registries. IE if I wanted a local instance of the Emerald Item

@ObjectHolder("minecraft:emerald")
public static final Item EMERALD = null;

That field now stores Items.EMERALD in it.

You can use this for your Items, but it is by no means required to use to get rid of static initializers. To get rid of static initializers means to not do

public static final Item NAME = new Item().setRegistryName...;
// OR
public static Item NAME;

static {
	NAME = new Item().setRegistryName...;
}

So instead you should do

public static void registryEvent() {
	ModItems.NAME = new Item().setRegistryName...
	// Register.
}

 

4 minutes ago, Animefan8888 said:

You can use this for your Items, but it is by no means required to use to get rid of static initializers.

I know its not, but they're kind of close (they share a forge page) so i figured I should use them anyway.

 

I think i get it now though. Its kindof the opposite of what I said. It "Overwrites" it (more accurately replaces "null") with the object specified if its in the registry for whatever type of object it is.

 

So to use this, I would have to add my items to the registry in the registry event thing, and then in the place where I declare Items, declare them null and let it fill in with the registry entry i just made?

13 minutes ago, Animefan8888 said:

So instead you should do

public static void registryEvent() {
	ModItems.NAME = new Item().setRegistryName...
	// Register.
}

I would argue against it, actually. Imagine if your mod has a multi-block structure, say an altar and that structure is composed out of a special block, say an altar stone. In your structure's TE you check the structure by comparing block instances - this.world.getBlockState(this.pos.down()).getBlock() == MyBlocks.ALTAR_STONE. Well, now let's say that someone else makes an addon to your mod which overrides your altar stone block with their version. Their mod loads after yours so the end object in the registry is their block. But now your comparason in your TE fails because MyBlocks.ALTAR_STONE isn't even registered, much less equals the AddonBlocks.ALT_ALTAR_STONE! This problem however goes away entirely if you use ObjectHolders instead since they will be populated with the actual block that was registered.

 

As for @TheGoldenProof's question - ObjectHolders simply tell forge "okay, after the registry event is done go through all fields annotated with ObjectHolder that match the registry that just finished being populated and put the things that the registry was populated with into those fields"

14 minutes ago, Animefan8888 said:

ModItems.NAME = new Item().setRegistryName...

Don't assign to a field that is marked with @ObjectHolder.

3 minutes ago, V0idWa1k3r said:

As for @TheGoldenProof's question - ObjectHolders simply tell forge "okay, after the registry event is done go through all fields annotated with ObjectHolder that match the registry that just finished being populated and put the things that the registry was populated with into those fields"

Ok good. Now that makes sense to me. Thank you.

 

5 minutes ago, V0idWa1k3r said:

I would argue against it, actually

I don't totally understand what you're arguing against here but I think I get your point. Use the object holder.

8 minutes ago, V0idWa1k3r said:

Well, now let's say that someone else makes an addon to your mod which overrides your altar stone block with their version. Their mod loads after yours so the end object in the registry is their block. But now your comparason in your TE fails because MyBlocks.ALTAR_STONE isn't even registered, much less equals the AddonBlocks.ALT_ALTAR_STONE!

True, but lets be honest the likelihood of this occurring isn't that high. I can't name a mod that actually does this to modded items or blocks.

5 minutes ago, Draco18s said:

Don't assign to a field that is marked with @ObjectHolder.

That's not what I was doing, I had switched to explaining what you could do instead of @ObjectHolder

10 hours ago, Animefan8888 said:

I can't name a mod that actually does this to modded items or blocks.

https://minecraft.curseforge.com/projects/botania-tweaks had difficulty with a number of things due to the base mod not using ObjectHolders.

6 hours ago, quadraxis said:

had difficulty with a number of things due to the base mod not using ObjectHolders.

You simply just needed to use reflection to change the values of the fields in your preInit method seeing as how botania still uses an old method of instantiating their IForgeRegistry fields and make your mod load after botania, which it should do anyways.

 

Now what would have made it a pain is if vazkii had updated to the new way because then you would have had to use reflection to change the fields and register them yourself. 

 

Of course it's more work than simply overriding the registry, but let's be real here why couldn't you have just done a pull request on vazkii's github to allow for the configuration options. It probably would've been easier to create than an addon.

I'm not the author of the mod, I'm simply repeating what they have previously said.

If you want to debate it, you can find them on various modding Discords, among other places.

1 hour ago, quadraxis said:

I'm not the author of the mod, I'm simply repeating what they have previously said.

If you want to debate it, you can find them on various modding Discords, among other places.

Oh, that's my bad when I read it I inserted an 'I' after the mod link.