[1.12.1] Help with entity code

[Fijal]

(man,  this forum's recaptcha thing hates me - I must've spent like five minutes trying to get it to work)

 

So, I've been working on my mod, following Shadowfact's, Jabelar's, and McJty's tutorials. I'm at the point where I'm making entities, and it "works", but the texture isn't appearing. I've copied  McJty's tutorial almost word-for-word, it still isn't there. My mob looks like a weird white rectangle (see attachment)

 

All my code is available here

Hope someone can help!

Edited September 10, 2017 by Fijal
added version of minecraft

[jabelar]

I think the problem may be that in your client proxy you don't call the super method for the preinit() method. The way you're doing it you're registering the entity model and renderer on the client but not the entity itself.

[Fijal]

When I do it like this it gives me the error "initModels cannot be resolved or is not a field"

@Override
public void preInit(FMLPreInitializationEvent e) 
{
	super(ModEntities.initModels);
}

 

Sorry if I'm missing something obvious, I'm still kind of new to this.

 

Also, I'm not sure if I should start a individual post for both of these questions, but I have two more. No. 1 is how do I render .OBJ models? Spoiler for no. 2 because it has some code

  Reveal hidden contents

So, I have for separate tabs Items, Blocks, Tools, and Misc. I made a separate modId for each tab, because there was only tab when I used the same modId.

// main modId + modId for creative tab 1
public static final String modId = "wofmc";
// modId for creative tab no. 2
public static final String modId1 = "wofmc1";
// modId for creative tab no. 3
public static final String modId2 = "wofmc2";
// modId for creative tab no. 4
public static final String modId3 = "wofmc3";

 

An example of the tab class:

public class WoFMCTabBlocks extends CreativeTabs 
{
	public WoFMCTabBlocks() 
	{
		super(WoFMC.modId1);
	}

	@Override
	public ItemStack getTabIconItem() 
	{
		return new ItemStack(ModBlocks.oreCopper);
	}
}

Surely there's a more effective way to do this?

 

[jabelar]

  On 9/10/2017 at 3:59 AM, Fijal said:

When I do it like this it gives me the error "initModels cannot be resolved or is not a field"

@Override
public void preInit(FMLPreInitializationEvent e) 
{
	super(ModEntities.initModels);
}

 

Sorry if I'm missing something obvious, I'm still kind of new to this.

Expand  

 

When you call the super method, you do it by passing the parameter through. Since your ClientProxy extends CommonProxy, iyou want to run the CommonProxy preInit() as well to make sure the actual entity is registered on the client. Like this

 

ModEntities.initModels();

super(e);

 

ISo you're passing the event to the common proxy method.

[Fijal]

When I do

@Override 	
public void preInit(FMLPreInitializationEvent e) 	
{ 		
	super(e); 
	ModEntities.initModels(); 
}

It gives me the error "Constructor call must be the first statement in a constructor"

I'm doing this in my common proxy class.

[Draco18s]

  On 9/10/2017 at 4:18 AM, Fijal said:

When I do

@Override 	
public void preInit(FMLPreInitializationEvent e) 	
{ 		
	super(e); 
	ModEntities.initModels(); 
}

It gives me the error "Constructor call must be the first statement in a constructor"

I'm doing this in my common proxy class.

Expand  

Do you know Java?

You don't call super in the super class, you call it in the subclass. i.e. the client proxy.

[jabelar]

Sorry it should actually be 

 

super.preInit(e)

 

You need to call the super method, not the super constructor. Also, you're right it is probably better to call it before the initModels().

[Fijal]

  On 9/10/2017 at 5:23 AM, Draco18s said:

Do you know Java?

You don't call super in the super class, you call it in the subclass. i.e. the client proxy.

Expand  

I haven't taken any courses or anything, but I know some.

  On 9/10/2017 at 4:07 AM, jabelar said:

 

When you call the super method, you do it by passing the parameter through. Since your ClientProxy extends CommonProxy, iyou want to run the CommonProxy preInit() as well to make sure the actual entity is registered on the client. Like this

[...]

ISo you're passing the event to the common proxy method.

Expand  

I just misread this to mean I should place it in the common proxy.

 

  On 9/10/2017 at 5:34 AM, jabelar said:

Sorry it should actually be 

 

super.preInit(e)

 

You need to call the super method, not the super constructor. Also, you're right it is probably better to call it before the initModels().

Expand  

So now my client proxy looks like this,

  Reveal hidden contents

public class ClientProxy extends CommonProxy
{
	@Override
	public void registerItemRenderer(Item item, int meta, String id) 
	{
		ModelLoader.setCustomModelResourceLocation(item, meta, new ModelResourceLocation(WoFMC.modId + ":" + id, "inventory"));
	}	
	
	@Override 	
	public void preInit(FMLPreInitializationEvent e) 	
	{
		super.preInit(e);
		ModEntities.initModels(); 	
	}
}

 

and my common proxy is the same.  There aren't any errors, but it's still a white cube thing.

[Draco18s]

Show your ModEntities class.

 

Also, your common proxy should not be the same. For two reasons: 1, you can't call super from the base class, 2, you shouldn't be registering models in it.

[Fijal]

Here's my ModEntities class

public static void init() 
    {
        // Every entity in our mod has an ID (local to this mod)
        int id = 1;
        EntityRegistry.registerModEntity(new ResourceLocation(WoFMC.modId, "weirdzombie"), EntityWeirdZombie.class, "WeirdZombie", id++, WoFMC.instance, 64, 3, true, 0x996600, 0x00ff00);

        //EntityRegistry.registerModEntity(new ResourceLocation(WoFMC.modId, "weirdzombie"), EntityWeirdZombie.class, "WeirdZombie", id++, WoFMC.instance, 64, 3, true, 0xa699f4, 0xe2defb);

        // Spawn Location
        EntityRegistry.addSpawn(EntityWeirdZombie.class, 100, 100, 100, EnumCreatureType.MONSTER, Biomes.PLAINS, Biomes.ICE_PLAINS, Biomes.DESERT, Biomes.DESERT_HILLS, Biomes.MUTATED_DESERT);

        // Loot Table
        LootTableList.register(EntityWeirdZombie.LOOT);
    }

    @SideOnly(Side.CLIENT)
	public static void initModels() 
    {
        RenderingRegistry.registerEntityRenderingHandler(EntityWeirdZombie.class, RenderWeirdZombie.FACTORY);
    }

 

Also, I meant "the same" as in I hadn't changed anything, not ClientProxy and CommonProxy are identical

[Fijal]

I think the tutorial I used uses CommonProxy as the server proxy.

In the tutorial the code in the main class is

@SidedProxy(serverSide = "com.modname.proxy.CommonProxy", clientSide = "com.modname.proxy.ClientProxy")

Would it make more sense to rename it ServerProxy then? And if so, why do so many tutorials have you make a CommonProxy class?

 

What should I be calling? The only thing in ClientProxy that relates to my entities is

@Override 	
	public void preInit(FMLPreInitializationEvent e) 	
	{
		super.preInit(e);
		ModEntities.initModels(); 	
	}

but that's just loading something in the ModEntities class, I don't see anything to call.

 

Sorry for my obvious ignorance, as you can tell I'm very new to this.

[Fijal]

So, I renamed CommonProxy.class to ServerProxy.class, made a new CommonProxy.class and moved all the stuff in the new ServerProxy.class to CommonProxy.class (which now that I think about it was a waste of time.) and it works now!

 

I'm not sure what did it, but thank you all for the help you gave me!

(also, thanks for not giving up on me because I don't know tons of Java)

 

Now, to figure out how to load .obj models...

Edit: Is it possible to move the spawn egg from the vanilla tab to my own custom one?

Edited September 11, 2017 by Fijal

[jabelar]

  On 9/11/2017 at 12:22 AM, Fijal said:

Edit: Is it possible to move the spawn egg from the vanilla tab to my own custom one?

Expand  

If you want to move all spawn eggs then you can just call the public method  Items.SPAWN_EGG.setCreativeTab(your custom tab here). 

 

However, I assume that you just want to do that only for spawn eggs for your custom entities. There might be an easy way to do it but as far as I can tell the EntityRegistry spawn eggs all use the vanilla instance, so I've always done it by making my own custom spawn egg that extends the vanilla ItemMonsterPlacer. I haven't done that in recent versions but "in the old days" there was a time that you had to make custom spawn eggs for your custom entities before they added the hooks. I still have some tutorial information posted at http://jabelarminecraft.blogspot.com/p/minecraft-forge-1721710-creating-custom.html

 

The code was posted for version 1.7.10 so you might need to do a bit of updating but I think the overall concept should still work.

Edited September 11, 2017 by jabelar

[Draco18s]

  On 9/11/2017 at 12:22 AM, Fijal said:

So, I renamed CommonProxy.class to ServerProxy.class, made a new CommonProxy.class and moved all the stuff in the new ServerProxy.class to CommonProxy.class (which now that I think about it was a waste of time.) and it works now!

Expand  

Move everything in CommonProxy.class to your main mod class. Then retype the CommonProxy to an interface.

[Fijal]

  On 9/11/2017 at 1:30 AM, Draco18s said:

Move everything in CommonProxy.class to your main mod class. Then retype the CommonProxy to an interface.

Expand  

Got it. Originally I made it as an interface, like you said, but it gave me a bunch of errors, so I changed it to a .class. I shall fix that.

 

  On 9/11/2017 at 12:53 AM, jabelar said:

If you want to move all spawn eggs then you can just call the public method  Items.SPAWN_EGG.setCreativeTab(your custom tab here). 

 

However, I assume that you just want to do that only for spawn eggs for your custom entities. There might be an easy way to do it but as far as I can tell the EntityRegistry spawn eggs all use the vanilla instance, so I've always done it by making my own custom spawn egg that extends the vanilla ItemMonsterPlacer. I haven't done that in recent versions but "in the old days" there was a time that you had to make custom spawn eggs for your custom entities before they added the hooks. I still have some tutorial information posted at http://jabelarminecraft.blogspot.com/p/minecraft-forge-1721710-creating-custom.html

 

The code was posted for version 1.7.10 so you might need to do a bit of updating but I think the overall concept should still work.

Expand  

I'll look into that! Thanks

Edited September 11, 2017 by Fijal

[Fijal]

  On 9/11/2017 at 1:30 AM, Draco18s said:

Move everything in CommonProxy.class to your main mod class. Then retype the CommonProxy to an interface.

Expand  

I did this and now it's throwing me a bunch of errors. Here's what I did:

• Moved the contents of CommonProxy.class to Main.class
• In my CommonProxy.class I changed class to interface
• Then I changed Client and Server Proxy to implement instead of extend
• After I saved everything, A few errors popped up. I'm listing them in a spoiler so they save space

  Reveal hidden contents

proxy.preInit(event); proxy.init(event); and proxy.postInit(event); all throw the error their respective versions of "The method postInit(FMLInitializationEvent) is undefined for the type CommonProxy". Do I need to call these in my main class? The solution suggested by Eclipse is "Create method init(FMLInitializationEvent) in type CommonProxy" If I do that the error goes away, however in ClientProxy,
 

public void preInit(FMLPreInitializationEvent e)
    {

    }

 gives me the error "The method preInit(FMLPreInitializationEvent) of type ClientProxy must override or implement a supertype method". Which is to be expected, since I don't have it there anymore. If I add it to CommonProxy.interface it errors as "Abstract methods do not specify a body". Again, to be expected I suppose.

 

There are quite a few more errors, but I'm not going to list them here unless you want me too.

 

All of that stems from the fact CommonProxy is now a interface, I think. Are you sure it should be an interface? One of the tutorials (MrCrayfish's) made it as one, but none of the others I've seen have.

 

[Splashsky]

What I've ended up doing was create the CommonProxy as an interface.

public interface CommonProxy
{
    void preInit();
    void init();
    void postInit();

    void registerItemRender(Item item, int meta, String id);
}

 

I then proceed to put the client logic into the ClientProxy.

public class ClientProxy implements CommonProxy
{
    @Override
    public void preInit()
    {
    }

    @Override
    public void init()
    {
    }

    @Override
    public void postInit()
    {
    }

    @Override
    public void registerItemRender(Item item, int meta, String id)
    {
        ModelLoader.setCustomModelResourceLocation(
                item,
                meta,
                new ModelResourceLocation(Reference.PREFIX + id, "inventory")
        );
    }
}

 

And then, finally, server stuff!

public class ServerProxy implements CommonProxy
{
    @Override
    public void preInit()
    {
    }

    @Override
    public void init()
    {
    }

    @Override
    public void postInit()
    {
    }

    @Override
    public void registerItemRender(Item item, int meta, String id)
    {
    }
}

 

Granted, Draco and jabelar know a lot more than me, but this is my current setup. Not much different then just a ClientProxy and ServerProxy.

 

Though, I probably should be implementing the FMLInitializationEvent thingies....

Edited September 11, 2017 by Splashsky

[Draco18s]

I still go by the ClientProxy extends CommonProxy setup myself. <_<

 

Mind, that came in handy when I built my EasyRegistry (they act as a common and client proxy, with the common actually containing a large portion of code, but code that makes no sense to be anywhere else).

[Fijal]

  On 9/11/2017 at 3:17 AM, Splashsky said:

Granted, Draco and jabelar know a lot more than me, but this is my current setup. Not much different then just a ClientProxy and ServerProxy.

 

Though, I probably should be implementing the FMLInitializationEvent thingies....

Expand  

Yeah, I'm 100% sure they know more than me

 

Well, it works for me! I tried to add the FMLInitializationEvent things, but it gave some errors.

 

Edit: Hmm I can't find how to quote someone when editing a post. So, this is directed at Draco. If CommonProxy is an interface don't you have to implement it instead of extend?

 

Edited September 11, 2017 by Fijal

[Draco18s]

  On 9/11/2017 at 3:31 AM, Fijal said:

Edit: Hmm I can't find how to quote someone when editing a post. So, this is directed at Draco. If CommonProxy is an interface don't you have to implement it instead of extend?

Expand  

Yes.

[Fijal]

Which is what I thought. But if you believe ClientProxy should extend, not implement CommonProxy, why'd you direct me to make CommonProxy an interface?

 

Eh, I suppose it doesn't matter.

[Draco18s]

  On 9/11/2017 at 2:50 PM, Fijal said:

Which is what I thought. But if you believe ClientProxy should extend, not implement CommonProxy, why'd you direct me to make CommonProxy an interface?

Expand  

FFS. They are two different ways of doing the same thing. You either make a common proxy (which is used server side) and extend it for the client proxy, or you make the common proxy an interface which the server and client proxy implement.

 

I never said "I believe ClientProxy should extend" I said I still do it this way, even though it is bad.

[jabelar]

  On 9/11/2017 at 2:50 PM, Fijal said:

Which is what I thought. But if you believe ClientProxy should extend, not implement CommonProxy, why'd you direct me to make CommonProxy an interface?

 

Eh, I suppose it doesn't matter.

Expand  

In coding there are many ways to achieve the same thing, and some of it is just preference and some of it is situational. Regarding preference, as diesieben07 mentioned earlier there is some argument remaining about the best way to do this and the terminology but most people have found a way that works for them and stuck with it.

 

In the end, the main point is that the proxy annotation allows you to point to a class that is loaded differently depending on which logical side is running. It is particularly useful for code that has the name but you want to operate differently on each side, because if there is code that is only run on one side you can just annotate it directly (that is why you also see methods, fields and classes with sided annotation sprinkled through other classes). The FML Lifecycle events (a.k.a. pre-init, init, post-init, etc.) are commonly ones that you collect in the proxy although some people find cases where they have other custom methods they want to run differently on each side and so also collect those there.

 

From there you can do many things so long as you collect all your sided code accordingly and respect the regular rules of Java inheritance. 

 

If it works, it is valid. Whether it is the best way depends on philosophy and situation. 

[Fijal]

  On 9/11/2017 at 3:36 PM, Draco18s said:

I never said "I believe ClientProxy should extend" I said I still do it this way, even though it is bad.

Expand  

ohhhh so you did. My bad, sorry!

 

@jabelar ah, got it. That makes sense

[Dustpuppy]

This into your common proxy pre init.

        int id = 1;
        EntityRegistry.registerModEntity(EntityWeirdZombie.class, "WeirdZombie", id++, TheWizardMod.instance, 64, 3, true, 0x996600, 0xff00ff);
        // We want our mob to spawn in Plains and ice plains biomes. If you don't add this then it will not spawn automatically
        // but you can of course still make it spawn manually
        EntityRegistry.addSpawn(EntityWeirdZombie.class, 100, 3, 5, EnumCreatureType.MONSTER, Biomes.PLAINS, Biomes.ICE_PLAINS);

 

And this into your client pre init

      RenderingRegistry.registerEntityRenderingHandler(EntityWeirdZombie.class, RenderWeirdZombie.FACTORY);

 

Don't forget, that the zombie will only spawn in plains and icy biomes then, if you don't extend it.

And change the instance to yours.

 

I followed the same tutorials like you, i think.