Draco18s

Btw, your try...catch block can be simplified by using a multicatch. Try {...} catch(IllegalAccessException | IllegalArgumentException | InvocationTargetException e) { ... } I also don't like the "just copy this class" but for what you're doing (single keyword triggers with no subkeys (e.g. "saw_bird" not "saw_n_birds","count: 10") and how complicated and how similar ICriterion triggers are, I suppose it's fine. I would, however, point out the test() and trigger() portions of the code so that readers know what to look for when they want to do something more complicated.

...pass null...

There aren't "new variants"

item.setUnlocalizedName(item.getRegistryName()). Magic. There's nothing wrong with in-lining it, although I do agree about keeping things clean.

Please do not use@SuppressWarnings("deprecation") Deprecated means "do not call" not "do not override." It is safe to override these methods, however if you want to know whether or not a given block has these features, you should call IBlockState.<whatever> instead.

All "feeding" the animal does is call setInLove()

Post your block class.

Both of these are possible through the use of Container Items. Look at the milk bucket.

> Tomlabete: post code

Sure @LexManos, here's one. It's not recipes, its advancements, but still, it's something JSON cannot do currently (requires reflection hacking to register new ICriterionTriggers):

Your post made no sense. None.

You do know about getEntitiesWithinAABB(EntityItem.class, AABB) don't you?

Why the fuck are you comparing unlocalized name strings? Jesus christ, itemStackIn.getItem() == MainMod.SyringeEmpty You do know what ActionResult<ItemStack> means, yes? It means that the item stack that is a part of the ActionResult return is the item that gets put into the player's active inventory slot... As for your asked question, you're doing something really, seriously wrong. I need to see more code, probably your BasicItem class and both syringes in completion.

Do what crops do. Random update ticks.

You can create your own triggers: https://github.com/Draco18s/ReasonableRealism/tree/1.12.1/src/main/java/com/draco18s/hardlib/api/advancement You still need to register them: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/HardLib.java#L46 But it will take reflection: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/EasyRegistry.java#L210

Must only be removed recipes then (e.g. I removed 3 wheat for bread and replaced it with 3 flour for bread, wheat requiring to be milled into flour). Still a warning worth giving. Pretty much. Any object given a domain other than the domain being processed will log that warning. The substitution system has always done this.

1) Don't know, probably 2) Yes, but that just means it isn't shown in the recipe book unless game settings are changed to make unknown recipes uncraftable 3) Don't know 4) They should be convertible, even if you have to write custom conditions for them. I haven't really messed with it at all 5) Relevant, but if you remove / replace recipes you need to provide a new advancement to unlock them and the original advancement cannot be killed and will throw an error when it is deserialized. This error cannot be prevented, as it happens during the deserialization process.

See:

No. You have to live with it.

Ah, thanks for that @LexManos

Ok, so your wands need the values, which I'd even said: But the rest of your items don't. You also don't need to supply "ground" (etc.) overrides if they're the same, you can just omit them.

item/handheld

Read point #2: Use item/generated not builtin/generated. Look at this. LOOK AT IT. LOOK AT HOW GLORIOUSLY SIMPLE IT IS.

OH FOR FUCK'S SAKE DO NOT USE getUnlocalizedName() HERE. THIS IS WHY WE HAVE REGISTRY NAMES AND getRegistryName()! Not to mention that in 1.12, GameRegistry.register(...) is private (use the RegistryEvent.Register<Item> event) and GameRegistry.registerItem() has been removed as it was deprecated back in 1.10.2 in favor of GameRegistry.register(...)! Also, I see no point in using ObjectHolder for your own items. None what so ever. You're already creating them, just stuff them into the static field yourself. ObjectHolder exists to get other mod's items without needing some kind of API or using getValue().

Forge Energy requires that you do a lot of stuff yourself, but it is essentially the same as Redstone Flux (IIRC, FE was inspired by RF). TL;DR: switch to Forge Energy.