Cadiboo

Refresh the gradle project in IntelliJ, I assume run gradlew eclipse for Eclipse. For reference, those 2 are equivalent to setupDecompWorkspace

Forge 1.13.2+ multi-threads mod initialisation. That’s probably as close to what your suggesting as is possible.

When I had this bug it was caused by me using "layer_0" instead of "layer0" in my model's textures. This is unlikely to be your problem though. As diesieben07 said, post your code.

Capabilities are a better way of achieving the same thing as Interfaces. Interface way: if (tileEntity instanceof IThing) Capability way if (tileEntity.hasCapability(ThingCapability)) Interface way: ((IThing)tileEntity).doThing(); Capability way tileEntity.getCapability(ThingCapability).doThing(); Interfaces make your tile be something while Capabilities let your tile provide something. Capabilities follow the OOP concept of "Composition over Inheritance".

What parts of them?

All the mods I was talking about are on 1.12.2, I’ll see if I can get you a list, but I don’t remember the names of most of them.

The file needs to be in META-INF, and it may also need to be named accesstransformer.cfg. You can see my mod using it at https://github.com/Cadiboo/NoCubes/blob/9e47ebe0924e5f846babd238bb34b7ee0c2b45d7/build.gradle#L42 and https://github.com/Cadiboo/NoCubes/blob/9e47ebe0924e5f846babd238bb34b7ee0c2b45d7/src/main/resources/META-INF/accesstransformer.cfg

You would need to look at the other mod's code to see what its books require.

Forge has its own jar-in-jar system.

Gui#drawRect

There are many combinations of mods that have most of these features. I’m not sure about light bridges, fake fluids or player rugs, but pretty much everything else has been done

Seems pretty obvious to me. You have your texture named “” in your model, but the model parent (block_all) requires a texture named “all”

Your GitHub is not set up correctly. It doesn’t include your gradle scripts or any of the files needed to setup your mod. It looks like you have prior Java/C programming knowledge. With modding there are a bunch of conventions and best practices you should follow. A few of them are - not naming your packages “core” or “ASM”. These package names are conventionally used by coremods, and using them in a non-coremod context can lead to confusion. - pls pls space out your code! - using block base/tile base etc. is discouraged - your package naming is against conventions for a few reasons More at https://gist.github.com/Cadiboo/fbea89dc95ebbdc58d118f5350b7ba93 I can’t see what the issue with your models is (I find it hard to read your code) but it sounds like you have a static field that should be an instance field. You can view my custom baked model code (I don’t exactly recommend it 100%, but it works) at https://github.com/Cadiboo/WIPTech/tree/WIPTechAlpha/src/main/java/cadiboo/wiptech/client

A PR or Pull Request is you writing the code for a feature you want, and it potentially getting accepted into Forge. https://mcforge.readthedocs.io/en/latest/forgedev/

ResourceLocations as strings are in the from domain:path, <domain>:<path>, modid:name. The <> indicate that you need to replace them with actual values

Your change to the event sounds useful, if you make a good use case, then there’s a good chance that it will be accepted. Parts of minecraft are badly done, but there are mods to rectify this, and large parts of the engine are being rewritten (and some parts are being open/visible sourced) in 1.13+.

Welcome to Minecraft ?

Is there a problem with this method though? It seems to be that you’re doing the exact same thing as changing the damage source. If you feel it’s neccesary, Forge is open source and you can make a PR to add this feature. Because of the ability to already do something very similar, I think it would be unlikely to get accepted though

Steps: 1) Learn Java 2) Read the Forge docs 3) Ask for help on discord/irc and the forums 4) Lots and lots of trial and error

What’s the problem with that method? Does it not achieve the exact same thing?

Not sure what you mean. You can 1) have objectholder on your class and name your fields after the registry path of your object 2) have objectholder on your fields with the full registry name of the object I’m not sure, debugging would probably be helpful. You can find where objectholder annotation lookups are applied by searching for “Holder lookups” with your IDE (text containing those words is logged every time objectholder is refreshed). I assume it would be <modid>:<name>, but avoid constructing Strings instead of ResourceLocations wherever possible.

Sorry for the bump, but the solution to this is to check if the block on the side is not opaque/normal. return !world.getBlockState(pos.offset(facing)).isNormalCube(); inside shouldSideBeRendered should do the trick. Returning false if the BlockState is of the same type as your block is probably also desirable.

No you don’t. You have it on your main class with your modid, and you have it in fields with only resource paths in an inner class. I’m not sure how entity entry registry names are dealt with, but as a general rule a resource location without a domain is interpreted to have the domain “minecraft”. You need to have all your registry names in the proper format.

You’re communicating with me right now. Alternate forms of communication are in my signature.

Please post your full installer log (it should be in the same folder as the installer).