[1.12] Registering for Dummies [Solved]

[ConfusedMerlin]

Well... good Evening?

 

I was drawn here because I might be too stupid to understand this Doc of yours: Doc about Registries. And while I do know a tiny bit about Java (at least Oracle thinks so), I feel pretty confused at the moment (see nickname *cough*) 

 

Thing is.... all guides out there are for older or outright ancient versions of Minecraft - following them step by step does work to a given degree, but as soon as they start registering their Tutorial-Object and blocks and whatnots, they use GameRegistry.registerItem() to do so. But I'm afraid that option is no longer valid. I got the forge beta for 1.12 (because, I'm feeling like that Minecraft 1.14 will be released more early than everything I could do, and I need to learn this sooner or later anyway), had some "fun" setting up IntelliJ (until I found a topic form Mr diesieben07 here out of the forum) and then... well... Minecraft starts, my empty mod shows up inside the mods list (yay) but then... one might want to have his mod do more than just showing up in a list. 

 

So I got a dumb Item that needs to get registered. At the moment its just this: 

import net.minecraft.creativetab.CreativeTabs;
import net.minecraft.item.Item;
import net.minecraftforge.event.RegistryEvent;

/**
 * Created by Seine Eiligkeit on 27.06.2017.
 */
public final class ModItem extends Item {

    public static Item tutorialItem;

    public static final void init(){
        tutorialItem = new Item();

        tutorialItem.setUnlocalizedName("tutorialItem");
        tutorialItem.setRegistryName("tutorialItem");
        tutorialItem.setCreativeTab(CreativeTabs.MISC);

        Item.

    }
}

 

I know, some stuff still is missing (or needs to get removed, like the orphan "Item" I forget to delete), but anyway: Where Item. is placed at, all Tutorials I found went strait for GameRegistry.registerItem(). 

And now... lets see... I may need to do this, according to the Doc you wrote down:

    @SubscribeEvent
    public void registerItem(RegistryEvent.Register<Item> event) {
        event.getRegistry().register(tutorialItem);
    }

But WHERE do I put this? I'm a bit certain that it need to be placed somewhere in the commonproxy (because all participants need to get it registered), or am I wrong?

Is it a method like the pre-, past- and -init()  Methods one should put there? I tried this, having my ModItem return itself as a Singleton when called using init(), but is that correct? At least minecraft didn't crash, or throw an exception and a infinite loop wasn't created either (the only thing I can do is creating unexpected infinite loops). 

 

So did I use the correct approach, or am I wrong? You know, there was a System.out.println("wuhu") inside the registerItem() some time ago, but it didn't show up in the console anyway.

 

I looked for code examples, but all I found was using the GameRegistry.registerwhatever(), and non of these where about 1.12. So my options came down to ask someone who actually does know how to do this. And, I feel sorry to say this, but your Doc looks a bit like the stuff my boss at work usually creates for documentation purposes: great for people which actually did this somehow many times and need a mind lift to get on track. But I didn't see a minecraft-mod from the inside until now...and I'm pretty confused.

 

So: Where do I need to put this, and what's up with with the @ObjectHolder I red about?

 

Greetings, Confused Merlin

Edited July 1, 2017 by ConfusedMerlin
It was solved, I think

[Jay Avery]

12 minutes ago, ConfusedMerlin said:

    @SubscribeEvent
    public void registerItem(RegistryEvent.Register<Item> event) {
        event.getRegistry().register(tutorialItem);
    }

But WHERE do I put this? I'm a bit certain that it need to be placed somewhere in the commonproxy (because all participants need to get it registered), or am I wrong?

Is it a method like the pre-, past- and -init()  Methods one should put there?

Yes, you have the right idea. It should be in common code (common proxy or your main mod class), and it should be in a class annotated with @Mod.EventBusSubscriber. What happened when you tried it?

[ConfusedMerlin]

Thanks for replying this fast.

 

Let me thing... I do have a CommonProxy which will be extended by Server and Client Proxy. These are used to be stuffed inside the CommonProxy Field inside the Mods main() (using this annotation @SidedProxy to let the api decide which to use).

 

At the very moment the method you quoted from me is right inside the CommonProxy Class... which does not have an annotation at the moment. 

*thinking*

So I place all these register-calls in a Class... I might choose a name for myself... and annote the class with @Mod.EvenBustSubsciber... and all the register-Subscribtions inside get a @SubscribeEvent... and because of that EventBus-Thingy it will get called before the preInit() and have all its content registered just in time for preinit? *thinking* 

 

(I wonder if I can refactor all Classes that might come inside this, or it will grow with every Object I want to add?)

 

Aaand... its late over here, so I will come back for more confusion tomorrow. Thanks for helping!

[Jay Avery]

3 minutes ago, ConfusedMerlin said:

Thanks for replying this fast.

 

Let me thing... I do have a CommonProxy which will be extended by Server and Client Proxy. These are used to be stuffed inside the CommonProxy Field inside the Mods main() (using this annotation @SidedProxy to let the api decide which to use).

 

At the very moment the method you quoted from me is right inside the CommonProxy Class... which does not have an annotation at the moment. 

*thinking*

So I place all these register-calls in a Class... I might choose a name for myself... and annote the class with @Mod.EvenBustSubsciber... and all the register-Subscribtions inside get a @SubscribeEvent... and because of that EventBus-Thingy it will get called before the preInit() and have all its content registered just in time for preinit? *thinking* 

 

(I wonder if I can refactor all Classes that might come inside this, or it will grow with every Object I want to add?)

 

Aaand... its late over here, so I will come back for more confusion tomorrow. Thanks for helping!

You seem to have the right ideas! You might find it easiest to simply put the registration events directly inside your main mod class, to keep everything in one place. Then inside those events, you can redirect to methods inside other classes if you don't want to keep all the code in @Mod.

[V0idWa1k3r]

2 minutes ago, ConfusedMerlin said:

public static final void

a final static void?... Why?..

 

3 minutes ago, ConfusedMerlin said:

Item.

You might want to finish your code here.

 

4 minutes ago, ConfusedMerlin said:

But WHERE do I put this?

In any class an instance of you subscribe to forge's event bus during pre-init/automatically.

 

5 minutes ago, ConfusedMerlin said:

commonproxy (because all participants need to get it registered)

Proxies are for distinguishing between physical sides. There should not be a common proxy to begin with, only a server one and a client one. Any common code can go in any common class, including your mod class for example.

 

7 minutes ago, ConfusedMerlin said:

I tried this, having my ModItem return itself as a Singleton when called using init(), but is that correct?

Assuming latest forge for 1.12:

Spoiler

 

You just need to pass an instance of a registry entry(item is one such object) that has a registry name setup to the registry. Then any 

public/private static final %Type% %name% = null

fields annotated with ObjectHolder that have the value of that annotation matching the registry name will be populated with the registered item's instance. Sounds confusing enough? You can try to figure it out using one of the examples provided by forge.

 

ObjectHolder on a field practically tells forge "hey, after we are done registering stuff can you put a thing with the registry name I hold in the field I annotate?". Forge then tells "sure, as long as I can find that thing". ObjectHolder on a class tells forge "Hey, I hold a modid. Any ObjectHolders in the class I annotate look for items from said mod and may not contain a modid in their name but that's what I am for". So basically a class like

@ObjectHolder("examplemod")
public class Example
{
    @ObjectHolder("example_item")
    public static final Item exampleItem = null;
}

Will have it's exampleItem field set to an item that has a registry name of examplemod:example_item after the items have been registered. You do not need to do anything with a class like this apart from just having it present somewhere. Forge will automatically do things with it.

 

Registering your things is even easier:

@SubscribeEvent
public void registerItems(RegistryEvent.Register<Item> event)
{
    event.getRegistry().register(new Item().setRegistryName("examplemod", "example_item"));
}

This is valid code that will register an item with the registry name of examplemod:example_item and automaticaly populate all ObjectHolder annotated fields that look for that item(the one in my previous example is one such field).

 

You know the best part and why this system is so amazing? It works with anything that is a registry entry. Anything. Blocks, Items, Biomes, Potions... And even modded registries! If there is a SpellMod that creates a registry for it's Spell objects the Register<Spell> event will be fired for it. This also allows you to reference items from other mods with ease using ObjectHolders afaik.

The registry events are normal forge events and can be registered both to an event bus manualy or with EventBusSubscriber.

 

26 minutes ago, ConfusedMerlin said:

And, I feel sorry to say this, but your Doc looks a bit like the stuff my boss at work usually creates for documentation purposes: great for people which actually did this somehow many times and need a mind lift to get on track.

Well the docs are open for changes. Anyone can contribute if they wish to. The end result is usually pretty confusing, especially now when stuff is actively changing.

 

Disclaimer: that is how I understand the new registry system. If I am not correct with something please do correct me. The behaviour I've described seems to match with the behaviour I see in game but I might be missing/misunderstanding something.

 

 

5 minutes ago, Jay Avery said:

and it should be in a class annotated with @Mod.EventBusSubscriber

Not necessary. Registry events are fired after pre-init so you can subscribe your handler to a bus in pre-init and be done. It will especially not work as the methods are not static - EventBusSubscriber(or subscribing a class to a bus) will only process static fields.

[Jay Avery]

1 minute ago, V0idWa1k3r said:

Not necessary. Registry events are fired after pre-init so you can subscribe your handler to a bus in pre-init and be done. It will especially not work as the methods are not static - EventBusSubscriber(or subscribing a class to a bus) will only process static fields

The docs say registry events are fired before preInit.

[V0idWa1k3r]

1 minute ago, Jay Avery said:

The docs say registry events are fired before preInit.

Well, Lex says differently. As far as I am aware the registry events have been moved to directly after pre-init but before init. Maybe the docs are not updated yet? I am subscribing my handlers for registries during pre-init and it works fine.

[ConfusedMerlin]

Good Evening again.

 

Thank you for your input. Well, long story short: it still does not work. 

But in another way as yesterday. At least I think. Long story short (again): minecraft starts without errors, I can went into my creative test world, but my item is missing. There is no hint in the creative inventory about it. 

 

So.... I looked up the example java (this one) and tried to pick out whats necessary for me. 

Now I do have a ModItem Class file, that is supposed to become a plane clone of the snowball (but with another name). And... yes, the main class is IanusIncHq (and contains its MODID field). Don't ponder about this name, I just picked something random from work.

Oh, and I cut off all the imports. 

Quote

public final class ModItem extends ItemSnowball {

    public ModItem(){
        super();
        setUnlocalizedName("modItem");
        setRegistryName(new ResourceLocation(IanusIncHq.MODID,"modItem"));
        setCreativeTab(CreativeTabs.MISC);
        setMaxStackSize(8);
        setHasSubtypes(true);
    }
}

 

 

I have moved the registering action from all these well named and packaged class files right into the main class of the mod. It still does look a bit short somehow, but I do have the feeling that my Item finally grabbed the attention of forge, because for a long time I had Unqualified reference to ObjectHolder Errors, which happened because the "@ObjectHolder" (at this moment in my commonProxy.java) tried to grab the item I told him to do... but the registering-function was not called after all. For some reason I did expect that it will be called by forge as soon as it finds the annotation "@SubscribeEvent"... even when not in the main class. 

Now everything is inside the main class. It starts... but no Copy of snowball called "ModItem" or something like this in the MISC Tab appears. I do suspect that I need to add a model for it or something like this. At least, thats what inside the example java but not inside the code of mine. But again, somehow I was expecting to get some invalid inventory icon hinting the existence of my fake snowball (and that something is missing).

 

Quote

@Mod(modid = IanusIncHq.MODID, version = IanusIncHq.VERSION, acceptedMinecraftVersions = "[1.12]")
public class IanusIncHq
{

    @SidedProxy(serverSide= "merlin.ianusinc.ianusinchq.ServerProxy", clientSide = "merlin.ianusinc.ianusinchq.ClientProxy")
    public static CommonProxy proxy;

    public static final String NAME = "Ianus Inc Headquaters Core";
    public static final String MODID = "ianus_inc_headquaters";
    public static final String VERSION = "0.0.1";

    @GameRegistry.ObjectHolder("modItem")
    public static final Item MOD_ITEM = null;

    @Mod.EventHandler
    public void preInit(FMLPreInitializationEvent e) {
        proxy.preInit(e);
    }

    @Mod.EventHandler
    public void init(FMLInitializationEvent e) {
        proxy.init(e);
    }

    @Mod.EventHandler
    public void postInit(FMLPostInitializationEvent e) {
        proxy.postInit(e);
    }

    @SubscribeEvent
    public void registrItems(RegistryEvent.Register<Item> event){
        event.getRegistry().registerAll(new ModItem());

    }
}

 

I will take a minute to ponder why there is no dedicated "java" selection inside the forum's code pasting highlighting... whatever, java script does this job well enough. 

 

Anyway. I'll try to be a bit less vague with my followup-request this time and ask directly: what do I need to do to get this ModItem appear in the MISC section using the model of the standard-snowball? I doubt that this will be enough to throw it (which just has been promoted to my next milestone, just a second ago), but one step after another. I will keep on studying the example java, but not tonight. 

 

Thank you for you nudging me in a useful direction. I start thinking that staring off from nothing with 1.12 wasn't such a bright idea, but... no. I will proceed. And get something done before Minecraft 1.13 will be launched. I hope. 

 

Bye for now. 

[V0idWa1k3r]

22 minutes ago, ConfusedMerlin said:

@SubscribeEvent public void registrItems(RegistryEvent.Register<Item> event)

You still need to subscribe an instance of a class that contains methods annotated with SubscribeEvent ot forge's event bus. Here is the tutorial from the official docs.

 

22 minutes ago, ConfusedMerlin said:

setRegistryName(new ResourceLocation(IanusIncHq.MODID,"modItem"));

Registry names should be entirely lower-case.

 

22 minutes ago, ConfusedMerlin said:

setUnlocalizedName("modItem");

You will have lang conflicts if another mod adds an item named modItem. It is a good practive to use your registry name as your unlocalized name to avoid such conflicts.

 

22 minutes ago, ConfusedMerlin said:

I will take a minute to ponder why there is no dedicated "java" selection inside the forum's code pasting highlighting...

Yes there is. It is called C Languages(C, C++, C#, Java, ObjectC)

Edited June 28, 2017 by V0idWa1k3r

[ConfusedMerlin]

Hallo again.

 

Well... a, let pictures speak. See attachment. 

Still... some things still are not finished yet. 

 

First - and most obvious - does the tutorial_ore lack its texture. I crawled through all spaces, where I could have placed a typo, but until now didn't find one. There is a dedicated texture available which is referred to in its very own model json. Buuut... Somehow I'm afraid I'm looking at the wrong destination. 

 

I wonder If I do need to the "ModelLoader.setCustomModelResourceLocation" I did for item for blocks too, but after there isn't a method that accepts block in that general direction I think something other might be necessary. Looking for this topic in the Docs didn't yield a result, but looking inside the example file there is this piece of code "GameRegistry.registerTileEntity(TileSimpleTank.class, "simpletank");"

Is that what needs to be done to get this piece of tutorial_ore get its texture? 

 

Another thing I observed is the Block{null} I receive when creating my tutorial_ore in the first place. It... should be kind of okay, because after this it gets registered and its ItemBlock extracted, but I wonder if this is correct. When the registration passes by the tuturial_ingot, it got a "proper" number, like {3521} or something like this. I do know that counting with computers usually include starting off with zero, but {null} isn't {0} as far as I can tell. 

So is that an error (caused by me?), or something not worth thinking about any more?

 

 

So. In case you are wondering what my classes do look alike now... okay, I'm afraid I might bore most of you guys, but in case someone with equal confusion passes by looking for a hint, I would like to offer my classes. And you can point out what I did wrong, if you like this more. 

By the way, yesterday I went amok reading and watching almost every tutorial I could my hands get on, but most of them seem to be unaware of the event registration process, getting pointed at by their watchers. Oh, and I came by the ForgeRegistries.BLOCK.register() function, which I tried to adapt, but that didn't work in my case. But it went pretty well in the setup the Tutor used for some reason. When I placed loggers everywhere to find out what happens at what point in execution, I noticed that his way of registering happened during the init() phase (which shouldn't work, shouldn't it?). For some reason after not coming to a success with his method, I went to bed and woke up with an idea for what's next.

 

First... the Mod-class, stripped off  the imports (which happen almost complete automatic this days): Oh, I replaced all my Mod-names with modClass in all parts comming, because the name I actually use is plain stupid... The Reference Class just contains Strings, as its used by next to every tutorial maker out there. And I DID edit the mcmod.info file as requested by the Docs!

Quote

import java.util.logging.Logger;

/**
 * Created by Seine Eiligkeit on 29.06.2017.
 */
@Mod(modid=Reference.MODID, name=Reference.NAME, version=Reference.VERSION)
public class ModClass {

    public static Logger LOGGER = Logger.getLogger(Reference.MODID);

    @SidedProxy(clientSide = Reference.CLIENTPROXY, serverSide = Reference.COMMONPROXY)
    public static CommonProxy proxy;

    @Mod.EventHandler
    public static void preInit(FMLPreInitializationEvent event) {
        LOGGER.info("Starting Preinitialization...");
        proxy.preInit(event);
    }

    @Mod.EventHandler
    public static void init(FMLInitializationEvent event) {
        LOGGER.info("Starting Initialization...");
        proxy.init(event);
    }

    @Mod.EventHandler
    public static void postInit(FMLPostInitializationEvent event) {
        LOGGER.info("Starting PostInitialization...");
        proxy.postInit(event);

    }
}

 

I tried to place the EventSubscriber Methods in there first, but they didn't get triggered. Which was a bit discouraging first, but than I remembered the statement, that this have to happen even before the preInit and could be accomplished by annotate a whole class with that bus-thing. 

 

So this came into existence.

Quote

/**
 * Created by Seine Eiligkeit on 30.06.2017.
 */

@Mod.EventBusSubscriber
public class RegisterUtil {


    @SubscribeEvent
    public static void registerBlocks(RegistryEvent.Register<Block> event){

        BlockInit.prepareBlocks();
        BlockInit.registerBlocks(event);
    }
    @SubscribeEvent
    public static void registerItems(RegistryEvent.Register<Item> event){
        ItemInit.prepareItems();
        ItemInit.registerItems(event);
    }
}

 

And its true, that this happens before the preInit is called. In here there is no logging, but the methods called in here do log again, and when they apperead in front of the preinit() call I had the feeling that things might turn out in a good way.

Just to be curious, does all the SubscribeEvent annoted methods get passed all occurring RegistryEvents that appear, or how does this work in detail? 

 

So next the BlockInit. Thats where I tired to place this RenderModel Thing, but it didn't work. But when I pass the BlockItem over to ItemInit, it will get its RenderModel Thing done. But... well, something is missing. 

Quote

/**
 * Created by Seine Eiligkeit on 29.06.2017.
 */
public class BlockInit {

    public static Block tutorial_ore;
    public static ArrayList<Block> blockList = new ArrayList<>();

    public static void prepareBlocks(){
        ModClass.LOGGER.info("Block Preparation starts now");

        tutorial_ore = new CustomOre("tutorial_ore",2.0F,4.0F,2);

        ItemInit.addItemBlockToItems(tutorial_ore);

        blockList.add(tutorial_ore);
    }

    public static void registerBlocks(RegistryEvent.Register<Block> event){
        ModClass.LOGGER.info("Block Registration starts now");
        for(Block block : blockList){
            ModClass.LOGGER.info("Going to register: " + block.getUnlocalizedName() +"...");
            event.getRegistry().register(block);

        }
        ModClass.LOGGER.info("Done Item registration...");
    }

}

 

It might be not the most efficient way to do this maybe, but it does not crash and yield some kind of result... Another thing I'm afraid I may do wrong is the transmission of the ItemBlock over to InitItem. As you will see in the next code part, there I get the modItem and stuff it to all the other items (yet to come).  

Oh, and this is the place where I did meet the "Block{null}"; when the Breakpoint at ItemInit.addItemBlockToItems triggered, I hovered over "tutorial_ore" and got this reading.

I will add "CustomOre" later, first the InitItem.java

 

Here we go: 

Quote

/**
 * Created by Seine Eiligkeit on 29.06.2017.
 */
public class ItemInit {

    public static Item tutorial_ingot;
    public static ArrayList<Item> itemList = new ArrayList<>();

    public static void prepareItems(){
        MocClass.LOGGER.info("Item Preparation starts now");

        tutorial_ingot = new CustomIngot("tutorial_ingot");

        itemList.add(tutorial_ingot);
    }
    public static void addItemBlockToItems(Block block){
        ItemBlock itemblock = new ItemBlock(block);
        itemblock.setRegistryName(block.getRegistryName());
        itemList.add(itemblock);
    }


    public static void registerItems(RegistryEvent.Register<Item> event){
        ModClass.LOGGER.info("Item Registration starts now");
        for(Item item : itemList){
            ModClass.LOGGER.info("Going to register: " + item.getUnlocalizedName() +"...");
            event.getRegistry().register(item);
            ModClass.LOGGER.info("\t\tSet ModelResourceLocation to " + Reference.MODID + ":" + item.getUnlocalizedName().substring(5));
            ModelLoader.setCustomModelResourceLocation(
                    item,
                    0,
                    new ModelResourceLocation(Reference.MODID + ":" + item.getUnlocalizedName().substring(5))
            );
           ModClass.LOGGER.info("Done registering: " + item.getUnlocalizedName() +"...");
        }
        ModClass.LOGGER.info("Done Item registration...");
    }
}

 

So in here all  my Items will be put to place, plus evers ItemBlock coming over from BlockInit. I avoided the Minecraft.getMinecraft.andsoon.ModelMesher Thing as requested. Still, most tutorial guys still love to use it. ModelLoader came from the example file I think....Anyway; as explained here somewhere, I didn't need to do something by myself to have the items registered after the blocks. All that follow are done in a alphabetical order? No, arbitrary... do I need to watch out for decencies in there?

 

Okay. We neeeed.... the Item and Block Classes. Item is straight forward, while block... is... huh... that's remaining from one of the later tutorials. I dunno, if I keep it this way, or if I need to adjust this. Well, at the moment its suspicious for making the tutorial_ore Block missing its texture. Oh, I had a moment of panic, when the block didn't appear after all, but all I was missing was the CreativeTabs Method call. So no default placement, hm?

Quote

/**
 * Created by Seine Eiligkeit on 29.06.2017.
 */
public class CustomIngot extends net.minecraft.item.Item {

    public CustomIngot(String name){
        setUnlocalizedName(name);
        setRegistryName(name);
        setCreativeTab(CreativeTabs.MATERIALS);
    }
}

/**
 * Created by Seine Eiligkeit on 29.06.2017.
 */
public class CustomOre extends CustomBlock
{
    public CustomOre(String name,float hardness,float resistance, int harvestLevel){
        super(name,hardness,resistance);
        setHarvestLevel("pickaxe",harvestLevel);
        setCreativeTab(CreativeTabs.MISC);
    }
}

/**
 * Created by Seine Eiligkeit on 29.06.2017.
 */
public class CustomBlock extends Block{

    public CustomBlock(String name,float hardness,float resistance)
    {
        super(Material.ROCK);
        setUnlocalizedName(name);
        setRegistryName(name);
        setHardness(hardness);
        setResistance(resistance);


    }
}

 

Okay... I think that are all classes that were necessary to get this stuff into the game. Oh, proxies are missing, but they are plain and empty at the moment, not really distinguishable from these you find in nearly every tutorial out there (expect that one gut who had a CommonProxy, ClientProxy AND a own ServerProxy, where  all the others work without the ServerProxy)

 

Hm. The folders with the textures and json files may be of interest. Look at this: 

Quote

└───assets
    └───modclass
        ├───blockstates - tutorial_ore.json
        ├───lang		- en_us.lang
        ├───models
        │   ├───block	- tutorial_ore.json
        │   └───item	- tutorial_ore.json, tutorial_ingot.json
        └───textures
            ├───blocks	- tutorial_ore.png
            └───items	- tutorial_ore.png, tutorial_ingot.png

tutorial_ore.json

{
  "variants": {
    "normal": {"model": "modclass:tutorial_ore" }
  }
}

tutorial_ingot.json

{
    "parent": "item/generated",
    "textures": {
        "layer0": "modclass:items/tutorial_ingot"
    }
}

tutorial_ore.json (from Blockstates)

{
  "variants": {
    "normal": {"model": "ianusinchq:tutorial_ore" }
  }
}

en_us.lang

item.tutorial_ingot.name=Tutorial Ingot
tile.tutorial_ore.name=Tutorial Ore

 

I feel like I missed one... ayway. You might spot the tutorial_ore inside item(s) folder, which is because I thought that the texture for the block might come from its BlockItem (which would get a reference to Items texture folder due to being registered alongside the normal Items)

 

So... I'm not certain how to proceed now. Of course I would be happy having the correct texture appearing at the block, but after this... 

 

Oh, I still do not know what to do with the @ObjectHolder to be honest. That might come next. Or using recipes. Are there other things, that did change in a way from pre 1.12 forge to now that old tutorials are not usable any more? Something one would come across inevitable?

 

So, thank you for inputting knowledge in my general direction. Still, I'm afraid I was so confused after all, that I closed in to enlightenment from the other direction and didn't accomplish this by using the resources available at the moment. But I'm a bad explainer too, especially if I have to use english (as my second language). I wonder if the stuff I provided could be of any help after all, but this topic of mine is to confusing to be feasible for anything but being forgotten in the deeps of this forum. 

 

So. I look forward to getting my block colourized properly. Until then have a nice day.

 

And last, but not least, my motivational picture of the day:  

[Jay Avery]

Your posts make me smile! I like how detailed you are about explaining what you've done and what's not working, compared to some people who just say "it's broken" and expect answers.

 

So, the block with no texture. This issue is only to do with rendering - it's nothing about registration (you seem to have that all working - although I'm no expert on @ObjectHolder stuff). For the rendering problem, there will be errors in the console log which explain what has gone wrong - can you post the log so we can look?

 

Also, because there are several files with the same name I'm not certain which is which from your post. Could you please clarify by posting the files you have at each of these locations:

• blockstates/tutorial_ore
• models/block/tutorial_ore
• models/item/tutorial_ore

[ConfusedMerlin]

Good Evening again,

 

well, I'm happy to provide some unexpected happiness. But lets keep on going with the disco-cube. Iiiiiii... just needed to find out where there are any logs after all, and I found quite a lot inside the projects "run" folder. But these are quite a big number of lines, so instead of quoting and code-tagging them, I will try to attach them all. Oh, I didn't find the log-file that represents the log from the IDEs console somehow... so I pasted in a .txt which may not have the proper name (look for run.txt)

And my mods stupid name (ianusinchq) came in pretty handy, because I could easily search for it. Or just "ianus". If I ever make it all the way to a usable mod I might explain why I did choose the two faced One (with a company type extension) as a mod name.

 

Aaaaaand here we have the most interesting part extracted (from the fml-junk-earlystarup.log)

Quote

...

[19:20:01] [Server thread/TRACE] [FML]:   Registry: 253 ianusinchq:tutorial_ore Block{ianusinchq:tutorial_ore}
[19:20:01] [Server thread/TRACE] [FML]:   Registry: 255 minecraft:structure_block Block{minecraft:structure_block}

...

[19:20:01] [Server thread/TRACE] [FML]:   Registry: 4096 ianusinchq:tutorial_ore net.minecraft.item.ItemBlock@757e13b2
[19:20:01] [Server thread/TRACE] [FML]:   Registry: 4097 ianusinchq:tutorial_ingot merlin.ianusinc.ianusinchq.items.CustomIngot@6e26d0b3

...

[19:20:01] [Server thread/DEBUG] [FML]: Registry Item: Fixed minecraft:items id mismatch ianusinchq:tutorial_ore: 4096 (init) -> 4097 (map).
[19:20:01] [Server thread/DEBUG] [FML]: Registry Item: Fixed minecraft:items id mismatch ianusinchq:tutorial_ingot: 4097 (init) -> 4096 (map).

...

[19:20:01] [Server thread/TRACE] [FML]:   Registry: 253 ianusinchq:tutorial_ore Block{ianusinchq:tutorial_ore}
[19:20:01] [Server thread/TRACE] [FML]:   Registry: 255 minecraft:structure_block Block{minecraft:structure_block}

...

[19:20:01] [Server thread/TRACE] [FML]:   Registry: 4096 ianusinchq:tutorial_ingot merlin.ianusinc.ianusinchq.items.CustomIngot@6e26d0b3
[19:20:01] [Server thread/TRACE] [FML]:   Registry: 4097 ianusinchq:tutorial_ore net.minecraft.item.ItemBlock@757e13b2

...

 

Parts between common minecraft stuff, to be precise. 

Item mismatch doesn't sound this good... but tell me, did he just swap the numbers of both findings, so the mismatch became mismatched again, or do I interpret this in a wrong manner? Or why was it necessary to switch the numbers of the ItemBlock and the CustomIngot?

 

Hm.... all other logs there seems to tell nothing extraordinary. Expect for latest.log maybe, which says this quite a few times:

Quote

[19:19:55] [main/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[19:19:55] [main/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[19:19:55] [main/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[19:19:55] [main/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[19:19:55] [main/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[19:19:55] [main/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[19:19:55] [main/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all

I do remember having seen "cube_all" somewhere shortly, and this is where we come to the  three json files. 

 

Lets start off with blockstates/tutorial_ore

Quote

{
  "variants": {
    "normal": {"model": "ianusinchq:tutorial_ore" }
  }
}

 

 

Next one, models/block/tutorial_ore (ah, this is where the cube_all came from)

Quote

{
  "parent": "block/cube_all",
  "textures": {
    "layer0": "ianusinchq:blocks/tutorial_ore"
  }
}

 

 

Last but not least, the models/item/tutorial_ore

Quote

{
  "parent": "ianusinchq:block/tutorial_ore"
}

 

huh, I thought it was more inside the last time I looked into, but... no, seems to be complete. But I missed it when posting the last post (because I thought it was the same as the one in block/tutorial_ore)

And is is missing a S behind block? It does. Does it need it? *thinking* 

...

...

...

What? No, I certainly didn't insert it and run minecraft just to see if it works. ... okay, yes, I did. And it didn't work.

Because "parent" points to the tutorial_ore inside my models/block folder, I think (so the missing s is needed).

 

But now, after reviewing all that belongs to this topic, I'm still out of ideas about the "why". Well, the purple-black texture does look kind of nice, but is not what I had in mind for that ore block. ... Okay, the actual texture is kind of purple too, but not like this! 

 

AfterPeviewPreSubmitEdit(): When reviewing the post with the page preview (to get rid of the most embarrassing typos) I noticed that the blockstates are missing any... folder-directory-prefix-whatever-this-is-called, and repeated the "thinking" I did before (added block/ in front of the tutorial_ore, than realized that this may point to the texture for the "normal" state, when no one tries to pickaxe it, and repeated it with blocks/, but...).

With the same result: Thinking does not fix texture-missing errors apparently; its still in its disco state. And I think I'm going to create a disco ball with music as the first real think, somehow. 

 

Greetings, Merlin

 

latest.log

fml-junk-earlystartup.log

fml-client-latest.log

run.txt

[Draco18s]

Your texture name in midels/block uses "layer0". That's the 2D item layer name.  Cube_all uses "all"

[Jay Avery]

27 minutes ago, ConfusedMerlin said:

Lets start off with blockstates/tutorial_ore

Quote

{
  "variants": {
    "normal": {"model": "ianusinchq:tutorial_ore" }
  }
}

 

 

Next one, models/block/tutorial_ore (ah, this is where the cube_all came from)

Quote

{
  "parent": "block/cube_all",
  "textures": {
    "layer0": "ianusinchq:blocks/tutorial_ore"
  }
}

 

 

Last but not least, the models/item/tutorial_ore

Quote

{
  "parent": "ianusinchq:block/tutorial_ore"
}

 

 

Okay, a few problems in these files!.

 

Firstly, in the blockstates file, your model points to "ianusinchq:tutorial_ore". The game translates this to the location assets/ianusinchq/models/block/tutorial_ore. Is that the location of your block model? No, you said your assets folder is named modclass, not ianusinchq.

 

Now, you have the same problem in your block model file. The texture points to "ianusinchq:blocks/tutorial_ore", which translates to assets/ianusinchq/textures/blocks/tutorial_ore. But you said your assets folder is named modclass. Additionally, as Draco18s pointed out, you are labelling the texture "layer0", but this isn't the name of the texture in cube_all. The texture used for the block faces is called "all" (this is what you saw in the log).

 

And finally, the same problem again in your item file! The model points to "ianusinchq:block/tutorial_ore", which means assets/iausinchq/models/block/tutorial_ore, which isn't the correct location of your block model.

[ConfusedMerlin]

Good Evening, the last time to...night.

 

Thank both of you for pointing out whats wrong with my texturing. It was the "all" that was missing; I'm sure I overlooked this in the tutorial I had the instructions from.

 

Oh,And @Jay Avery, ianusinchq is the correct name  I changed it in the grand classes post because I was wondering what a troubled junior mod maker may think if he reads this. Maybe something like "what is that ianus thing?" and "do I need this too?"

When its "modclass" chances seem to be higher the one realize "oh, so thats the point where I put my mods name into!"

 

Now... I think this has been resolved. Should I change the Title to (solved) or something like this? Or is there anything anyone might want to add? (can I change the title anyway?)

 

Now have a nice day / night and see u the next time I get confused.

 

Greetings, (not so) ConfusedMerlin

 

EDiT: and here we go - purple blocks, but this time in a less disco-ish look

Edited June 30, 2017 by ConfusedMerlin
Wanted to add that awesome... okay, its a boring pic

[Kokkie]

8 minutes ago, ConfusedMerlin said:

Now... I think this has been resolved. Should I change the Title to (solved) or something like this? Or is there anything anyone might want to add? (can I change the title anyway?)

If you want you can change the title to:

[1.12] Registering for Dummies [Solved]

You don't have to. To change the title, edit the first post and change the title of the post.