[SOLVED] How to register WallOrFloorItem / Torch

[StealthyNoodle]

Hi. I've just made a torch that extinguishes over time, but only as a floor block. The torch is functional, but to finish it I need to pass the floor block through a WallOrFloorItem, along with a wall block.
I'm struggling with figuring out the proper way to register WallOrFloorItem along with those two blocks. Do I register the TorchBlock and WallTorchBlock with their own unique registry-names, or do they get registered as part of WallOrFloorItem? If they all should be registered, shouldn't I be able to use the same registry-name for WallOrFloorItem and TorchBlock?

If only there was an example resource to look at, that'd help a lot too!

tl;dr: What's the right way to register custom WallOrFloorItem, TorchBlock and WallTorchBlock?

ModItems:

public static final RegistryObject<Item> FLIMSY_TORCH = Registration.ITEMS.register("flimsy_torch", () ->
		new WallOrFloorItem(ModBlocks.FLIMSY_TORCH.get(), Blocks.WALL_TORCH, (new Item.Properties()).group(ItemGroup.DECORATIONS)));

 

ModBlocks:

public static final RegistryObject<Block> FLIMSY_TORCH = register("flimsy_torch", () ->
		new FlimsyTorchBlock(Block.Properties.from(Blocks.TORCH).tickRandomly().setLightLevel((state) -> {
		      return 14;
		   }), ParticleTypes.FLAME, 3));

//Still missing a WallTorchBlock, using vanilla WallTorch as placeholder

When trying to register the TorchBlock in addition to the WallOrFloorItem(using same name), I'm presented with this error:

 

[04:25:28] [modloading-worker-1/ERROR] [ne.mi.fm.ja.FMLModContainer/LOADING]: Failed to create mod instance. ModID: solidrocks, class com.snoodle.solidrocks.SolidRocks
java.lang.ExceptionInInitializerError: null
	at com.snoodle.solidrocks.setup.Registration.register(Registration.java:25) ~[?:?] {re:classloading}
	at com.snoodle.solidrocks.SolidRocks.<init>(SolidRocks.java:19) ~[?:?] {re:classloading}
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:1.8.0_271] {}
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) ~[?:1.8.0_271] {}
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[?:1.8.0_271] {}
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423) ~[?:1.8.0_271] {}
	at java.lang.Class.newInstance(Class.java:442) ~[?:1.8.0_271] {}
	at net.minecraftforge.fml.javafmlmod.FMLModContainer.constructMod(FMLModContainer.java:81) ~[forge:35.1] {re:classloading}
	at net.minecraftforge.fml.ModContainer.lambda$buildTransitionHandler$4(ModContainer.java:120) ~[forge:?] {re:classloading}
	at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640) [?:1.8.0_271] {}
	at java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1632) [?:1.8.0_271] {}
	at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289) [?:1.8.0_271] {}
	at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1067) [?:1.8.0_271] {}
	at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1703) [?:1.8.0_271] {}
	at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:172) [?:1.8.0_271] {}
Caused by: java.lang.IllegalArgumentException: Duplicate registration flimsy_torch
	at net.minecraftforge.registries.DeferredRegister.register(DeferredRegister.java:125) ~[forge:?] {re:classloading}
	at com.snoodle.solidrocks.setup.ModItems.<clinit>(ModItems.java:20) ~[?:?] {re:classloading}
	... 15 more

Edited January 17, 2021 by StealthyNoodle

[ChampionAsh5357]

1 hour ago, StealthyNoodle said:

Do I register the TorchBlock and WallTorchBlock with their own unique registry-names

Well, yes. Names must be unique on a per registry basis. That's where your error is coming from.

[StealthyNoodle]

5 hours ago, ChampionAsh5357 said:

Well, yes. Names must be unique on a per registry basis. That's where your error is coming from.

Currently I don't register a WallTorchBlock, so I wouldn't think that's the duplicate (unless it's being registered as part of the WallOrFloorItem). But at the same time I find it odd that it would register my WallOrFloorItem(which is registered under ITEMS) to be in conflict with my TorchBlock(which is registered under BLOCKS with the same name) as they're unique in their registries as you say.

Could it be that I'm messing up somewhere else? Data generation perhaps?

[ChampionAsh5357]

4 hours ago, StealthyNoodle said:

Could it be that I'm messing up somewhere else? Data generation perhaps?

Well, I wouldn't know, the entire class where the error is occurring is not shown. If you could provide a link to your repo, it would provide more detail. Also, you shouldn't use a vanilla block within a BlockItem placeholder. That will cause all instances of that block to believe that your item is its item representation.

[StealthyNoodle]

17 minutes ago, ChampionAsh5357 said:

If you could provide a link to your repo, it would provide more detail.

Certainly! https://github.com/Fnkee/solidrocks

I see that I'm running a copy method on the torch, under the ItemTagsProvider (ModItemTagsProvider). That should be transfering data from the block tag into an item tag. Maybe that's what's causing the duplicate registration.

[ChampionAsh5357]

6 minutes ago, StealthyNoodle said:

I see that I'm running a copy method on the torch, under the ItemTagsProvider (ModItemTagsProvider). That should be transfering data from the block tag into an item tag. Maybe that's what's causing the duplicate registration.

Nope, you're just registering the item twice. Your block calls this method which creates an item to which you then create another item under the same name.

[StealthyNoodle]

On 1/15/2021 at 5:19 PM, ChampionAsh5357 said:

Nope, you're just registering the item twice. Your block calls this method which creates an item to which you then create another item under the same name.

Fantastic - That would take me days to figure out!



Got it all up and running now. Thanks a lot, man!
 

 

On 1/15/2021 at 4:09 PM, ChampionAsh5357 said:

Also, you shouldn't use a vanilla block within a BlockItem placeholder. That will cause all instances of that block to believe that your item is its item representation.

I'll keep this in mind too