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 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.

If you can't view vanilla code from your IDE, get that fixed ASAP. It's absolutely critical to be able to see how vanilla and Forge code does stuff, not to mention being able to set debugging breakpoints.

Have you looked at how vanilla animals (e.g. pig or sheep) do it? Mob entities (which include animals) have goals, which are registered and run by the entity's GoalSelector object. Every mob entity has a goal selector, which is public, and the goal selector has a getRunningGoals() method to get all of the currently-active goals. Take a look at e.g. PigEntity and find the obviously-named goal which controls panic behaviour. That should be all the info you need. It might actually be simpler just to check that the animal has a non-null getRevengeTarget()... depends on how much control you want over the process. An animal can have a revenge target but not have a running panic goal if it can't find somewhere to flee to, for example.

Going to guess that the entity in question doesn't extend LivingEntity, in which case see or one of the other several threads I found by Googling "forge 1.14 entity renderer". And yeah, ditch that itemModelMesher code like yesterday It's utterly unnecessary.

Hard to know for sure without seeing your code, but I'm guessing you're doing the "consume" operation client-side, and that's not to going to work. When the button is clicked, the server needs to know; in other words, send a custom "this button was clicked" packet to the server, and do the inventory change there. Changes don't get magically sent to the server if you modify a slot client-side; if you look at vanilla code, you'll see packets are used to handle this (take a look at PlayerController#windowClick() for example - modifying the container slot and sending a packet to the server are done separately).

Apart from what diesieben said, if you're adding capabilities to your own item, you shouldn't be using the AttachCapabilitiesEvent. Instead override initCapabilities() and return your capability provider there (see BucketItem for an example of how Forge attaches a fluid handler capability to buckets).

As Cadiboo pointed out, you're not editing the original AI - you're editing the AI in your subclass, which inherits the original AI. SquidEntity.FleeGoal itself has a private constructor, so you'd need to use reflection to access it. But if you simply want to get rid of it, the cleanest way is probably to override SquidEntity#registerGoals() to simply not add the FleeGoal in the first place. The base registration method also adds a SquidEntity.MoveRandomGoal, which you may or may not want to keep. If you do, it's conveniently public.

Creating any registry objects (which includes blocks and items) dynamically is a big no-no. You can't do it.