Leaderboard

Ah sorry! I somehow forgot to push to remote for quite a while. Anyways, here is the blockstate file. (Note that by item_pipe I meant the model of the pipe that transfers item, as opposed to the item model of a pipe) In addition, SixWayBlock can handles almost everything about the blockstate and collision boxes of a block that can connect to 6 directions (i.e. pipes). Check out the vanilla chorus plant for usage.

Are you SURE you wanna search 531,441 spots for cake... All in one loop, presumably all in one tick? The answer is no, that's a horrible idea. Secondly, BlockPos IS immutable. The point of the toImmutable is to convert the MutableBlockPos to BlockPos. So either remove the new, or remove the toImmutable Third, are you sure it's actually being set? toImmutable will never return null so it's most likely that you're not being hit at all, or that something else is unsetting it.

Creating new loot conditions isn't that hard. Vanilla has tons of examples, and while I haven't done a condition, I have done advancement triggers, which are pretty similar. If you don't know how to implement the interface directly, copy an existing implementation, find the test() method, modify to return true when you want it to be true (adding undefined variables for the conditions specified by the json file) and working backwards until the errors are gone.

Yes, that's how generated item models work.

As the Optional annotation has now disappeared in favour of capabilities, there is now no way to add optional features to non-TileEntity blocks. An example use case would be proper fluid handling for vanilla cauldrons, or handling of different blocks' "heat" values. It would have to return a function (BlockState, IWorldReader) -> custom capability instance. And couldn't be cached without more work. The capability would also not be able to be serialisable to NBT (obviously non-TEs don't have NBT). It would effectively be a mapping of blockstate -> capability. If we restricted it to readonly capabilities there would be no issues with modders caching the capability and modifying something they shouldn't, but it would for example allow extraction from cauldrons, but not insertion. The optimum solution would be for the capabilities to be cached when first accessed (Probably by calling World/Chunk#getBlockCapability(Capability, BlockPos)) which would then be returned every time afterwards (until the position was unloaded). It would allow ModB to support ModA's X system, without having to inherit from an API which may not exist at runtime. This post is intended as the starting point of a discussion, if it is an idea that no-one is interested in, that is fine. The alternative is to just ship ModA's API with ModB, or at least the interfaces you are implementing in your block, but that has no way of adding capabilities to blocks which you don't own (e.g. vanilla cauldrons, torches).

Those classes are erroring because those classes no longer exist. You have to look at what vanilla is doing for its tools now. And mimic it.

Did you write that manually? If so, throw it out and use datagenerators.

GitHub Gist is literally in the list that is in my signature...

Make a github account, then use a github gist, that's how I share debug logs

I tried to launch the eclipse forge.But it didnt find the MC_VERSION.

This function is both unused and useless. NAME is also unused. Beyond that, I don't see any obvious issues that would be causing your problem.

1.12 is no longer supported on this forum. Please update to a modern version of Minecraft to receive support.

Why don't you try to port it to 1.15 or 1.14?

Are you sure you need a 1.12.2 mod? There is no disadvantage when you use 1.15.

I personally like version 1.12.2 pretty much, so I prefer to work on that one. Updating to a newer version is no option for me since I need a 1.12.2 mod.

I'm sure this is an outdated version. Why aren't you modding in newer versions like 1.15?