imacatlolol

Read up on how streams work. There's a filter method you can run on them to choose the specific thing you need.

Yes, or just use SimpleFoiledItem if you don't need anything else. Both will work.

Check out how vanilla does it in GrassColors, FoliageColors, and BiomeColors. Then use BlockColors#register in the client setup event ColorHandlerEvent.Block* to replace the vanilla block colors.

If you're on a version older than 1.14 you'll have to completely redownload the MDK and replace your gradle files. If you're on 1.14/1.15 simply change the minecraft version in the dependencies section at the bottom of your build.gradle.

Take the position of the block you destroyed with the tool, then use that as your reference point to get nearby positions. Then, use the world to get the states of the block positions you got.

Instead of checking if the stack is enchanted, simply return true. Since the stack likely isn't enchanted, it will return false otherwise. Also, there's actually a SimpleFoiledItem class in vanilla that you can use like you were doing before, without having to make your own class just for that.

It's a standard enforced by vanilla, i.e. Mojang. I believe it's for compatibility reasons, but it also helps ensure consistency. If I had to guess, it may also prevent weird conflicts as "Monster1" and "monster1" are technically different but may look the same, so requiring things to be lowercase likely helps with any strange issues that may arise from that.

Subscribe to the RenderGameOverlayEvent (Pre or Post, depending on your needs) and put your rendering code there. Important: Make sure to filter the event by calling getType on it, otherwise your code will be called multiple times which isn't good. For your purposes, I'd recommend filtering for the FOOD event type. To see what your rendering code would need to be, simply study how vanilla does it. A good example of what you're trying to do would be in ForgeIngameGui#renderFood.

Did you forget to register your entity's renderer? You need to use RenderingRegistry#registerEntityRenderingHandler in the FMLClientSetupEvent.

Oh my bad, I misread your entity class. Anyways, your check entity.goalSelector.getRunningGoals().findFirst().get().getGoal().getClass() == PanicGoal.class doesn't make much sense in the first place. Instead if picking the first running goal and seeing if it matches, you should specifically look for the goal you need.

Sadly this is currently not possible through conventional methods. There have been a few attempts to get this implemented in Forge, but nothing's come of it so far to my knowledge. Currently, the only clean-ish way to achieve this would be to use coremods or something similar, which can be quite complicated and requires a lot of caution. Someone more experienced than me would have to explain what that would entail.

Use the debugger. Your entity never uses a PanicGoal.

Look into how the game uses ItemRenderer. You can get the vanilla instance of it directly from the Minecraft instance.

I'm afraid you're using an unsupported version of Minecraft, it would be best to update to 1.14 or 1.15 in order to receive support. Read this for more info.

Look at CapeLayer

Use Java 8 for modding.

They're incompatible with virtually every other mod since they directly modify vanilla code and replace vanilla files. Given that this is the Forge forums, and that the idea of jar mods goes against the whole concept of Forge, it's a highly discouraged practice on here.

You're using an outdated version. Update to a modern version of Minecraft to receive support.

I suppose that's an ideal workaround, thanks for letting me know (and thanks @Cadiboo), I'll try something somewhat similar.

I'm aware that you have to initialize EntityTypes before spawn eggs in order for them to link up, then register the EntityTypes in their event. I like to do this with RegistryObjects to keep things consistent across my mod, but I know they're not designed for this use. There's no way to set the value inside of a RegistryObject without registering it first, which makes sense of course, so I'm sure trying to work around that would just be a hacky solution at best. Is there any way of still using RegistryObjects, and also having the spawn eggs point to the correct EntityType reference even if changes by the ObjectHolderRegistry? Maybe I could create dummy EntityTypes that get changed after registration, using custom spawn eggs? This probably isn't worth all the effort...

McJty's youtube tutorials aren't half bad, but they still use somewhat outdated concepts like sided proxies. Still a good starting point, in my opinion. In general, I recommend looking for resources no earlier than for 1.14, as that's when Forge did a massive rewrite of the entire system. Anything before that would be too outdated to be useful (or receive support on the forums).

It's in the parent class. It takes a good 10 seconds of searching to find, no offense.

Ah right, I guess I wasn't clear when I said "generating items", what I have should be fine then. Oh! Forgot about those, thanks for mentioning them. Guess I'll dive into that. I was worried that a bunch of JSON models would degrade performance, but I'll cross that bridge when I come to it.

Without dynamic generation or shared resources, I would have to manually write ~5-6 items and their resources just to add a single new variant, of which I intend to have over a dozen. The alternative to either of those would be to use single items with NBT, which is also usually discouraged. Honestly I don't like any of my options. This is a very old project that I'm trying to flatten. The items (used to) use a system akin to Forestry's honeycombs, with item metadata and potentially hundreds of variants. Writing some scripts to do some code/file generation might be a last resort, but things would be getting out of hand at that point.

This is a question I thought I figured out a while ago, but I guess not. I have 40+ items that get auto-generated and shoved into a map at runtime. I want all of these items to share the same model to save on load times and allow for easy expansion. This could be achieved in the past by using ModelLoader#setCustomModelResourceLocation, but that's obviously not an option anymore. What is the correct way of achieving this nowadays?