Choonster

There doesn't seem to be any way to toggle off the tt formatting or clear formatting completely. Either this didn't work or there's some other restriction on editing. I edited a post a few time shortly after posting it, but now it's been about 8 minutes since it was posted and I can't seem to edit it any more.

Would it be possible to convert the [tt] tags in all the old posts to monospace font instead of code blocks? Having the [tt] tag work in new posts would also be more convenient than having to highlight the text and click a button. Most of my old posts are borderline unreadable because each section of inline code has been replaced with a code block.

If EntityLiving#getLootTable returns a non-null value, you can use LootTableManager#getLootTableFromLocation to get the LootTable from that ResourceLocation. You can then go through the table's pools and entries to build the list. If the entity doesn't use a loot table (e.g. EntityWither), you'll need to hardcode its drop list. Look at JustEnoughResources for an example of how to work with loot tables.

ContainerMessage is being sent to the client, so ContainerMessageHandler will be executed on the logical client side. This means that you can't use server classes like EntityPlayerMP and NetHandlerPlayServer, you need to get the client player instead. I do this using a method in my proxy that takes the MessageContext and returns the player. In the client proxy, I override this to return Minecraft#player if MessageContext#side#isClient returns true or MessageContext#getServerHandler#player if it doesn't. In the server proxy, I override it to return MessageContext#getServerHandler#player if MessageContext#side#isServer returns true or throw an exception if it doesn't (because something has gone wrong if you're getting a client-side MessageContext on the dedicated server). To be safe, you should probably send the Container's ID (Container#windowId) in the packet and check that it matches the open Container's ID in your packet handler before you update it with the packet's data. Vanilla packets like SPacketSetSlot do this.

Override it. Forge will call it when required, you don't call it yourself.

You never register CapabilityHandler on the Forge event bus, so CapabiltiyHandler#attachCapability is never called and the capability is never attached to any ItemStack. What diesieben07 said also applies, though.

As I said several times in my previous post, the intention was never to completely prevent my replacement from being overridden, just for it not to be overridden by resource packs that replace the vanilla model (e.g. minecraft:foobar). If a resource pack replaces the replacement model (e.g. mymod:foobar_replacement), that's fine.

I'm not suggesting that you'd want to stop a texture from being overridden, just that you might want your replacement of a specific model/texture to take priority over other replacements (which isn't possible to do reliably without a lot of hackery). If my mod replaced a vanilla model, the ideal behaviour would be that this replacement takes priority over user-added resource packs replacing the vanilla file; but user-added resource packs could still override my replacement file. Although I've just remembered that you don't have to replace vanilla models using resource packs, you can simply tell Minecraft to use a different model for the Item/Block in code. This way resource packs that replace the vanilla model are ignored, but resource packs can still replace your model.

It's what allows resource packs to replace files from mods, so it's useful in that respect; but if you're replacing a vanilla file you may not want that replacement overridden by a resource pack that also replaces the same file. A lot of resource packs only replace vanilla textures (but this definitely isn't always the case), so you could replace the model/blockstates file with one pointing to your own textures/models. A resource pack designed for your mod could still replace these, but a resource pack that replaces the vanilla textures wouldn't have any effect.

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.