Draco18s

Go complain to Lex, then. Fair warning: he hates whining noobs.

...wouldn't you only want to spawn the drops when the TE gets removed?

That's not what its for. What happens if you use 3 vanilla cobble and 3 modded cobble? Nothing. The tag makes it so that it has a result.

Go look at the Container for the Anvil?

I don't know, maybe if mods add their own forms of cobblestone and want it to work with the vanilla recipe along side regular cobblestone? That is what tags are for, afterall...

Yes. Ever since tags replaced the OreDict Forge has supplied tag recipes instead of OreDict recipes. Its supplied OreDict recipes since basically forever. "are" the word you're looking for is "are" They're not unnecessary. This sounds like a bug with Forge. Forge should load its recipes first, then mods have their recipes loaded after. Presuming, of course, that you are placing your recipes in the correct place.

It might be valid JSON, but this is not a valid recipe ingredient: "X": [ { "item": "minecraft:planks", "data": 0 }, { "item": "minecraft:planks", "data": 1 }, { "item": "minecraft:planks", "data": 2 }, { "item": "minecraft:planks", "data": 3 }, { "item": "minecraft:planks", "data": 4 }, { "item": "minecraft:planks", "data": 5 } ] 1) metadata doesn't exist any more 2) you have specified an array of 6 items instead of a single object

That's what I needed. I hadn't looked at it in a while and I've become more comfortable with Supplies and Consumers lately and I just hadn't gone back to see if I could figure it out again. I knew it was better than what I was doing, but that I'd gotten stuck and went with what I knew. Thanks.

Oh I know. Its more that it's irksome that having to do orElse(null) and having check for null. (I'm not sure what the difference between orElse and orElseGet is, and should probably use orElseThrow, but I'm a little confused by what to pass in).

I don't remember exactly. Use this: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/util/LootUtils.java It already handles 99% of use cases with intelligently named parameters and will offer sensible alternatives when you just need to do something simple (such as not needing an ILootCondition or ILootFunction). If you have more specific questions, just ask. There's some examples of usage in my code (mostly in Harder Farming's EventHandler class).

1) Don't create LazyOptionals in getCap, violates the whole point and doesn't allow you to mark the LazyOptional as invalid when its no longer needed. This is an easy mistake to make and if you do it, Lex will find you and come murder you in your sleep. 2) All it is is a wrapper around your capability instance (which may or may not necessarily exist yet) and when your cap does exist, the LazyOptional will automatically get updated from holding null to holding your cap instance (because its actually providing a pointer to your cap field, rather than pointing at what your cap field contained when the LazyOptional was created). Annoyingly, I've found situations where this isn't possible. https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/industry/entity/AbstractHopper.java#L118-L121 There's no way to return the boolean required for the hopper updateHopper's Supplier parameter from inside the ifPresent lambda. Trust me, I tried.

Mystcraft would do this when non-player entities were teleported to Myst dimensions via a portal. It really isn't that intensive.

?

You can't CHANGE them. That means no adding, no removing.

Literally knowing fuckall about where to look, let me see... oh hey, there's a net.minecraft.entity.merchant package. I wonder what's in here.

Probably. Have you tried looking at the code that handles it?

What if: The entity gets unloaded The player teleports it to them (it gets cloned) The new one gets unloaded The player goes to the chunk where the old one (from (1) is)?

You know that BlockCrops already implements IPlantable, right? You know that you don't have to use ValueOf on integer literals, right? Why do you have this in your constructor twice? And you called super()...where, exactly? getValue already returned an int, that you cast to an Integer, that you then called intValue on... 1) You don't need both of these 2) The second one is doubly-useless because those static references are still null because they aren't populated until AFTER the event Ditto... Well, that was fucking pointless.

Another idea is to place everything, then place everything again, and clean up dropped items. This does require storing the blockstates in a separate (non-world) array though. Its not great and I've played around with this a little (I've teleported sections of terrain around in the same dimension). It's really really hard to determine whether or not a block requires a solid surface.

I haven't yet worked out the systems necessary to convert my machines recipes over to a JSON system, but as largely speaking they tightly controlled values (eg. 1 raw ore chunk grinds to 2 tiny dust of the same metal type, 8 tiny dust combine to 1 large dust pile) I'm not overly concerned with exposing them via data packs. I do, however, want to insure mod compatibility and have set up the necessary structures to handle tag-based inputs. It seems, however, that I can't examine what stacks exist in a given tag until after a world loads, which has led to this: private static Map<Tuple<Supplier<Tag<Item>>, Integer>, ItemStack> siftTagRecipes = Maps.<Tuple<Supplier<Tag<Item>>, Integer>, ItemStack>newHashMap(); which is storing the parameters passed thusly: addSiftRecipe(() -> ItemTags.getCollection().getOrCreate(new ResourceLocation("forge","dusts/tiny/iron")), 8, new ItemStack(ModItems.largedust_iron,1)); I can't imagine that this is the best way of doing this. I'll even admit that a Map isn't the best choice either, but it was what was being used by the vanilla recipe manager, but an ArrayList<Tuple<Tuple<Supplier<Tag<Item>>, Integer>, ItemStack>> is equivalent for the purpose and still suffers the same problem: How best to store a reference to a Tag when the point in time that I create the reference the tag contains no items. As far as I can tell, I need all of those wrappers. In a related conversation, there does not seem to be any standard for tags that are the equivalent to the old OreDict conventions (e.g. dustTinyThing->dusts/tiny/thing and so forth). I have made a best-guess and can only hope that other developers make the same logical conclusion that I did. I would appreciate if a similar set of guidelines to the old OreDict Common Names were created for the new tag system (as, as far as I can tell, if you specify a different namespace, the tags are unique; e.g. "forge:dusts/tiny/iron" is not the same as "mcmod:dusts/tiny/iron").

Provided of course that you are modding on a version of Minecraft that supports JSON recipe files. If you are not, you won't get help here because the version is over 5 years old and no longer supported.

Those are the names of two methods in the Item class. They are used by the BucketItem class to leave an empty bucket in the crafting grid when it originally contained a fluid (eg. milk). You can look at the bucket class for an example, but what's important is: 1) you override those methods 2) you do something to achieve your desired results, the stack passed in is what started there and the stack returned is the stack that stays in the grid when you retrieve the crafted result.

...and this is why you use an IDE plugin that can find JSON errors for you.

I see two "key"s

What do you mean?