desht

Read the javadocs for the isKeyDown() and isPressed() methods of KeyBinding. They make it pretty clear which of the two methods you should be using in a tick event handler.

Expanding on this: If you intend for your capability to ever be used by other mods (i.e. you're making it part of your mod's API) then using an interface is very strongly advised, simply as good programming practice (expose the interface, not the implementation). If you only ever intend for your capability to be used for storing data for your own purposes, an interface is very much optional. You might decide it's useful to have one, just for tidiness in your own code, but then again you're free just to use a class.

Vanilla buckets know nothing about a modded block whose tile entity offers a fluid capability. You need to code the bucket-filling logic in your block's onBlockActivated() method. Tip: don't just check for a bucket, check for any item which offers the CapabilityFluidHandler.FLUID_HANDLER_ITEM_CAPABILITY, since that would also allow other mod fluids containers (tanks etc.) to be filled from your block.

Yeah, I had this problem too in PneumaticCraft, but (with much thanks to Botania, which does it right with the mana pool particles), I got it figured out: You will need a custom particle render type, like this: https://github.com/TeamPneumatic/pnc-repressurized/blob/1.15/src/main/java/me/desht/pneumaticcraft/client/particle/AirParticle.java#L91 And return that from your getParticleType() method: https://github.com/TeamPneumatic/pnc-repressurized/blob/1.15/src/main/java/me/desht/pneumaticcraft/client/particle/AirParticle.java#L71 The important thing is the al

That's because the concept no longer exists in Minecraft as of 1.13, aka "the great flattening". Read https://gist.github.com/williewillus/353c872bcf1a6ace9921189f6100d09a#whats-the-deal-with-metadata for much more info.

The signature looks scary at first glance, but it's actually fairly simple: props.setISTER(() -> YourRenderer::new) where YourRenderer is a class you create that extends ItemStackTileEntityRenderer, where you override/implement therender() method to do the rendering.

A little more complicated, but not unnecessary. It's down to how 1.15 handles rendering, basically by combining all operations for particular render type together, which greatly reduces the number of OpenGL state changes needed. It's a big performance boost.

Emoniph's whereabouts are unknown, as far as anyone can tell. Not necessarily dead, but not reachable. Unfortunately, just because the mod hasn't been updated, and the author can't be reached, that doesn't give you the right to use any of the assets, even with acknowledgement. The mod's licence very explicitly forbids that. As for repercussions... well, you might or might not get a C&D notice, but I can pretty much guarantee that Curseforge (and probably other platforms) won't host it. Someone else ported the mod to 1.12.2 not along ago, and posted an announcement to the feedthebeast

JSON models don't support arbitrary rotations, only increments of 22.5 degrees on one axis. See https://minecraft.gamepedia.com/Model#Block_models for a detailed description of the format (note the "angle" tag that elements have). If you need something more flexible, an OBJ model is probably your best bet. I don't know offhand how Witchery did it - might even have been a TESR, though using a TESR for static models isn't a good idea. Regarding the legality of recreating Witchery: there's nothing to stop you using the code or assets privately, for just "practice". But you cannot p

Another useful Intellij shortcut here is Ctrl-N, the default binding for Navigate -> Class... Press Ctrl-N and type in the name, or part of the name, of the class you want to find (in this case TorchBlock). You might also need to press Ctrl-N a second time, to toggle on the "include non-project items" checkbox, since TorchBlock isn't part of your own project. This works for any class known to your project, including all those in external libraries like Forge and (deobfuscated) vanilla code.

Yeah, I think you're right that CookingRecipeSerializer.IFactory needs to be public to be able to extend it in any useful way. I'd say a PR to Forge is needed there (just an AT entry to make IFactory public, so pretty simple). You do need to move away from statically creating your recipe type and serializer objects, though, same as for any other registry object.

Not true. GrassBlock also implements IGrowable, which is where you should be looking.

I haven't done anything with cooking recipes specifically, but all vanilla recipe serializers are now Forge registry objects. So registering your own serializer is now done like any other registry object - either via RegistryEvent.Register<CookingRecipeSerializer> and @ObjectHolder, or (preferably) using the new deferred registry system. So it should (like I said, I haven't tried this with cooking recipes, only crafting recipes) be possible to register your custom cooking recipes with a registry name of (say) "mymod:my_recipe", and then have a recipe JSON in your data/recipe

Regarding "unnecessary lag": if the sole reason for a tile entity is for rendering, your TE does not need to tick and thus won't produce any lag. Technically, the presence of any tile entities in a chunk mean a little more work to load the chunk, but if you have enough instances of your TE in a chunk to cause loading performance issues, then you probably also have enough to murder client performance with all the rendering that's going on. tl;dr non-ticking tile entities produce zero lag unless you grossly abuse the feature.

Yep. Also, bookmark this, since the blit() param names aren't deobf'd: https://github.com/mekanism/Mekanism/blob/1.15x/src/main/java/mekanism/client/gui/GuiMekanism.java#L226-L233