Jump to content

Recommended Posts

Posted

Since i updated my workspace to 1.12 and updated to the new registering. All my blocks do not render their item.

If you place them down they are fine but in any inventory or when throwing away it is a purple-black square.

I saw in my log they are all looking for a variant "inventory". Do they need an "inventory" variant now? In 1.11.2 everything worked fine.

Has something changed about this?

Posted

This is how i registered the renders in 1.11.2:

	private static void registerMetaRender(Block block, int meta, String variant){
		ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(block), meta, new ModelResourceLocation(block.getRegistryName(),variant));	
	}
	private static void registerRender(Block block, String variant){
		ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(block), 0, new ModelResourceLocation(block.getRegistryName(),variant));
		}
	private static void registerRender(Block block){
		ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(block), 0, new ModelResourceLocation(block.getRegistryName(),"inventory"));
		}
	private static void registerItemRender(Item item){
		ModelLoader.setCustomModelResourceLocation(item, 0, new ModelResourceLocation(item.getRegistryName(),"inventory"));
		}

and i use it like this:

registerMetaRender(chalkstone,0,"type=raw");
registerMetaRender(chalkstone,1,"type=smooth");
registerMetaRender(chalkstone,2,"type=bricked");

this is how my blockstate file looks like:

 

{
    "forge_marker": 1,
    "defaults": {
        "model": "minecraft:cube_all"
    },
    "variants": {
        "type": {
            "raw": {
                "textures": {
                    "all": "tem:blocks/chalkstone"
                }
            },
            "smooth": {
                "textures": {
                    "all": "tem:blocks/smooth_chalkstone"
                }
            },
            "bricked": {
                "textures": {
                    "all": "tem:blocks/bricked_chalkstone"
                }
            }
        }
    }
}

 

Posted

It is in a method called

public static void registerRenders(){}

Wich is in the ModBlocks class. Yes i know you are going to say it doesn't belong there. Eventually i will move it. It has never been a problem, because i call this method only in the clientproxy. Having everything in my ModBlocks class gives me a better oversight. That's my opinion. Since that class doesn't do anything on its own, why not.

Posted

Nvm, lol! Turn out i forgot something to do in my clientproxy:

public class ClientProxy implements CommonProxy{
	
	@Override
	public void preInit() {
		
		NetworkRegistry.INSTANCE.registerGuiHandler(Tem.instance, new ModGuiHandler());
		if (ModConfig.load_module_woodchests==true){
		ClientRegistry.bindTileEntitySpecialRenderer(TileEntityModChest.class, new ModTERChest());
		ClientRegistry.bindTileEntitySpecialRenderer(TileEntityModChestBOP.class, new ModTERChestBOP());
		ClientRegistry.bindTileEntitySpecialRenderer(TileEntityModChestBOP2.class, new ModTERChestBOP2());
		}
		if (ModConfig.load_module_metalchests==true){
		ClientRegistry.bindTileEntitySpecialRenderer(TileEntityIronChest.class, new ModTERIronChest());
		}
		if (ModConfig.load_module_voidchest==true){
		ClientRegistry.bindTileEntitySpecialRenderer(TileEntityVoidChest.class, new ModTERVoidChest() );
		}
		//ModBlockStateMapper.registerAllBlocks();
		//ClientRegistry.bindTileEntitySpecialRenderer(TileEntityBirchChest.class, new ModTERChest());
		ModItems.registerRenders();
		//ModBlocks.registerRenders();
		//if(Loader.isModLoaded("biomesoplenty")){
			//ModBlocksBOP.registerRenders();
			//ModItemsBOP.registerRenders();
		//}
		System.out.println("renders have been registered");
	}	
}

I forgot those // . Works fine now. Thank you anyway.

Posted
3 minutes ago, diesieben07 said:

It's not about opinion. Your code is broken. You can't be of the opinion that it is not.

 

If you call this method in your client proxy, that is a problem, unless you have event handlers in your client proxy. Models must be registered in ModelRegistryEvent.

Can you explain this better? Why is it a problem to call it in my client proxy? I am really confused now, because it is working all fine now.

Posted
1 minute ago, diesieben07 said:

The server will load your ModBlocks class, see references to client-only classes (ModelLoader) in the code and crash.

I know you have said that alot of times already but i have run my mod on my server for a while in 1.7.10, 1.10.2 and 1.11.2 and it never crashed.

I also see no logic why the server will load my ModBlocks class and run all the methods inside it while it hasn't asked to do so. Ofcourse you have way more experience and

knowledge with these things, but then again why does it not crash the server anyway?

7 minutes ago, diesieben07 said:

Do not register models in preInit. Use the event.

How i do that? Where do i call the event?

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • I tried do download the essential mod to my mod pack but i didnt work. I paly on 1.21 and it should work. I use neoforge for my modding. The weird things is my friend somehow added the mod to his modpack and many others that I somehow can´t. Is there anything i can do? 
    • Thanks, I've now installed a slightly newer version and the server is at least starting up now.
    • i have the same issue. Found 1 Create mod class dependency(ies) in createdeco-1.3.3-1.19.2.jar, which are missing from the current create-1.19.2-0.5.1.i.jar Found 11 Create mod class dependency(ies) in createaddition-fabric+1.19.2-20230723a.jar, which are missing from the current create-1.19.2-0.5.1.i.jar Detailed walkthrough of mods which rely on missing Create mod classes: Mod: createaddition-fabric+1.19.2-20230723a.jar Missing classes of create: com/simibubi/create/compat/jei/category/sequencedAssembly/JeiSequencedAssemblySubCategory com/simibubi/create/compat/recipeViewerCommon/SequencedAssemblySubCategoryType com/simibubi/create/compat/rei/CreateREI com/simibubi/create/compat/rei/EmptyBackground com/simibubi/create/compat/rei/ItemIcon com/simibubi/create/compat/rei/category/CreateRecipeCategory com/simibubi/create/compat/rei/category/WidgetUtil com/simibubi/create/compat/rei/category/animations/AnimatedBlazeBurner com/simibubi/create/compat/rei/category/animations/AnimatedKinetics com/simibubi/create/compat/rei/category/sequencedAssembly/ReiSequencedAssemblySubCategory com/simibubi/create/compat/rei/display/CreateDisplay Mod: createdeco-1.3.3-1.19.2.jar Missing classes of create: com/simibubi/create/content/kinetics/fan/SplashingRecipe
    • The crash points to moonlight lib - try other builds or make a test without this mod and the mods requiring it
    • Do you have shaders enabled? There is an issue with the mod simpleclouds - remove this mod or disable shaders, if enabled  
  • Topics

  • Who's Online (See full list)

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.