Item Texture

[Blitex]

I making a mod, but when I test the mod the texture doesn't show up.
Here's my ModItems

package net.minecraft.client.renderer.entity.item;


import net.minecraft.client.Minecraft;
import net.minecraft.client.renderer.block.model.ModelResourceLocation;
import net.minecraft.client.renderer.entity.tab.ModelsTab;
import net.minecraft.creativetab.CreativeTabs;
import net.minecraft.item.Item;
import net.minecraft.util.ResourceLocation;
import net.minecraftforge.fml.common.registry.GameRegistry;
import noppes.mpm.MorePlayerModels;

/**
 * Created by Alex Nava on 9/24/2017.
 */
public class ModItems {
    public static Item RiptideSword;

    public static void preInit(){

        RiptideSword = new ItemTutorialItem("Riptide Sword");

        registeritems();
    }

    public static void registeritems() {
        GameRegistry.register(RiptideSword, new ResourceLocation(MorePlayerModels.MODID, "Riptide_Sword"));


    }

    public static void registerRenders(){
        registerRender(RiptideSword);
    }

    public static void registerRender(Item item){
        Minecraft.getMinecraft().getRenderItem().getItemModelMesher().register(item,0,new ModelResourceLocation(MorePlayerModels.MODID + ":" + item.getUnlocalizedName().substring(5),"inventory"));
    }
}

My Item

package net.minecraft.client.renderer.entity.item;

import net.minecraft.entity.player.EntityPlayer;
import net.minecraft.init.Blocks;
import net.minecraft.item.EnumRarity;
import net.minecraft.item.Item;
import net.minecraft.item.ItemStack;
import net.minecraft.util.ActionResult;
import net.minecraft.util.EnumActionResult;
import net.minecraft.util.EnumFacing;
import net.minecraft.util.EnumHand;
import net.minecraft.util.math.BlockPos;
import net.minecraft.util.text.TextComponentString;
import net.minecraft.world.World;
import noppes.mpm.MorePlayerModels;

import java.util.List;

/**
 * Created by Alex Nava on 9/24/2017.
 */
public class ItemTutorialItem extends Item {
    public ItemTutorialItem(String name) {
        setUnlocalizedName(name);
        setCreativeTab(MorePlayerModels.modelsTab);
        setMaxStackSize(1);
    }

    @Override
    public boolean hasEffect(ItemStack stack) {
        return true;
    }

    @Override
    public EnumRarity getRarity(ItemStack stack) {
        return EnumRarity.EPIC;
    }

    @Override
    public void addInformation(ItemStack stack, EntityPlayer playerIn, List<String> tooltip, boolean advanced) {
        tooltip.add("Carried by the mighty Sky or Percy");
        super.addInformation(stack, playerIn, tooltip, advanced);
    }

    @Override
    public ActionResult<ItemStack> onItemRightClick(ItemStack itemStackIn, World worldIn, EntityPlayer player, EnumHand hand) {
        return super.onItemRightClick(itemStackIn, worldIn, player, hand);
    }

    @Override
    public EnumActionResult onItemUse(ItemStack stack, EntityPlayer playerIn, World worldIn, BlockPos pos, EnumHand hand, EnumFacing facing, float hitX, float hitY, float hitZ) {
    if (worldIn.getBlockState(pos).getBlock()== Blocks.GRASS){
        worldIn.setBlockState(pos, Blocks.DIAMOND_BLOCK.getDefaultState());
        return EnumActionResult.SUCCESS;
    }
        return EnumActionResult.PASS;
    }
}

And my JSON

{
  "parent": "item/handheld",
  "textures": {
    "layer0": "moreplayermodels:items/RIPTIDESWORD"
  }
}

 

[jabelar]

The most important thing is actually your file names and locations of your assets. Also, I know that previously it was a bad idea to use upper case letters in any of your registry names or asset file names. So you need to:

 

change Riptide_Sword to riptide_sword and change RIPTIDESWORD to riptidesword and make sure all your file names match these as well. If you're still having problems after that you need to post a screen shot of your assets directory so we can see all the file names and locations.

 

Also, you are probably getting warntings in the console about missing models or textures so you should post the console log as well.

[Blitex]

57 minutes ago, jabelar said:

The most important thing is actually your file names and locations of your assets. Also, I know that previously it was a bad idea to use upper case letters in any of your registry names or asset file names. So you need to:

 

change Riptide_Sword to riptide_sword and change RIPTIDESWORD to riptidesword and make sure all your file names match these as well. If you're still having problems after that you need to post a screen shot of your assets directory so we can see all the file names and locations.

 

Also, you are probably getting warntings in the console about missing models or textures so you should post the console log as well.

Ok I will do that.

[Draco18s]

5 hours ago, Blitex said:

Minecraft.getMinecraft().getRenderItem().getItemModelMesher().register(item,0,new ModelResourceLocation(MorePlayerModels.MODID + ":" + item.getUnlocalizedName().substring(5),"inventory"));

OH MY GOD.

 

1) use the ModelRegistryEvent to register your models (where are you even calling registerRenders()?)

2) use ModelLoader.setCustomModelResourceLocation(), ModelMesher has been the wrong way to do things for over a year.

3) use getRegistryName(), not getUnlocalizedName().substring(5), this has been the wrongest way to do things for almost two years.

4) this is client-only code and you have it in a common class, this will crash the dedicated server, this has been wrong since forever.

5 hours ago, Blitex said:

GameRegistry.register(RiptideSword, new ResourceLocation(MorePlayerModels.MODID, "Riptide_Sword"));

What version are you even developing for? you should be using the RegistryEvent.Register<Item> event to register items, this has been true for a year.

Also, use setRegistryName() instead.

[Blitex]

14 minutes ago, Draco18s said:

OH MY GOD.

 

1) use the ModelRegistryEvent to register your models (where are you even calling registerRenders()?)

2) use ModelLoader.setCustomModelResourceLocation(), ModelMesher has been the wrong way to do things for over a year.

3) use getRegistryName(), not getUnlocalizedName().substring(5), this has been the wrongest way to do things for almost two years.

4) this is client-only code and you have it in a common class, this will crash the dedicated server, this has been wrong since forever.

What version are you even developing for? you should be using the RegistryEvent.Register<Item> event to register items, this has been true for a year.

Also, use setRegistryName() instead.

I am making a mod for 1.10.2 and I was just following a YouTube tutorial made 11 months ago 

Edited September 26, 2017 by Blitex

[MrBendelScrolls]

1 hour ago, Blitex said:

I am making a mod for 1.10.2 and I was just following a YouTube tutorial made 11 months ago 

Sadly, all the YT tutorials are messy outdated crap. Try to google for some text ones, but make sure that creators know what they're doing.

As for an example, you can look at how my new mod does it.

I'm not pretending that it's the 'right' or 'good' way, but by far the most readable that I've seen.

[jabelar]

I have to say that although I agree modders have to keep up to date, it is also very difficult to keep up with all the changes. For example, I was looking at some code for a fairly recent mod by another strong modder and his item model implemented IModel, ICustomModelLoader, and IRetexture and the last two were not in my class path. I did some digging and it looks like those interfaces were absorbed directly into IModel so you don't have to implement all three. But these changes just happened going from 1.11 (his code) and 1.12.

 

As someone who writes tutorials to help people it is becoming almost impossible to keep tutorials up to date. For example, over past couple years custom item models have gone from using item mesher, being registered in pre-init etc. to now using JSON with IModel and being registered in a combination of item registry, model registry and model bake event. Literally 1.9 is different from 1.10 from 1.11 to 1.12 ...

 

In other words, all the really good tutorials and all the github repositories out there are all getting outdated about every six months and there is no easy way for someone who is new, or someone who comes back to modding occasionally, to sort it all out.

 

Furthermore, updating my existing mods is becoming a full time job for me. For example, I just ported my entity-based mods to 1.12.1 and now I see pull requests where they are about to change the entity registration scheme. The IEEPs became capabilities, all the achievements have become advancements, etc. 

 

So honestly giving someone a hard time for using a one year old approach, or calling tutorials out there "outdated crap" I think isn't very fair. Forge is becoming extremely "unstable" -- I don't mean buggy, just that the API is changing rapidly. And frankly in programming an API that changes rapidly is a bad thing in terms of maintainability.

 

This is causing real trouble because all the kids I ask about which version of Minecraft they use are saying 1.7.10. That seems to have been the golden age for mods. In particular my kids seem to like the Morph mod. It is creating a situation where it is difficult for people to find a combination of Minecraft and mods that has everything they like. Having colors and parrots isn't enough for people to give up their favorite mods...If you look at the Minecraft Forum Modification Development forum you'll see that almost half the question are from people still developing for 1.7.10.

Edited September 26, 2017 by jabelar

[Cloudy]

Whilst from time to time Forge does change how they do things - on major versions, over a year apart (as they do it on breaking Mojang changes), the changes made aren't Forges fault. Forge is an API layer on top of Mojang code - and it is Mojang code which keeps changing. Forge just has to adapt to the new way Mojang do things. 

 

It's just the way of modding - there can't be a 100% stable API, but forge tries its best.

[Blitex]

15 minutes ago, Cloudy said:

Whilst from time to time Forge does change how they do things - on major versions, over a year apart (as they do it on breaking Mojang changes), the changes made aren't Forges fault. Forge is an API layer on top of Mojang code - and it is Mojang code which keeps changing. Forge just has to adapt to the new way Mojang do things. 

 

It's just the way of modding - there can't be a 100% stable API, but forge tries its best.

 

5 hours ago, jabelar said:

I have to say that although I agree modders have to keep up to date, it is also very difficult to keep up with all the changes. For example, I was looking at some code for a fairly recent mod by another strong modder and his item model implemented IModel, ICustomModelLoader, and IRetexture and the last two were not in my class path. I did some digging and it looks like those interfaces were absorbed directly into IModel so you don't have to implement all three. But these changes just happened going from 1.11 (his code) and 1.12.

 

As someone who writes tutorials to help people it is becoming almost impossible to keep tutorials up to date. For example, over past couple years custom item models have gone from using item mesher, being registered in pre-init etc. to now using JSON with IModel and being registered in a combination of item registry, model registry and model bake event. Literally 1.9 is different from 1.10 from 1.11 to 1.12 ...

 

In other words, all the really good tutorials and all the github repositories out there are all getting outdated about every six months and there is no easy way for someone who is new, or someone who comes back to modding occasionally, to sort it all out.

 

Furthermore, updating my existing mods is becoming a full time job for me. For example, I just ported my entity-based mods to 1.12.1 and now I see pull requests where they are about to change the entity registration scheme. The IEEPs became capabilities, all the achievements have become advancements, etc. 

 

So honestly giving someone a hard time for using a one year old approach, or calling tutorials out there "outdated crap" I think isn't very fair. Forge is becoming extremely "unstable" -- I don't mean buggy, just that the API is changing rapidly. And frankly in programming an API that changes rapidly is a bad thing in terms of maintainability.

 

This is causing real trouble because all the kids I ask about which version of Minecraft they use are saying 1.7.10. That seems to have been the golden age for mods. In particular my kids seem to like the Morph mod. It is creating a situation where it is difficult for people to find a combination of Minecraft and mods that has everything they like. Having colors and parrots isn't enough for people to give up their favorite mods...If you look at the Minecraft Forum Modification Development forum you'll see that almost half the question are from people still developing for 1.7.10.

Thanks for your relies it really helps!