Another clueless modder with missing item textures

[StoneWolf]

I do know that there are already plenty of topics concerning missing item textures. Sadly, they were of little help for me, primarily as you do not get to see the end result. Therefore I would gladly like if someone could take a small peek at my code over at Github (link below).

 

https://github.com/TheStoneWolf/StoneWolf-s-Roleplay-Mod-MC

 

As you can see by the topic subject the texture in question, cookedEgg, is missing and while the game says that there is a crash it does not specify what has actually caused the crash. From what I can tell there is no problem with the item itself but rather with how the model are added. That is about all of the relevant information I can come up with at the moment since I have been unable to discern little about what is going on (crash logs sure are very useful).

 

While we are at it, when uploading my mod to Github I somehow ended up with all of my code being in a extra folder as you will notice if you see my project on Github. Would anyone like to share their insight on how this might have happened and does this represent in any way a problem? If so, what can I do to fix it?

[Draco18s]

Well I can tell you that you made a complete joke of your proxy system.

 

1) You do not need a separate "ServerProxy" as either things are common or client-only.

2) You put the common half of things in the common proxy and then the client-only stuff in your main mod class!

 

Anyway, your issue is using ModelMesher.  You should be using

ModelLoader.setCustomModelResourceLocation

, which needs to be called during preInit.

 

I recommend taking a look at my library proxies:

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/EasyRegistry.java

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java

 

It encapsulates the required actions such that it works similar to the 1.7 method of registering blocks and items.

[StoneWolf]

I have been doing my best on trying to do as you specify though I got to admitt that I am a bit lost on what exactly you want me to do. The "ServerProxy" is gone and I have also uppdated Github with the latest code which is something I forgot to do before.

 

To begin with, you talk about tips on how to register the item but was not the texture missing the issue or are the two correlated? From what I know the registration seems to work fine though you definitely know better than me in that regard. Is the problem that I register the item with the method in "ModItems" which is called by the main mod class (preInit method)?

 

Anyhow, thank you for the help, it really is a step in the right direction!

[Draco18s]

I have been doing my best on trying to do as you specify though I got to admitt that I am a bit lost on what exactly you want me to do. The "ServerProxy" is gone and I have also uppdated Github with the latest code which is something I forgot to do before.

 

Looks much better, but now your problem is that you're never calling proxy.preInit

Things should work at this point, but the idea of the proxy having init/preint/postinit functions is silly.

 

For one, it shouldn't need the init event directly, the only thing that matters is when the registration methods are invoked (which at this point is always pre-init.

 

To begin with, you talk about tips on how to register the item but was not the texture missing the issue or are the two correlated?

 

Sort of yes.

There are things that you do during registration that affect missing textures.

i.e. ModelMesher isn't preferred because it gets janky if done wrong, hence the recommendation to use ModelLoader

Or the registration name being messed up/not matching.

 

The reason I suggest the way I've set up my files is that it doesn't require that you do this in your client proxy:

ModelLoader.setCustomModelResourceLocation(ModItems.item1, ...)
ModelLoader.setCustomModelResourceLocation(ModItems.item2, ...)
ModelLoader.setCustomModelResourceLocation(ModItems.item3, ...)
ModelLoader.setCustomModelResourceLocation(ModItems.item4, ...)

 

But rather ModelLoader.setCustomModel is invoked as part of the registration.  Like this:

		item1 = new BlockHardIron();
	EasyRegistry.registerItem(item1, "hardiron");
	item2 = new BlockHardIron();
	EasyRegistry.registerItem(item2, "hardiron");

It also means I don't need a .setRegistryName or .setUnlocalizedName in my item class.

 

Which is very similar to how it was done in 1.7:

 

		item1 = new BlockHardIron();
	GameRegistry.registerItem(item1, "hardiron");
	item2 = new BlockHardIron();
	GameRegistry.registerItem(item2, "hardiron");

 

The various registerItem and registerBlock methods I have all take different paths depending on what the "goal" is (item, item with variants, block (no item), block with item, block with custom ItemBlock...) but all make sure that everything that needs to happen gets done.  I don't have to think about it and remember "oh yes, I need to loop through the variants and register an item model for each of these..." it's handled for me.  .registerItemWithVariants(...)

[StoneWolf]

It worked! Thank you for the help, if it were not for you I would have given up for sure. If I could only find the place where the screenshots are found I would be able to show you the now fully functioning textures. They may not be pretty but at least they work.

 

There is one small thing though. The game still reports that there is a crash (which obviously don't exist or at least not in the way I have experienced them before) but without any sort of crashlog and with only a hint that it has something to do with "Loading screen debug info". The mod works as far as I can tell but I am a tad worried that this might turn into a real problem. Is this a valid concern?

 

Edit: I forgot to ask, is there even any benefit in dividing the different method calls between different proxies or even having proxies at all(excluding differing between clientside and all that in the main mod class)? Even if there may not be one for me right now will this change going onwards?

[Draco18s]

It worked! Thank you for the help, if it were not for you I would have given up for sure. If I could only find the place where the screenshots are found I would be able to show you the now fully functioning textures.

 

[forge dir]/run/screenshots

 

Edit: I forgot to ask, is there even any benefit in dividing the different method calls between different proxies or even having proxies at all(excluding differing between clientside and all that in the main mod class)? Even if there may not be one for me right now will this change going onwards?

 

You need a client proxy in order to register any rendering.  Other than that, no you don't need a proxy.

I set my registration up via proxies so I could have a one-function-call "do everything" in my main mod class.