Alpvax

.minecraft/logs Or wherever your gameDir is

Be careful when doing that, chunks are unloaded for a reason (reduce memory usage by not keeping all chunks in memory at once). Make sure you unload/unforce the chunk again when you're done. Otherwise your mod will have performance issues on worlds which have been played for a while.

Use a multipart model/blockstate is the easiest way to do it: https://minecraft.gamepedia.com/Model#Block_states Look at how the fence blockstate is defined (client-extra.jar) for an example, and just rotate about the other axis for up/down. That way you only need a couple of models for all permutations, and don't need a custom baked model. See mine (wire, has multiple states for each side so is somewhat complicated, but you can just look at the basic structure): Blockstate file: https://github.com/Alpvax/AdvancedAutocrafting/blob/1.15/src/generated/resources/assets/advancedautocrafting/blockstates/wire.json One of the model files (wire_arm is currently just base_wire_arm, but with a texture): https://github.com/Alpvax/AdvancedAutocrafting/blob/1.15/src/generated/resources/assets/advancedautocrafting/models/block/part/base_wire_arm.json For reference, my wire blockstate has an enum property for each direction (NONE, CONNECTED, INTERFACE, DISABLED) and each state shows something different ("arm"s are visible for both connected and interface, hence the | in the "when" json value. I would not recommend actually looking at my WireBlock code, it is overly complicated due to some experimentation I was doing with data generation and general messing around). Attached image for end result (before disabled got its own model).

There is always a log. As your code looks correct, I would say there's probably a line in your log file telling you what is wrong.

Code? Logs? We aren't magic (well, most of us, anyway ? ).

You will have to make a new blockstate file for each block (unless they have custom tile renderers, which I haven't looked into). You can use the same model for all of those files I believe. Also, look into data generators, it will help you generate all the files from code, saving you a lot of time.

Imagine if everyone used 2 character mod IDs. That means there would be a lot of conflicts, as there are only 26² possible combinations, but some would be more popular than others.

Actually yes. But only if the player uses the vanilla "recipes need to be unlocked before they can be used" mechanic. I believe you can relock the recipes, although I've never tried. Alternatively, make your own IRecipe implementation which checks whether or not it should be unlocked for the player creating it.

In your model JSON, set the "particle" texture to "#texture" (or whatever you want it to be). I went with the vanilla approach of having base models (in /part/) and then my textured models, which the blockstate references. I'm not sure if there is a better way, as I don't think you can pass in texture overrides from the blockstate file. My models are here: https://github.com/Alpvax/AdvancedAutocrafting/tree/1.15/src/generated/resources/assets/advancedautocrafting/models/block

The voxelshapes method takes values between 0 and 1, the model takes 0-16. You need to divide all your voxelshapes by 16.

Please keep this forum in English! Learn Java first, before you start modding. For your issue, look into resource packs, the vanilla format can support 3d models from JSON.

Copy one of the mappings from here: http://export.mcpbot.bspk.rs/ Into your build gradle (copy the existing format, just update the numbers).

You need to look into tile entity rendering (look at chests and shulker boxes opening animations

No, it would appear that I'm getting a 404 when using curl. I'm afraid I'm not sure what your issue is. I have just noticed that your mappings are for 1.14, but you're missing for 1.15. try updating your mappings.

This is the third thread I have come across from you now, all asking the same thing! Please stop spamming the forums and give people a chance to actually answer!

Are you on the school network. At least when I used to be at school the games sites were blocked. Can you actually access the site listed in the link?

One case I can think of would be to have a folder of optional mods (renamed with .disabled after the extension to prevent loading). When modpacks get large it can become more difficult to find the ones you are looking for, and I don't see how more organisation can hurt. You can search if you know what mod you are looking for but you can't search for "optional mods". Duplicates/different versions would get flagged up on launch. It could be put behind a config option.

Look through the vanilla code (tracing up the call path if necessary). Find a mod which does something similar to what you want and look through it's code (most mods are on GitHub somewhere). Ask specific questions on here, telling people what you want to achieve (for the user).

Look at VoxelShapes.or for multiple shapes at once. There is a getShape for if you want to override the selection shape as well as the collision shape.

Sounds like you need to sync the changes to the client when it changes.

This is not how you should add capabilities to your own items, you should override IForgeItem#initCapabilities: @Nullable @Override public ICapabilityProvider initCapabilities(ItemStack stack, @Nullable CompoundNBT nbt) { return new IMultitool.Provider(); } I can't really tell from the snippets you have posted, do you have a git repository? Use your IDE to set breakpoints to try and find what is actually null when that function is called.

Yes, that's what I'm going to continue to do. I misunderstood the following: to mean that the currently used mappings were available by default somewhere in my IDE.

class Provider implements ICapabilityProvider { private Supplier<IMultitool> multitoolSup; Provider() { this(() -> Capabilities.MULTITOOL_CAPABILITY.getDefaultInstance()); } Provider(Supplier<IMultitool> sup) { multitoolSup = sup; } private LazyOptional<IMultitool> capability = LazyOptional.of(() -> multitoolSup.get()); @Nonnull @Override public <T> LazyOptional<T> getCapability(@Nonnull Capability<T> cap, @Nullable Direction side) { return cap == Capabilities.MULTITOOL_CAPABILITY ? capability.cast() : LazyOptional.empty(); } } I had the advantage that my capability currently just acts as a flag, so I don't care about storing it for later use (i.e. I can just create a new instance every time with no issues). You will probably want to save the value of `supplier.get()` if you interact with it outside of the LazyOptional.

I discovered with my mod that due to the order of class loading (item registration depending on the ItemGroup from my main class) my initCapabilities method was being called before my capability instance was set, so it was attempting to call null.getDefaultInstance and throwing the error. I resolved the issue by wrapping it in an additional supplier, so the capability was definitely set by the time it was used.

No, it's a bump. You need to render your custom interface in the RenderGameOverlayEvent.Post (So it is displayed in front of anything else on the screen). You also need to make sure you only listen to one of the events (see RenderGameOverlayEvent.ElementType) to prevent rendering it multiple times per frame.