ChronosWS

According to the github code, you are calling BlockInit.preInit() in your FMLPreInit event, but there is no preInit() method on BlockInit. I suspect you forgot to commit your latest changes and push them to GitHub. @EventHandler public static void preInit(FMLPreInitializationEvent event){ GameRegistry.registerWorldGenerator(new OreGen(), 3); BlockInit.preInit(); // THIS METHOD DOESN"T EXIST IN YOUR GITHUB VERSION OF BlockInit ItemInit.init(); Smelting.init(); }

Yeah, you need to: a) don't create BLOCK_COPPER in the static initializer b) don't create your Items (in ItemsInit) in the static initializer. Repeat the pattern of preInit and init from BlocksInit c) call SmeltingInit after BlocksInit and ItemsInit (which you will need to add.)

Is your sourcecode up on GitHub? Can you post a link to the full source? I feel like looking at your code through thin snippets is obscuring the actual problem.

You might find it very helpful to download the full source for one of these more established mods and step through it with a debugger. Sometimes that's easier than reading the source (though in the case of the two mods I have linked so far, the source is pretty well organized.)

Ah actually in BOP, they do that smelting registration in preInit. I didn't read back far enough

For smelting, you might look here for an example of how to configure smelting: https://github.com/Glitchfiend/BiomesOPlenty/blob/BOP-1.12.x-7.0.x/src/main/java/biomesoplenty/common/init/ModCrafting.java in init(), you might do the following: GameRegistry.addSmelting(new ItemStack(ORE_COPPER_BLOCK), new ItemStack(<your item or block here>), 0.1F); if I understand the code correctly...

Also, had you previously generated a world with your old code (which perhaps assigned different/corrupt values for block IDs). I don't know exactly, but you may need to generate a new world if you aren't already doing so.

Are you registering them during the appropriate events? What is the exact error message?

Sorry, remove the 'final' from it

I'll take a stab at this - sorry I'm pretty new to modding but I can answer the Java-ish related question for you. When they say don't register in the static initializer, they mean that you shouldn't be creating the items as part of static initialization, which is what happens when you assign static fields a value as part of the declaration. In your code: public class BlockInit { public static final List<Block> BLOCKS = new ArrayList<Block>(); public static final Block ORE_COPPER_BLOCK = new Ore("ore_copper"); } Both of those fields are static initializer fields. Now, if you want to be able to access them statically but not initialize them statically, do something like this (which you can find by examining a number of mods source code on Github; see for example Vazkii's relatively clean Psi mod here): public class BlockInit { public static final List<Block> BLOCKS = new ArrayList<Block>(); public static final Block ORE_COPPER_BLOCK; // DO NOT ASSIGN HERE! public static void preInit() { ORE_COPPER_BLOCK = new Ore("ore_copper"); BLOCKS.add(ORE_COPPER_BLOCK); // Not sure why you are keeping the list, but if you want to add, you can do so here. } public static void init() { OreDictionary.registerOre("<your block ore dict id here>", new ItemStack(ORE_COPPER_BLOCK, 1, 0)); } } Then, when handling the FMLPreInitializationEvent , call BlockInit.preInit(). When handling the FMLInitializationEvent , call BlockInit.init(). Hope this helps more than harms. I strongly recommend following one of the other mods' patterns rather than rolling your own Vazkii's more or less follows the Forge documentation recommended guidelines, and it will help your future questions here if you have followed the documentation patterns so you won't have to explain yourself

I am looking to do some performance profiling for my server, likely using JProfiler, in order to track down where server lag is coming from (I have my suspicions but there are several mods and the only way to *know* is to do a detailed look.) This isn't a request for a tutorial on how to do performance profiling, but rather a request for any tips and guidance from those who are familiar with the Minecraft and Forge codebase, in particular: 1) Aspects of the codebase which are known to be slow but which for one reason or another cannot be optimized (perhaps because doing so would require making very large changes to the base MC codebase), so I don't waste too much time on them 2) Aspects of the codebase which are known to be in dire need of performance attention, and whose fixes would have broad positive impact on enduser experience 3) Gotchas and things to look for which others who have done performance profiling have come across 4) Any other recommendations, particular about the tolerance of the Forge codebase to performance-related pull requests and caveats to that I'm willing to look at MC, Forge and specific mod code - basically wherever the hotspots take me. I'll be looking at memory usage as well (in my previous experiences with games written in managed languages, misuse of memory is one of the most common performance failures and so deserves extra scrutiny.) For the record on my server (which is a fully up-to-date 1.12.2 server) I am running the following major mods, so these will be my initial focus: Tinkers, Immersive Engineering (and related add-ons), Scaling Health, Tough as Nails, Lycanites Mobs, Abyssal Craft, Roots 2, Biomes O' Plenty, Ender Zoo, Baby Mobs My background is primarily C#, so any pointers about relevant differences between Java and .Net which would help my performance investigations would be appreciated. Thanks!