KindOfWay

No, support for 1.12.2 was dropped.

This looks like outdated code to me. There is no reason for you to use CommonProxy to register the items. The EventSubscriber is wrong the notation is @EventBusSubscriber(modid = Mymod.modId, bus = EventBusSubscriber.Bus.<target>) Where target is either MOD or FORGE depending which events you need I register my items like this in 1.15.2 public final class ModItems { public static final DeferredRegister<Item> ITEMS = new DeferredRegister<>(ForgeRegistries.ITEMS, MyMod.modId); public static final RegistryObject<Item> sample_item = ITEMS.register("sample_item", () -> new Item(new Item.Properties().group(ModItemGroups.MOD_ITEM_GROUP))); } Then in my MyMod java final IEventBus modEventBus = FMLJavaModLoadingContext.get().getModEventBus(); ModItems.ITEMS.register(modEventBus);

public class WitcheryItems { public static final List<Item> ITEMS = new ArrayList<>(); // Items public static final Item SOFT_CLAY_JAR = new ItemBase("soft_clay_jar"); public static final Item CLAY_JAR = new ItemBase("clay_jar"); } @SubscribeEvent public static void onRegisterItems(RegistryEvent.Register<Item> event) { event.getRegistry().registerAll(WitcheryItems.ITEMS.toArray(new Item[0])); } You creating the items, but you never actually register them. Witchery.ITEMS is a empty ArrayList, then in registerAll you access it and assign a new empty Item to it. This won't work, and it looks like that's the issue. Unless I overlooked where you're adding SOFT_CLAY_JAR and CLAY_JAR to the ITEMS array.

Also post ExampleMod java, to make sure the registered name is correct, it should be registering as "my_sword" to work.

I can guarantee that registering of items is working just fine in 1.15.2. The problem you're facing is that a major rework was done on the forge api after 1.12.2. The latest documentation won't hold your hand explaining all changes, but it does a good job revealing what the latest way is. I wouldn't recommend looking up old tutorials and porting your existing code base step by step, apart from a lot of overhead work, you will face countless other problems. Take a look how items are registered in this github: https://github.com/Cadiboo/Example-Mod, start from there.

My guess is, the png is in the wrong path within the project. Mine are located in src/main/resources/assets/modname/textures/items/myitem.png My model is in src/main/resources/assets/modname/models/item/myitem.json For you, it looks like the json expects the file in: src/main/resources/assets/sword/textures/items/my_sword.png

What helped me a lot start out was this tutorial and github: https://cadiboo.github.io/tutorials/1.15.1/forge/ https://github.com/Cadiboo/Example-Mod For complex or specific things I looked at other githubs, just ensure they are 1.14.2+ or you run into issues with the API changes. Another source of information are the original Java classes from Mojang you can inspect in your ide of choice, a lot is de-obfuscated and human readible. I also strongly recommend to have at least some Java background or read up on it, some of the concepts use rather "modern" ideas like lambdas.

Maybe it's my lack of build system knowledge. Edit: I should also mentioned that it's building just fine now, just the runClient task is showing this issue I changed the following to build.gradle: I added repositories { flatDir name: 'libs', dirs: 'libs' } And in dependencies I added compile fg.deobf(name: 'budgit-1.15.2-0.1') Full build gradle of the target: build.gradle Edit: Solved, if you find this: Ensure that in the source project, jar.finalizedBy is commented out, delay that step as seen below. // Example configuration to allow publishing using the maven-publish task // This is the preferred method to reobfuscate your jar file //jar.finalizedBy('reobfJar') // However if you are in a multi-project build, dev time needs unobfed jar files, so you can delay the obfuscation until publishing by doing publish.dependsOn('reobfJar') Then build via the jar task, not the build task. Copy your jar into the repository, in my case the libs folder of the targets root directory. Follow the rest of the configuration and it will work fine.

Hello, I am having trouble to understand what is required to use a jar from another project(source) I created as a dependency for my current project(target). 1. Which jar should be used in build.grade from the source project, do I have to run the gradle jar task or the gradle build task? 2. I tried both methods, and I am listing them as a dependency using: compile fileTree(dir: 'libs', includes: ['*.jar']) in the target project this results in the following errors: [m[1;31m[04:09:23] [Render thread/ERROR] [ne.mi.fm.ja.FMLModContainer/LOADING]: Caught exception during event RegistryEvent.Register<minecraft:item> dispatch for modid budgit java.lang.NoSuchMethodError: net.minecraft.item.Item$Properties.func_200916_a(Lnet/minecraft/item/ItemGroup;)Lnet/minecraft/item/Item$Properties; at com.kow.budgit.init.ModItems.lambda$static$0(ModItems.java:18) ~[budgit-1.15.2-0.1.jar:1.15.2-0.1] {re:classloading} at net.minecraftforge.registries.DeferredRegister.lambda$register$0(DeferredRegister.java:84) ~[forge-1.15.2-31.1.16_mapped_snapshot_20190719-1.14.3-recomp.jar:?] {re:classloading} -- cut here as the rest doesn't seem relevant The code in question is: public final class ModItems { public static final DeferredRegister<Item> ITEMS = new DeferredRegister<>( ForgeRegistries.ITEMS, Budgit.modId); public static final RegistryObject<VesaCardItem> vesa_card = ITEMS .register("vesa_card", () -> new VesaCardItem( new Item.Properties().group(ModItemGroups.MOD_ITEM_GROUP).maxStackSize(1))); } This code of the (source) is build, loading and working as a mod just fine on it's own. Just when attempted to add this to the target project to use some of it's methods, it produces this error. It appears there is an issue finding the default Minecraft method, is this some issue with obfuscation? Thanks for any hints!