imacatlolol

Are you using @Mod.EventBusSubscriber? If so, your event methods need to be static. Also, instead of printing directly to the console, it's generally better to print with a logger instance via LogManager.getLogger(). Using your IDE's debugger is also great for testing whether or not code is being run.

IItemTier isn't an item class, so of course you can't register it as one. Like I said, look at how vanilla does it. You need to register something that extends from Item, so SwordItem, ToolItem, etc. If you're just trying to make a simple sword, you could just register a new instance of SwordItem without making a custom item class.

That stuff is controlled by the IItemTier you input in the first part of the SwordItem's constructor. Investigate the ItemTier class to see how vanilla does that. All you should have to do is make something that implements IItemTier and use it in your sword's constructor.

What problem are you having, exactly?

The game runs a server and a client, the server does most of the logical work while the client mainly handles input and rendering. You can read up on the server/client a bit here. The events I mentioned (PlayerContainerEvent.Open and GuiOpenEvent) are things you can subscribe to and run some code when the events occur. Read this to see how events work. Both of those events offer a way of accessing an instance of HorseInventoryContainer, which is what controls what items are allowed into a horse's inventory. By changing the saddle slot in this container, you will be able to allow your saddle to be placed in it.

Hmm, I've never tried this, but it seems doable. I think you'd have to listen for the horse's container to open on the server with PlayerContainerEvent.Open and on the client with GuiOpenEvent, then replace the saddle slot with your custom slot that also accepts your new saddle.

Huh, I was convinced that would fix it... I did some more digging and found out that Lex made a workaround for the latest versions of Forge, so try updating to the latest version (31.1.47 at the time of writing) and see if that fixes it.

Your pattern is "III", " I ", " S " maybe you meant "III", " S ", " S " instead?

You would create a new item stack of whatever type of potion you're trying to make. Items.POTION, Items.SPLASH_POTION, and Items.LINGERING_POTION are the vanilla ones. You could either do new ItemStack(item) or item#getDefaultInstance() to get a stack of any item.

You can use PotionUtils.addPotionToItemStack, then use the resulting stack as an ingredient.

Ah, I've never been very good at clarity, my bad. Glad you got it working!

Investigate EndPortalTileEntityRenderer for details on how that effect works. It seems to use RenderType.getEndPortal for the meat of it, so take a look at that as well if you want to use your own textures or change things up a bit.

You have "tag": "realism:ruby" as an ingredient, have you made sure such a tag exists? If you just want to use that specific item, you'll want to use "item": "realism:ruby" instead.

It's a static method. You just call it directly in the client setup event (FMLClientSetupEvent). It wants a Block and a RenderType, so simply provide it with what I said. I'm not sure what the confusing part is, this should be basic Java. If you don't know how to subscribe to events, read the docs.

Different items is generally preferred for this case. Vanilla does this (separate blocks and items for each thing that uses dye colors), and I believe it's better for general usability of the mod as well as performance. If you're dead-set on using a single item, you would have to use NBT data. That can be a bit messy and is really overkill if you're just using those 16 colors, so using separate items is advisable. If you were mixing colors then I'd recommend taking a look at how leather armor does that using NBT data.

You need to call RenderTypeLookup.setRenderLayer in the client setup event to define the block's render type. I recommend using CUTOUT, but CUTOUT_MIPPED would also work.

As I expected, you need to reset your Gradle cache. I'm honestly not super familiar with Gradle as a whole myself, but I believe the best way to do so is to navigate to the .gradle folder in your user directory and delete the caches folder. You will have to wait for Forge to redownload and reprocess the game, but it should work perfectly afterwards.

Well there's a few options, but here's my initial idea. You could make a couple methods for adding black or white keys respectively and then have those methods call addButton and also place the keys in separate lists. Then, you could override the mouseClicked function of your screen and have it first iterate through the black keys and check the result of their mouseClicked function, then the white keys, and then fall back to the default behavior.

One option would be to have it check if any black keys are hovered first, and if so, completely skip the check for white keys. You'd probably have to restructure the way you're performing checks whenever the user clicks, but it's certainly doable.

First of all, keep in mind that mod ids have to be entirely lowercase. As for the error, it's value="modid" not modid="modid". You can also just type the mod id directly, so: @Mod("modid").

Yes, you certainly don't need to have every block be a tile entity. Use block states to determine whether or not the block should render by overriding getRenderType. When interacting with the block, you could have it point to some "core" block that actually has the tile entity, and make it interact from there. The exact method for that would vary depending on your intent, and I'm sure someone could come up with a better solution, but my rough idea would be for it to have each block in the multiblock point to a neighboring block via a DirectionProperty, which would point to another block, which would eventually point to the "core" block that houses the tile entity. (You can't store block positions in block states, right? I'm not 100% sure, to be honest.)

You need to use Java 8 for modding. If you get further errors after switching to Java 8, you may have to reset your Gradle cache.

GL_SPHERE_MAP is used for spherical environmental reflection textures, to my understanding; they have nothing to do with actually drawing spheres.

Show your code for creating and registering your BlockItems, they seem to be missing actual blocks.

@TheGreyGhost Thank you for the tips! I spent a while digging into the lighting code but didn't manage to find anything wrong. Instead, the problem was quite simple and I feel pretty silly for not noticing. The TileEntityRendererDispatcher calls RenderHelper.enableStandardItemLighting before rendering tile entities, so I simply had to call the reverse before rendering the block model and it worked flawlessly. Also, I changed my code to use BlockRendererDispatcher#renderBlock instead of renderModelSmooth for the sake of accuracy to vanilla, in case anyone cares.