Cadiboo

Nowhere. It’s all done with JSON

Your modid is too short. It should be angry-birds or angrybirds

Your logs should be telling you any problems. You need a blockstate.json which maps variants to models. Minecraft will load the models you give it.

This may help https://forgegradle.readthedocs.io/en/latest/user-guide/shading/

This can't be static. Also models are singletons. Your problem could also be a combination of those issues

Use JSON.

AFAIK getCollisonBox doesn't need to be square.

Item models are now loaded automatically.

If you want something to not pause the main thread when it runs, you need to put it on another thread. https://www.javaworld.com/article/2077138/java-concurrency/introduction-to-java-threads.html

Use JSON

What: Not using an object base class.Why: Using an object base class (commonly called BlockBase or ItemBase) is unnecessary and is an anti-pattern. There is already a BlockBase class, it’s the minecraft Block class. Making a class just to have its children inherit default implementations of methods goes against the OOP principle of Composition over Inheritance.Consequences: Using a class like this stops you from extending other classes and because lots of minecraft code uses instanceof checks to specially handle logic, you are likely to encounter weird and hard-to-fix bugs.How: Instead of putting all your common logic in one class and extending it, extract the logic to utility methods. For example: Instead of calling setRegistryName, setTranslationKey, etc. inside your object base’s constructor, extract it to a helper method and call it on every object when you create it. In this example setup calls the above methods. registry.register(setup(new CustomItem(), "custom_item")); What: Not using static initialisers.Why: Using static initialisers does not allow you to control when your objects are created or the order in which your objects are created.Consequences: Using static initialisers prevents other mods from overriding your objects, prevents forge from being able to dynamically load/unload mods and can cause weird, unreproducible crashes.How: Use the @ObjectHolder annotation if you need static references to your objects and create & register your objects in the appropriate registry event. (Note: before registry events Modders created and registered their items in preInit. This practice became out of date in 1.7 with the introduction of registry events, and is no longer possible in 1.13). What: Not using an interface to register models.Why: This interface (commonly called IHasModel) is unnecessary. All items need models and nothing about model registration requires private or protected data.Consequences: This interface makes you write 4 lines of code in each class and 2+ lines of code in your registry event, when 1 or 2 lines of code could accomplish the exact same thing. It also leads to weird bugs when you forget to make your object implement the interface.How: Simply register each model in the registry event (1 line of code for each model) or write a loop that does it for you (1 or 2 lines depending on the implementation). For example: Write out registerModel(item, meta, variant) for each item and variant or write a loop like this for (Item item : allModItemsAndItemBlocks) registerModel(item, meta, variant); A list of all your items can be acquired in many ways, such as looping over registries and checking domain, keeping your own list, looping over registries and using an instanceof check etc. Read more code common issues & solutions at https://gist.github.com/Cadiboo/fbea89dc95ebbdc58d118f5350b7ba93

Continued from @nullsector76 A coremod is not necessary for this. Furthermore this exact thing has already been done. Multiple times. Also - your coremod is not the first for 1.13.2.

I'm 90% sure its the other way round

What: Not using static initialisers.Why: Using static initialisers does not allow you to control when your objects are created or the order in which your objects are created.Consequences: Using static initialisers prevents other mods from overriding your objects, prevents forge from being able to dynamically load/unload mods and can cause weird, unreproducible crashes.How: Use the @ObjectHolder annotation if you need static references to your objects and create & register your objects in the appropriate registry event. (Note: before registry events Modders created and registered their items in preInit. This practice became out of date in 1.7 with the introduction of registry events, and is no longer possible in 1.13). What: Using @Override.Why: Using @Override tells the compiler that you intend to override a method. This lets your IDE warn you about bugs before they happen.Consequences: When you update your mod to a new minecraft version/ update your mappings/ update your Forge version and don’t use @Override, methods will silently stop overriding what they should override due to name changes, and will fail to ever be called, resulting in unexpected behaviour, crashes and bugs.How: Just annotate methods you intend to override with the @Override annotation.

I "solved" this by removing the library as a dependency and copying all the code into my mod then commenting out the @Mod annotation and calling stuff from my (non-dependency) mod. I "solved" this by making a dev version (with gradlew jar instead of gradlew build) of my library and putting it in both /libs/ and /run/mods/

Make sure you've (re)imported the project twice. How are you running user dev and what IDE are you using?

I've updated my library mod to 1.13.2, but I'm having trouble adding it to my project. Putting it in /libs doesn't do anything by default. Putting it in /libs and adding compile fileTree(dir: 'libs', include: '*.jar') doesn't load the mod when I launch the game Putting it in /libs and adding deobf fileTree(dir: 'libs', include: '*.jar') tells me that deobf isn't implemented for files yet and that I need to use maven Putting it on CurseForge and using the CurseForge maven (yes the dependency string is correct) doesn't load the mod when I launch the game Putting it on CurseForge and using the CurseForge maven (yes the dependency string is still correct) results in the following errors (using different versions of the mod) - https://gist.github.com/Cadiboo/71ba7b723c194215f9beab01c3260925 - https://gist.github.com/Cadiboo/8a7976add44f5d3e6ca0b282dac428f9 Note that it looks in file:/Users/Cadiboo/.gradle/caches/forge_gradle/bundeled_repo/renderchunk-rebuildchunk-hooks/RenderChunk-rebuildChunk-Hooks-1.13.2/0.4.0_mapped_snapshot_20180921-1.13/RenderChunk-rebuildChunk-Hooks-1.13.2-0.4.0_mapped_snapshot_20180921-1.13 and in file:/Users/Cadiboo/.gradle/caches/forge_gradle/bundeled_repo/renderchunk-rebuildchunk-hooks/RenderChunk-rebuildChunk-Hooks/1.13.2_mapped_snapshot_20180921-1.13/RenderChunk-rebuildChunk-Hooks-1.13.2_mapped_snapshot_20180921-1.13 In both the last part of the version is missing (pre2 in the first one, and 0.4.0 in the second) I am able to get it into my project by - Putting the library in /run/mods/ - Also putting the library in /libs/ - Telling grade to add the file in /libs/ as a dependency with compile fileTree(dir: 'libs', include: '*.jar') in my build.gradle This allows me to compile my mod in user dev, and build it into a full mod with gradle build, but when I launch user dev it crashes because of an NoSuchFieldError on an SRG named field reference in my main mod class. Error: Failed to create mod instance. ModID: render_chunk-rebuild_chunk-hooks, class io.github.cadiboo.renderchunkrebuildchunkhooks.RenderChunkRebuildChunkHooks java.lang.NoSuchFieldError: field_178592_a at io.github.cadiboo.renderchunkrebuildchunkhooks.RenderChunkRebuildChunkHooks.<init>(RenderChunkRebuildChunkHooks.java:22) ~[?:1.13.2-0.4.0] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:1.8.0_191] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) ~[?:1.8.0_191] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[?:1.8.0_191] at java.lang.reflect.Constructor.newInstance(Constructor.java:423) ~[?:1.8.0_191]

Put it on GitHub gist. No ones going to download a random text file (and people on mobile can’t)

This sounds like an XY problem. Post your code and a screenshot of the problem

Forge blockstates are in the latest (and only the latest) 1.13.2 beta.

You're saying the equivalent of “Build me an airplane then I’ll go and learn how to build one myself”. That information is Get the armor slot index and call Minecraft.getInstance().player.inventory.armorInventory.set(armorIndex, itemStack); Note: Minecraft.getInstance and everything else from that snippet is from 1.13 mappings. Names may not be the same in your version (Minecraft.getInstance is Minecraft.getMinecraft on <1.13)

Optifine has not finished forge compatibility yet. It’s been 2 days.

Post your entire log please

Take the code, and put it in a method, substituting the variables for parameters. If you need more help, google “java method”

You could put that code in a method, or write it out for every entity