Corey

Yes, and that's what I did to fix the issue, but I think this might be an oversight on Forge's part

I was going to use ObjectHolders in my code to grab a couple items I needed to register models for. It's client-only code, and stripped from the dedicated server. The ObjectHolder injection still tries to do its thing and crashes. Is there a way around this or can I not use ObjectHolders in this situation? @SideOnly(Side.CLIENT) @Mod.EventBusSubscriber(value = Side.CLIENT, modid = GradientMod.MODID) public final class ModelManager { ... @GameRegistry.ObjectHolder("gradient:firepit_discriminator") private static final Item FIREPIT_DISCRIMINATOR = null; @GameRegistry.ObjectHolder("gradient:grinding_discriminator") private static final Item GRINDING_DISCRIMINATOR = null; @GameRegistry.ObjectHolder("gradient:mixing_discriminator") private static final Item MIXING_DISCRIMINATOR = null; ... } [11:42:48] [Server thread/ERROR] [minecraft/MinecraftServer]: Encountered an unexpected exception java.lang.RuntimeException: java.lang.ClassNotFoundException: lordmonoxide.gradient.ModelManager at net.minecraftforge.registries.ObjectHolderRegistry.scanTarget(ObjectHolderRegistry.java:110) ~[ObjectHolderRegistry.class:?] at net.minecraftforge.registries.ObjectHolderRegistry.findObjectHolders(ObjectHolderRegistry.java:80) ~[ObjectHolderRegistry.class:?] at net.minecraftforge.fml.common.Loader.preinitializeMods(Loader.java:624) ~[Loader.class:?] at net.minecraftforge.fml.server.FMLServerHandler.beginServerLoading(FMLServerHandler.java:99) ~[FMLServerHandler.class:?] at net.minecraftforge.fml.common.FMLCommonHandler.onServerStart(FMLCommonHandler.java:333) ~[FMLCommonHandler.class:?] at net.minecraft.server.dedicated.DedicatedServer.init(DedicatedServer.java:128) ~[DedicatedServer.class:?] at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:552) [MinecraftServer.class:?] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181] Caused by: java.lang.ClassNotFoundException: lordmonoxide.gradient.ModelManager at net.minecraft.launchwrapper.LaunchClassLoader.findClass(LaunchClassLoader.java:191) ~[launchwrapper-1.12.jar:?] at java.lang.ClassLoader.loadClass(ClassLoader.java:424) ~[?:1.8.0_181] at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:1.8.0_181] at java.lang.Class.forName0(Native Method) ~[?:1.8.0_181] at java.lang.Class.forName(Class.java:348) ~[?:1.8.0_181] at net.minecraftforge.registries.ObjectHolderRegistry.scanTarget(ObjectHolderRegistry.java:104) ~[ObjectHolderRegistry.class:?] ... 7 more Caused by: net.minecraftforge.fml.common.asm.ASMTransformerWrapper$TransformerException: Exception in class transformer net.minecraftforge.fml.common.asm.transformers.SideTransformer@70101687 from coremod FMLCorePlugin at net.minecraftforge.fml.common.asm.ASMTransformerWrapper$TransformerWrapper.transform(ASMTransformerWrapper.java:260) ~[forgeSrc-1.12.2-14.23.5.2772.jar:?] at net.minecraft.launchwrapper.LaunchClassLoader.runTransformers(LaunchClassLoader.java:279) ~[launchwrapper-1.12.jar:?] at net.minecraft.launchwrapper.LaunchClassLoader.findClass(LaunchClassLoader.java:176) ~[launchwrapper-1.12.jar:?] at java.lang.ClassLoader.loadClass(ClassLoader.java:424) ~[?:1.8.0_181] at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:1.8.0_181] at java.lang.Class.forName0(Native Method) ~[?:1.8.0_181] at java.lang.Class.forName(Class.java:348) ~[?:1.8.0_181] at net.minecraftforge.registries.ObjectHolderRegistry.scanTarget(ObjectHolderRegistry.java:104) ~[ObjectHolderRegistry.class:?] ... 7 more Caused by: java.lang.RuntimeException: Attempted to load class lordmonoxide/gradient/ModelManager for invalid side SERVER at net.minecraftforge.fml.common.asm.transformers.SideTransformer.transform(SideTransformer.java:62) ~[forgeSrc-1.12.2-14.23.5.2772.jar:?] at net.minecraftforge.fml.common.asm.ASMTransformerWrapper$TransformerWrapper.transform(ASMTransformerWrapper.java:256) ~[forgeSrc-1.12.2-14.23.5.2772.jar:?] at net.minecraft.launchwrapper.LaunchClassLoader.runTransformers(LaunchClassLoader.java:279) ~[launchwrapper-1.12.jar:?] at net.minecraft.launchwrapper.LaunchClassLoader.findClass(LaunchClassLoader.java:176) ~[launchwrapper-1.12.jar:?] at java.lang.ClassLoader.loadClass(ClassLoader.java:424) ~[?:1.8.0_181] at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:1.8.0_181] at java.lang.Class.forName0(Native Method) ~[?:1.8.0_181] at java.lang.Class.forName(Class.java:348) ~[?:1.8.0_181] at net.minecraftforge.registries.ObjectHolderRegistry.scanTarget(ObjectHolderRegistry.java:104) ~[ObjectHolderRegistry.class:?] ... 7 more

8 gigs is throwing away money unless you're running an insane server... you can easily run sevtech on 3 (as I do), and it has over 200 mods

I'm not 100% sure this works with flowing water, but you could try this... Add an onItemRightClick to your item that does a ray trace like this: final RayTraceResult target = this.rayTrace(world, player, true); // true: useLiquids if(target.typeOfHit != RayTraceResult.Type.BLOCK) { return ActionResult.newResult(EnumActionResult.PASS, itemstack); } // ...

Note: I see IRecipeWrapper has a drawInfo method that allows extra things to be drawn. I tried implementing ICraftingRecipeWrapper on my recipe class, but the vanilla plugin still wraps my recipe in its own wrapper, which doesn't delegate to mine of course. I tried doing the following in my plugin's register method, but my wrapper factory doesn't get called: registry.handleRecipes(CustomRecipeClass.class, recipe -> recipe, GradientRecipeCraftingUid.CRAFTING);

Hi, I'm not sure if asking about help with specific mods is allowed, but I'm having trouble figuring out the documentation for JEI integration. Basically, I have a custom recipe type that extends ShapelessRecipes. It's exactly the same, but adds an extra field that's read out of the json. Because it extends ShapelessRecipes, the recipes are already listen in JEI, great. But I want to render a string on the recipe page based on the field that's read in. My first thought was to extend the vanilla handlers and jack in support that way, but since they aren't part of the JEI API, that doesn't really seem like an option. I'd rather not copy and paste all of the code into my own classes to make the minor changes I need to. Is there any way I can render the extra line of text without doing that?

Awesome, thanks!

My mod generates large veins of ore that can span multiple chunks. I use a deferred generation method that generates the entire vein, but only places the ore that's in loaded chunks, and waits for the other chunks to load before placing their ores. This works great, except setBlockState calls markAndNotifyBlock, which in turn calls updateObservingBlocksAt. If a block is generated on a chunk boundary, updateObservingBlocksAt will cascade into those chunks. I am aware I can prevent updateObservingBlocksAt from being called by passing the flag 0x10, and doing so fixes all instances of cascading chunk gen. All I want to know is if that's safe/desirable during chunk population, or if it may cause problems.

Okay, thanks for the info

I used a standard property. I was under the impression that IUnlistedPropertys couldn't persist data without a tile entity to back them, could you elaborate a bit please?

Hmm, I attempted to go back to using a single block with different blockstates, while using a forge registry for the casts, but Minecraft attempts to create the blockstates during the block registry event, which means that the cast registry would already have to be available. It seems that using a forge registry for this is just impossible.

On a related topic, is GameRegistry.findRegistry the preferred way to access a registry?

@Animefan8888 Future plans for registry reloading is still a much larger issue. You'd have to specify that registry A relies on registry B, and therefore is registry B is reloaded, registry A must be as well... and I'm sure you can see how that'd instantly lead to unresolvable cyclic dependencies

I can appreciate the issues with arbitrary sorting, but I was referring only to being able to say "I need this to be loaded before blocks/items" (ie. three phases instead of two: a-z pre-b/i registries, blocks/items, a-z post-b/i registries)

If that's the only reason, has any thought been put into allowing modders to load specific registries early?

Do you mind elaborating as to why?

Yes, but other mods adding entries to my registries won't be picked up

They are always loaded, but it's coded like this so that adding a new entry into the registry generates blocks, items, etc. automatically. In this instance, the blocks do need a reference to their cast.

I have several old "registries" in my code that I want to convert to IForgeRegistrys. The problem is, my block/item registration relies on these existing, and from what I understand, loading order is always "blocks -> items -> all other registries a-z". Example: I have a list of metal casts, such as for pickaxes and swords. Currently, I iterate over the casts and register one block for each. My block registration relies on the casts already being registered, but there doesn't seem to be a way to control the order in which the registration events are fired. Is there some way around this? It'd make my code a lot cleaner.

No, I mean there is no version of Forge for 1.13 yet, so if you're trying to use an older version of Forge with the new Minecraft client, that's why it isn't working.

Are you trying to use older versions of Forge on Minecraft 1.13...?

I have a custom IBakedModel that delegates all methods except for getQuads to the model that it replaces. It works great aside from two issues: The block break cracks do not render. I've looked at other peoples' custom IBakedModels and it doesn't appear that they have any custom code to render this. Is it supposed to render automatically? When in item form (ie. in a player's hand) the depth buffer doesn't seem to work. The different layers of the model render on top of each other. I'll attach a screenshot for this one. getQuads adds vertices for the block itself on the CUTOUT_MIPPED layer, and vertices for the fluids on the TRANSLUCENT layer. Here's the underlying model:

It was, in fact, a double-registration... after disabling the universal bucket and only registering my own, I was still getting a conflict. I had accidentally registered it with the same name I had used for another block. However, after registering it, I ran into several other issues. Some of the code assumes the universal bucket, and I couldn't seem to get it to actually show up in JEI. I've ended up just using parts of the universal bucket code and its supporting classes, removing all of the special-case handling of vanilla buckets. My final issue now is that I'm having trouble tracking down the code that provides the dynamic textures. Any pointers? Edit: Scratch that, found it. Thanks for your help.

I'll try to reproduce in a minimal environment...

Just checked - I don't see any way it could be getting registered twice. It's being registered during the item registry event, and no other code calls that method. I added logging immediately before the call to register it just in case, and I'm only seeing it logged once. Just realised I forgot to attach the actual stacktrace to my first post... java.lang.RuntimeException: One of more entry values did not copy to the correct id. Check log for details! at net.minecraftforge.registries.ForgeRegistry.sync(ForgeRegistry.java:543) at net.minecraftforge.registries.GameData.loadRegistry(GameData.java:490) at net.minecraftforge.registries.GameData.freezeData(GameData.java:225) at net.minecraftforge.fml.common.Loader.initializeMods(Loader.java:730) at net.minecraftforge.fml.client.FMLClientHandler.finishMinecraftLoading(FMLClientHandler.java:352) at net.minecraft.client.Minecraft.init(Minecraft.java:581) at net.minecraft.client.Minecraft.run(Minecraft.java:421) at net.minecraft.client.main.Main.main(Main.java:118) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at net.minecraft.launchwrapper.Launch.launch(Launch.java:135) at net.minecraft.launchwrapper.Launch.main(Launch.java:28) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at net.minecraftforge.gradle.GradleStartCommon.launch(GradleStartCommon.java:97) at GradleStart.main(GradleStart.java:26) The line pasted in the first post is the last thing logged before the error.