ChampionAsh5357

Nope, just understand toml and comments. No forge modding understanding required. Although I have been programming in Forge correctly for a while now, it still is not necessary. However, your issue more relies on reading the gradle documentation. The forge docs was only to add the dependency block that says "hey, i require this to load". That's exactly what you're supposed to do.

Well looking at gradle docs and the forge docs is always a good start. That's fine, still need to know java though to get it working. This part makes it sound like less like an actual mod and more like just modifying a vanilla loot table. So, you're probably going overkill making a mod when all that's needed is probably a datapack.

Ok, can you show the entire code block for the event then? Because with what I see now, I think it might be a different place that is causing the infinite check.

Probably since the float field is never synchronized to the client (my guess anyways). Also, don't construct a map every time you try and get the default item. Construct the map once and then never again.

Just because something is easier doesn't mean it is right. Feel free to try and find a fix the way you are doing it. However, the correct way would be to create two separate blocks that are within the bounds.

I'm confused on this statement. It doesn't lock onto one sheep, it finds the nearest village structure within 70 blocks of the specified position regardless of if the chunk exists or not. It will also only call whenever an animal is trying to be spawned in the world, so this seems a bit flawed for testing if a structure is present. It doesn't lock necessarily, you'll just find the same structure within the specified distance unless you get far enough away for an animal to not be in range of a village. Not really deterministic.

First, you can't do this, your block might not be initialized at that time and can throw an error. Also, the you could look at the configuration provided by a tree within DefaultBiomeFeatures and see the differences. A good one being that the foliage height is never greater than the base height. Another one being that the spruce foliage placer is never called with foliage height anywhere within the vanilla features. I haven't looked into trees all that much so I don't know exactly where it goes wrong, but you can assume that certain values are set and not set for specific reasons and use that to assume what are reasonable calls to chain or values to set.

A block should never be more than a 16x16x16 area or else these any many other issues start to occur. You must split the block in two and make it a multipart of sorts. Also, assuming you understand the render types, make sure you are not unnecessarily using one which is not relevant to what you are doing.

1.12.2 is no longer supported on this forum. Please update to at least LTS 1.15.2 to receive support.

All this information should be provided regardless. Please include the debug.log instead and the build.gradle if modified.

Probably would help if your wrote your inventory to your tile entity nbt and read it from there.

Here's the logic: if in storage -> try and merge to hotbar, if fail try to merge to inventory else if in hotbar/inventory -> try and merge to storage else if neither -> try and merge to inventory I believe this is the logic used by vanilla iirc. But to answer your question more effectively, yes. You just need to include the indexes of the inventory/hotbar.

Make your own method that handles it? Or you can just create a wrapper of some kind that Forge may or may not provide.

So your slots cover 0-44, player inventory is 45-71, and hotbar 72-80. Your transfer method override only checks if index is storage, move to storage, else try and merge to storage. So you don't have any logic to move into the player inventory.

Then it seems that your storage block doesn't check the inventory slots. Assuming your storage block takes up slot 0-8 (for example), you would need to check if the stack can merge to 9-44.Once again, this mainly depends on how the inventories were added to the slots.

I answered that as well.

You need to override that method and handle it yourself. If you use the same implementation, it might work, it might not. Depends on how your slots are set up in the container.

Container#transferStackInSlot, the implementations of click handling should be already done by ContainerScreen, just need to override the resulting stack change.

Probably doesn't exist. Most information can either be retrieved from looking through the source or asking someone who've might have done it. Reading more about a particular topic most likely won't be well known or even present unless someone is copying someone else's explanation of a system.

You would probably need to change the width of the string rendered somehow. It's definitely possible with all the tools in FontRenderer or your own method.

There should be an instance provided by the event. It's just the rotations, translations, and scales used by the game to specify where to render your object. The other is an ITextComponent which you should know and then followed by the x and y values.

The way to set up symmetry is to click the butterfly icon on the drawing tool of your choice. From there, you need to scale the reflection to occur in what area. Then depending on what reflection you chose, the program will place the subsequent pixels in the other regions provided it's in the specified area.

Well that would make sense, you are using a font renderer that writes vertically. You can just use FontRenderer#func_243246_a or FontRenderer#func_243248_b without the drop shadow.

Two things I suggest, reverse the order of rendering so that the item renders first and then the entity. Other thing is change the graphics to fabulous. I think only one of these will work. My theory though is that the item is being culled out from the ItemRenderer#renderItem as it uses a culling render layer. Since it's inside another block, it's being told that hey, you can't render here. So you'll probably need to make your own version that removes the culling feature from it rendering.

Well you know the position of the waypoint and the current position of the player. You also know the current rotation and yaw of the player as well. You can also figure out when to check for if the area is loaded. Take that as you will.