Trying to learn blockstates and config files...

[AmeliaLotus]

1 hour ago, Draco18s said:

Honestly?

 Grab these two classes. They're set up as Common/Client proxy, just wire them up to use your own mod class rather than HardLib and change the package name (or if you want, declare a dependency on HardLib).

Then use EasyRegistry.registerItem(...) and EasyRegistry.registerBlock(...) (or the -WithVariants version).

 

I've done a lot of work to make the system easy to use and still conform to proper registration methods.

Truthfully, I've never done dependencies or tried modifying someone's entire class codes to fit mine. It just never works. 

But I tried, and failed miserably...Now I have to redo everything by downloading on GitHub because I don't have a clue what broke...

[Draco18s]

All you should have to do is:

1. Copy-paste the raw text into a class file somewhere in your project.
2. Let Eclipse rename and fix package declarations as needed.
3. Replace all references to Hardlib with a reference to your own mod.
   • Be aware that these classes were proxy-based.
   • If you copy the code into your common proxy and your client proxy, you will just need to replace HardLib with your own main class name.

 

[AmeliaLotus]

28 minutes ago, Draco18s said:

All you should have to do is:

1. Copy-paste the raw text into a class file somewhere in your project.
2. Let Eclipse rename and fix package declarations as needed.
3. Replace all references to Hardlib with a reference to your own mod.
   • Be aware that these classes were proxy-based.
   • If you copy the code into your common proxy and your client proxy, you will just need to replace HardLib with your own main class name.

 

If I just copy pasted into my Client and Common proxies, would I need your API files, such as IMetaLookup, MeshDefinitions, etc? It's a whole lot of files for a little register item thing...

[Draco18s]

1 hour ago, AmeliaLotus said:

If I just copy pasted into my Client and Common proxies, would I need your API files, such as IMetaLookup, MeshDefinitions, etc? It's a whole lot of files for a little register item thing...

Yes, you would need those too. You can put them anywhere convenient, just update the package names and import reference. I forgot about those two.

 

IMetaLookup is how I handle enum variants for items, e.g. this enum and this item. IItemWithMeshDefinition is used for custom mesh definitions (you can omit this one and any code that uses it, if you don't need NBT-driven models, e.g. this item). They just let me specify strict types for the generic methods and know that I'm getting everything needed in order to register things completely.

 

Its not perfect, but once set up it works amazingly.

[AmeliaLotus]

2 hours ago, Draco18s said:

Yes, you would need those too. You can put them anywhere convenient, just update the package names and import reference. I forgot about those two.

 

IMetaLookup is how I handle enum variants for items, e.g. this enum and this item. IItemWithMeshDefinition is used for custom mesh definitions (you can omit this one and any code that uses it, if you don't need NBT-driven models, e.g. this item). They just let me specify strict types for the generic methods and know that I'm getting everything needed in order to register things completely.

 

Its not perfect, but once set up it works amazingly.

Alright, so I have attempted (to the best of my ability) to register with your api.

I get no error, but the blocks aren't showing anymore. https://pastebin.com/XTuBCxSf
Here's the github for all of the code!

EDIT: I figured out that it's just not running the registerBlocks and registerItems SubscriberEvents. Fun...

Edited July 13, 2018 by AmeliaLotus
added github

[AmeliaLotus]

15 hours ago, Draco18s said:

Yes, you would need those too. You can put them anywhere convenient, just update the package names and import reference. I forgot about those two.

 

IMetaLookup is how I handle enum variants for items, e.g. this enum and this item. IItemWithMeshDefinition is used for custom mesh definitions (you can omit this one and any code that uses it, if you don't need NBT-driven models, e.g. this item). They just let me specify strict types for the generic methods and know that I'm getting everything needed in order to register things completely.

 

Its not perfect, but once set up it works amazingly.

How do I use the -withVariant version if I don't technically have any 'variant' to give it? I am simply extending BlockColored and the other "RegisterItems" doesn't seem to work at all.

[Draco18s]

Its a block, use the RegisterBlockWithItem method, it will automatically create and register the item form.

Edited July 13, 2018 by Draco18s

[AmeliaLotus]

5 hours ago, Draco18s said:

Its a block, use the RegisterBlockWithItem method, it will automatically create and register the item form.

I thought so! That was my first try, but it doesn't load the blocks nor the items correctly.  
 

Exception loading model for variant blockstatetraining:blockstatetraining#color=cyan for blockstate "blockstatetraining:blockstatetraining"

It works with RegisterBlock, just not RegisterBlockWithItem...
 

Edited July 13, 2018 by AmeliaLotus

[Draco18s]

You will need to show the whole error.

I need the "Caused By" line that comes later.

 

Odds are, something is wrong with your blockstate or model file.

Edited July 13, 2018 by Draco18s

[AmeliaLotus]

Just now, Draco18s said:

You will need to show the whole error.

I need the "Caused By" line that comes later.

 

Odds are, something is wrong with your blockstate or model file.

Spoiler

 [main/ERROR] [FML]: Exception loading model for variant blockstatetraining:blockstatetraining#color=cyan for blockstate "blockstatetraining:blockstatetraining"
net.minecraftforge.client.model.ModelLoaderRegistry$LoaderException: Exception loading model blockstatetraining:blockstatetraining#color=cyan with loader VariantLoader.INSTANCE, skipping
    at net.minecraftforge.client.model.ModelLoaderRegistry.getModel(ModelLoaderRegistry.java:153) ~[ModelLoaderRegistry.class:?]
    at net.minecraftforge.client.model.ModelLoader.registerVariant(ModelLoader.java:237) ~[ModelLoader.class:?]
    at net.minecraft.client.renderer.block.model.ModelBakery.loadBlock(ModelBakery.java:153) ~[ModelBakery.class:?]
    at net.minecraftforge.client.model.ModelLoader.loadBlocks(ModelLoader.java:225) ~[ModelLoader.class:?]
    at net.minecraftforge.client.model.ModelLoader.setupModelRegistry(ModelLoader.java:152) ~[ModelLoader.class:?]
    at net.minecraft.client.renderer.block.model.ModelManager.onResourceManagerReload(ModelManager.java:28) [ModelManager.class:?]
    at net.minecraft.client.resources.SimpleReloadableResourceManager.registerReloadListener(SimpleReloadableResourceManager.java:121) [SimpleReloadableResourceManager.class:?]
    at net.minecraft.client.Minecraft.init(Minecraft.java:559) [Minecraft.class:?]
    at net.minecraft.client.Minecraft.run(Minecraft.java:421) [Minecraft.class:?]
    at net.minecraft.client.main.Main.main(Main.java:118) [Main.class:?]
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_172]
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_172]
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_172]
    at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.8.0_172]
    at net.minecraft.launchwrapper.Launch.launch(Launch.java:135) [launchwrapper-1.12.jar:?]
    at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.12.jar:?]
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_172]
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_172]
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_172]
    at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.8.0_172]
    at net.minecraftforge.gradle.GradleStartCommon.launch(GradleStartCommon.java:97) [start/:?]
    at GradleStart.main(GradleStart.java:25) [start/:?]
Caused by: net.minecraft.client.renderer.block.model.ModelBlockDefinition$MissingVariantException
    at net.minecraft.client.renderer.block.model.ModelBlockDefinition.getVariant(ModelBlockDefinition.java:83) ~[ModelBlockDefinition.class:?]
    at net.minecraftforge.client.model.ModelLoader$VariantLoader.loadModel(ModelLoader.java:1182) ~[ModelLoader$VariantLoader.class:?]
    at net.minecraftforge.client.model.ModelLoaderRegistry.getModel(ModelLoaderRegistry.java:149) ~[ModelLoaderRegistry.class:?]
    ... 21 more

That's the whole error.

 

{
   "parent": "block/cube_all",
   "textures": {
       "all": "blockstatetraining:blocks/lighted_glass_block"
   }
}

That's my model json

 

{
    "variants": {
        "color=white": { "model": "blockstatetraining:lighted_glass_white" },
        "color=orange": { "model": "blockstatetraining:lighted_glass_orange" },
        "color=magenta": { "model": "blockstatetraining:lighted_glass_magenta" },
        "color=light_blue": { "model": "blockstatetraining:lighted_glass_lightblue" },
        "color=yellow": { "model": "blockstatetraining:lighted_glass_yellow" },
        "color=lime": { "model": "blockstatetraining:lighted_glass_lime" },
        "color=pink": { "model": "blockstatetraining:lighted_glass_pink" },
        "color=gray": { "model": "blockstatetraining:lighted_glass_gray" },
        "color=silver": { "model": "blockstatetraining:lighted_glass_lightgray" },
        "color=cyan": { "model": "blockstatetraining:lighted_glass_cyan" },
        "color=purple": { "model": "blockstatetraining:lighted_glass_purple" },
        "color=blue": { "model": "blockstatetraining:lighted_glass_blue" },
        "color=brown": { "model": "blockstatetraining:lighted_glass_brown" },
        "color=green": { "model": "blockstatetraining:lighted_glass_green" },
        "color=red": { "model": "blockstatetraining:lighted_glass_red" },
        "color=black": { "model": "blockstatetraining:lighted_glass_black" }
                }
}

This is my blockstate json.

It all works perfect if I used RegisterBlock (Items don't work, of course...), and if I use BlockWithItem then it all breaks.

[Draco18s]

Ah, sorry, for blocks that have variant items you need registerBlockWithCustomItem, so you can pass in a non-default ItemBlock instance (vanilla has one, I think its ItemBlockColored for colored blocks). There's a lot of register variants and I can't always remember the right one without looking (they are, however, intelligently named).

 

Mind posting the whole log on Pastebin? The error isn't pointing to anything specific still.

[AmeliaLotus]

2 hours ago, Draco18s said:

Ah, sorry, for blocks that have variant items you need registerBlockWithCustomItem, so you can pass in a non-default ItemBlock instance (vanilla has one, I think its ItemBlockColored for colored blocks). There's a lot of register variants and I can't always remember the right one without looking (they are, however, intelligently named).

 

Mind posting the whole log on Pastebin? The error isn't pointing to anything specific still.

At this point, I'm just entering random things and trying it out.

Here's my main class:
https://pastebin.com/0fLSYYSi

Here's my console error:
https://pastebin.com/dAcuTEyK

I even used comments to show you how I did the other ones. Maybe I'm just really screwing things up in my main class... (Probably the issue here...)

And blocks don't show up anymore. Just the purple/black again.

 

EDIT: WOOPS. I set the registryName to MODID instead of "lighted_glass_block" ... Still gives me an error for the items, and only gives me 16 of the exact same block instead of multiple variants... (Each and every item-instance gives me a white lighted block (perfectly textured on the block but not the item!)

Edited July 14, 2018 by AmeliaLotus

[Draco18s]

I'm still seeing a File Not Found error:

Caused by: java.io.FileNotFoundException: blockstatetraining:blockstates/blockstatetraining.json

Edited July 14, 2018 by Draco18s

[AmeliaLotus]

3 minutes ago, Draco18s said:

I'm still seeing a File Not Found error:

Caused by: java.io.FileNotFoundException: blockstatetraining:blockstates/blockstatetraining.json

Yeah. That was my bad. Used MODID instead of "lighted_glass_block.

Here's some updated code: 

	//Easy Register everything with CommonProxy(Server) and ClientOnlyProxy(Client)
    blockGlassLight = new LightedGlassBlock(Material.GLASS);   
    CommonProxy.registerBlockWithCustomItem(blockGlassLight, new ItemBlock(blockGlassLight), "lighted_glass_block");
    
	//Call forth the proxy events!
	MinecraftForge.EVENT_BUS.register(proxy);
		

This gives no errors, the item textures are FINALLY working, but they're all an identical block when placed(the item textures are appropriately working, however). They're all the white block instead of multi-colored. Also, I have absolutely no idea how to name each of them in my en_US.lang if they're all the exact same name in the Item list. 

Meta data in F3 when hovering over each block placed is all color=white... so it's not giving me all the blocks that BlockColored places? 

[Draco18s]

31 minutes ago, AmeliaLotus said:

but they're all an identical block when placed

That's where the custom ItemBlock class comes in. Right now you're using ItemBlock, which by default, places the default state of the block, ignoring any item metadata. Look at the type hierarchy for ItemBlock, I know vanilla has a meta-specific version.

[AmeliaLotus]

1 hour ago, Draco18s said:

That's where the custom ItemBlock class comes in. Right now you're using ItemBlock, which by default, places the default state of the block, ignoring any item metadata. Look at the type hierarchy for ItemBlock, I know vanilla has a meta-specific version.

So I "Cheated" and copied your ItemOreBlock class... it works ! Now I just need to find a way to name them... They're all named with the same exact name ... Now how would I even go about fixing that.... Hmmmm

[Draco18s]

Again, its handled by the ItemBlock.

[AmeliaLotus]

1 hour ago, Draco18s said:

That's where the custom ItemBlock class comes in. Right now you're using ItemBlock, which by default, places the default state of the block, ignoring any item metadata. Look at the type hierarchy for ItemBlock, I know vanilla has a meta-specific version.

You're confusing me by telling me to look at the type hierarchy for ItemBlock.  That's just "Item". Inside item, it's the same issues.

Code is below to how I reached this point. I know I have to switch "lighted_glass_block" with something, but I don't really know how I'd do it. Metadata is just so difficult, I would've been done by now if I just made a separate block for all 16...

CommonProxy.registerBlockWithCustomItem(blockGlassLight, new ItemMetaBlock(blockGlassLight), "lighted_glass_block");

 

[Draco18s]

9 hours ago, AmeliaLotus said:

That's just "Item".

No, its not. Minecraft has metadata blocks too (wool, planks, logs).

 

Here's the list of vanilla ItemBlock subclasses:

• ItemBanner
• ItemCloth
• ItemColored
• ItemLeaves
• ItemMultiTexture (This is the one I couldn't remember the name for that you want)
• ItemPiston
• ItemShulkerBox
• ItemSlab
• ItemSnow

Edited July 14, 2018 by Draco18s

[AmeliaLotus]

2 hours ago, Draco18s said:

No, its not. Minecraft has metadata blocks too (wool, planks, logs).

 

Here's the list of vanilla ItemBlock subclasses:

• ItemBanner
• ItemCloth
• ItemColored
• ItemLeaves
• ItemMultiTexture (This is the one I couldn't remember the name for that you want)
• ItemPiston
• ItemShulkerBox
• ItemSlab
• ItemSnow

ItemMultiTexture requires two blocks and a String array for the meta names. Sorry, but that makes no sense as to why I'd use that here. 

Looks like I'm just going to give up the Metadata thing... No one even uses it anymore(Shown by the fact that only a few people on this forum understand Metadata in the first place)... I'll just be happy with what I've got on LightMod and call it good. I appreciate your help! I've learned quite a bit doing this for the past few days. Thank you!

[Draco18s]

34 minutes ago, AmeliaLotus said:

ItemMultiTexture requires two blocks and a String array for the meta names. Sorry, but that makes no sense as to why I'd use that here

The second block parameter goes into a field named unused. It is unused. The array of strings are a parameter called namesByMeta. Which would be the block's name by meta (e.g. "yellow glass" or "white glass") handled like this:

    public String getUnlocalizedName(ItemStack stack)
    {
        return super.getUnlocalizedName() + "." + this.nameFunction.apply(stack);
    }

Where the nameFunction determines which string in the array to use (handled for you).

 

All that said, there's nothing stopping you from creating your own ItemBlock subclass or using a different one (ItemColored?).

 

Quote

Looks like I'm just going to give up the Metadata thing... No one even uses it anymore(Shown by the fact that only a few people on this forum understand Metadata in the first place)

Block metadata isn't used any more, except as a means of serialization. It's an implementation detail.

And even that is going away in 1.13.

Edited July 14, 2018 by Draco18s

[AmeliaLotus]

6 hours ago, Draco18s said:

Block metadata isn't used any more, except as a means of serialization. It's an implementation detail.

And even that is going away in 1.13.

I feel a little better about this then, for sure. Thank you for your help! 

At the very least, I've learned quite a bit about API's and how to use them. Thanks!