desht

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 alternative GL blend function (GL11.GL_SRC_ALPHA, GL11.GL_ONE), and GL_GREATER rather GL_EQUAL in the alpha func. Update: just realised you're already using GL_ONE in a custom render type. Have you also provided the finishRender() method in your render type?

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 reddit, and got deleted with 24 hours. Maybe your efforts would be better spent contributing to Bewitchment, a spiritual successor which doesn't use any of the original mod's assets?

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 publish anything containing any code or assets from that project, since it's not open-source. And you can't call anything you release "Witchery" either.

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/recipes looking like: { "type": "mymod:my_recipe" } For an example of how I register custom crafting recipes, see https://github.com/TeamPneumatic/pnc-repressurized/blob/1.14/src/main/java/me/desht/pneumaticcraft/common/core/ModRecipes.java

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

Interact evens are fired on both the client and server, and potentially for both the main and off hands.

Your pool is of type "alternatives", which means "select one sub-entry from a list". Your second sub-entry (dirt_chunk) has no condition, so it's always successful; therefore the third entry (grass_seeds) will never be reached.

I'd recommend looking at McJty's tutorials here, especially parts 13 - 15 for 1.15.x rendering topics.