Choonster

This is true, but it's worth noting that user-added resource packs will take priority over mod resource packs. This means that if a user-added resource pack and a mod resource pack both replace the same file, the one from the user-added resource pack will be used.

The GUI needs to send a packet to the server, which will perform the action in the packet handler (if the player has permission to do it).

This is what the sided proxy system is for. Create a method in your base proxy class called something like registerModel and then override it in the client proxy to call ModelLoader.setCustomModelResourceLocation. Keep in mind that ModelResourceLocation is also a client-only class, so you can't have it as a parameter of the method. Instead, you'll need to have the name as a parameter and create the ModelResourceLocation in the client proxy's override method. You can read more on sides here.

Only use AttachCapabilitiesEvent to attach capabilities to external objects. For your own Items, override Item#initCapabilities to return a new instance of an ICapabilityProvider implementation that provides the capability instance. Your ICapabilityProvider should store the IItemHandler instance, implement ICapabilityProvider#hasCapability to return true if the Capability argument is CapabilityItemHandler.ITEM_HANDLER_CAPABILITY and implement ICapabilityProvider#getCapability to return the IItemHandler instance if the Capability argument is CapabilityItemHandler.ITEM_HANDLER_CAPABILITY.

Either set those values on the ItemStack before you add a recipe for it or create your own recipe class and set them in IRecipe#getCraftingResult.

In your Container#detectAndSendChanges override, iterate through Container#listeners and check if each one is an instance of EntityPlayerMP. If it is, send your packet to them. In your packet's handler, you can either call Container#updateProgressBar or your own method to update the client-side data.

PlayerEvent.PlayerLoggedOutEvent

On closer inspection, overriding Block#shouldSideBeRendered to return false won't affect an OBJ model as OBJModel.OBJBakedModel always returns an empty list from IBakedModel#getQuads when the EnumFacing isn't null. Are you sure ClientProxy#preInit is being called? Set a breakpoint in it to make sure. Set a breakpoint in OBJLoader#loadModel. Is it ever called for your pedestal model?

You override Block#shouldSideBeRendered to return false, so no sides of your block's model are rendered. What does your TESR render? Post your TESR class.

Looking at the decompiled source, it seems RWTema has created his own model system on top of the existing system. Unless you know exactly what you're doing, it's probably a lot easier to just use the existing system rather than trying to implement your own.

Could you post your Block class?

It looks like you didn't call OBJLoader#addDomain for your mod's resource domain, so the OBJ loader wasn't loading models in that domain.

I don't think Minecraft stores this information. You'll need to store it yourself.

Which mod are you talking about? If it's DenseOres, the models and textures are generated at runtime.

Short answer: No. Long Answer: You can use Forge's Blockstates Format to reduce the number of models you need to create. You can use OBJ and B3D models instead of JSON models. You can create your own model loader and generate models at runtime.

No. I suggest you look up any terms you don't understand and look at examples in Forge's code.

Yes. Your code has several issues: You're trying to create and register your IItemColor from common code, which will crash the dedicated server. You need to do this from a client-only class. You're storing your own Map of IItemColor instances and never using it anywhere. Delete this Map and register your IItemColor using ItemColors#registerItemColorHandler. Get the ItemColors instance from Minecraft#getItemColors. You're calling ItemEternalCrystal#registerItemColorHandler with an empty Item array. You need to call ItemColors#registerItemColorHandler with your Item instance.

So you create your own.

Simply change the value of the version property in the minecraft block of your build.gradle, re-run the setupDecompWorkspace Gradle task and refresh your IDE project (click the "Refresh all Gradle projects" button in IDEA's Gradle window or re-run the eclipse task and refresh the project in Eclipse). You can also update the MCP mappings used for your project by changing the value of the mappings property in the minecraft block of your build.gradle. The same process applies for refreshing the project. Note that you can change the Forge version and the MCP mappings version at the same time, you'll only need to refresh your project once.

Start by reading the documentation.

You can suggest name changes on the MCPBot Issue Tracker. You can use MCPBot itself to find the SRG name of a field/method/parameter.

Either create your own packet using the Simple Network Wrapper or send SPacketWindowProperty if you want to keep using Container#updateProgressBar.

Use SlotItemHandler instead of Slot. IItemHandler doesn't have the same "fields" concept as IInventory, so you'll need to re-implement the syncing yourself.

The acceptedMinecraftVersions property of your @Mod annotation controls which versions of Minecraft your mod will be allowed to load on. If you don't reference any classes, methods or fields that have changed between the versions you want to support, it's entirely possible for the mod to work in multiple versions. That said, very few mods are able to do this.