Cadiboo

That snippet you posted adds a place to get a dependency from, and a dependency to download. When you re-import your gradle project and/or run setupDecompWorkspace gradle will try and find this dependency. If it finds it, it will download it and because of the "deobfCompile" keyword it will deobfuscate it and remap it to your current MCP mappings. You might want to read https://docs.gradle.org/current/userguide/declaring_dependencies.html. You can also add dependencies by directly dropping them into ProjectRoot/libs/ and reimporting your gradle project and/or running setupDecompWorkspace (These will deobfuscate your library too). Actually adding your shears based on these mods is a whole other topic/issue, and depends on the mod you're adding compatibility with. If you always want these other metals, or don't want to deal with separate metals for every mod, you could use one of the popular Metal libraries like BaseMetals for example. I'm assuming you're doing this for 1.12.2.

Don't hijack someone else's thread. Make your own thread and include your debug log. You can find instructions on how to locate your debug log in my signature (the text below all of my posts) and the EAQ.

This topic is about putting dependencies inside your finished mod and has nothing to do with your problem. Please create your own topic and include the version your are writing your mod for. You shouldn't need any of that in your build.gradle, everything from /libs/ is added automatically.

Post your log as described in my signature and the EAQ

Make your own forum thread, this has nothing to do with this thread. In future don't hijack other threads. Jabelar has some tutorials on stuff like this at http://jabelarminecraft.blogspot.com

Which is a great impulse, however the way they got stuff to work was convoluted, unstable and overly-complicated. This isn’t that much of an issue in itself, they can go back and fix their code. The issue is that this code is not suitable for tutorials.

The MCPBot GitHub has something about 1.12.2 -> 1.13. Also https://gist.github.com/williewillus/353c872bcf1a6ace9921189f6100d09a

I know there is a way to register them only if another mod is installed, and you can look at forge’s ConditionFactory.

Yes, if EnergyManager extends EnergyStorage it implements IEnergyStorage

It’s being phased out in favour of fast util IIRC

You can have conditions recipes

IHasModel is fine if it’s used for what it’s meant for, a high level of control over individual item models. For example if your mod has lots of items with many variants and complicated models. It is not fine for beginners as it complicates their code, they don’t need it and they probably don’t understand how it works, why it’s used or what it does. Therefore it shouldn’t be in tutorials. @devguydan Some good tutorials include MinecraftByExample, ShadowFacts tutorials, Jabelar’s tutorials and Cubicoder’s tutorials. I’ve also heard that McJty’s tutorials are good, but IIRC they use IHasModel and CommonProxy. I’ve got a list of tutorials and resources at https://github.com/Cadiboo/Example-Mod and I’m also doing my own 1.13.2 tutorials.

Also don’t use this, just override hasTileEntity and createTileEntity

Please post the solution for people with same problem!

Yes they do matter. They break your own mod and other peoples mods. Usually text based tutorials have something at the beginning saying “learn java”. This is important. Most video tutorials say “I’m just starting, this is what worked for me. Do this, this, this and this. Why? Because.”

The vanilla equivalent. Find out how it normally works

Step through your code with the debugger, see where that method would normally get called. Find out the difference between stuff that works and your code

1x energy storage in an instance field 1x (anonymous) class that wraps said energy storage (all methods delegate to the energy storage except canRecieve and receiveEnergy) in an instance field 1x (anonymous) class that wraps said energy storage (all methods delegate to the energy storage except canExtract and extractEnergy) in an instance field

Post your logs as described in my signature and the EAQ.

Your package name should not contain “main.java”

Does this ever get called?

Also, it seems like a good idea initially when you’re adding super simple blocks. Write some code once and have it done nearly automatically & keep your registration super simple. However once you start trying to do more complicated things like adding logs or stairs (stuff with multiple blockstates and variants) it’s not feasible as you now need to recreate all the logic from the vanilla class rather than just extending it. And because minecraft handles a lot of stuff based on class and using instanceof, your copy might not work the same way as vanilla’s. Now you have a game breaking bug that logically shouldn’t happen. The alternative to this is to add 1 method in your registry class and call that method on each of your objects. Using this way, you write less code and don’t run into unexplainable bugs.

Taken from https://gist.github.com/Cadiboo/fbea89dc95ebbdc58d118f5350b7ba93 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..... (Can’t past the rest because mobile)

No, have one normal energy storage. Then have a wrapper for that storage that can only receive and another wrapper that can only send.