Draco18s

Your enums have this method: @Override public String getName() { return null; } You cannot return null here. Actually, that line is unhelpful. It's just a "new MyBlock()" line. The important bit is this bit:

Thanks. I was darn sure that it cleared when I closed the search window, which is what I've done in the past (though I haven't even seen it highlight a whole bloody method, just the object name before).

What is the point of a private field with both methods to get the current value and modify the current value? That is, what is protected against that having the field public not protect against?

A couple things: 1) any item stored in a chest (or other non-entityliving inventory) will not tick and thus not rot. 2) any item in an unloaded chunk (or in a player that is not connected to the server's inventory) will not tick and thus not rot. 3) how do you plan to handle combining a stack of "damage:1" meat with "damage:10" meat?

What is this blue highlight and how do I get rid of it? It showed up when I did a search for existing usages of addPropertyOverride, opened up the ItemClock (it was faster than using the package explorer), and now it won't go away.

It was deprecated in favor of: AttachCapabilitiesEvent<Entity>

16.4 posts per day is not that many, especially for a moderator.

Unsurprisingly, -Xmx2G does too.

@Override public int hashCode() { return item.hashCode(); } This won't work. ItemStack does not provide a hashcode implementation, therefor this wrapper class violates the hashcode/equals contract: That if equals returns true on two instances, hashcode must also return the same value. You will need to provide your own hash implementation. I suggest something along these lines: @Override public int hashCode() { return 37*item.getItem.hashCode() + item.getItemMetadata(); } Or use a HashUtility function: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/math/HashUtils.java Also, again:

What happens if there are no pancakes?

Which ticks even if you're not wearing the armor. Talk about overkill. (do your armor tick in one of your armor items, like the boots)

Huh?

On the other hand, it means (potentially) being able to toss item stacks of Air into the world, stacking them in your inventory, or pulling them out of the crafting grid. You'd have to do more work to prevent this, than I imagine you'd save by handling null correctly.

The whole point of creating the wrapper was so you could do this: smeltmulti.get(stack);

That's super weird. Why would they change that?

The question is "why?" Nearly everything anyone would want to do can be done without ASM, the rest should be submitted as a pull request to Forge.

Coremods are heavily discouraged around here. Sooo....you are unlikely to get any help. That said: > a) what to do, to get the method names deobfuscated? > 1) asm patches are applied before deobfuscation You can't both of these. You're either waiting until after deobf, or you're not. You can't have both.

ItemStack newstack = stack.split(1);

You do know about stack splitting, yes?

So you know how FurnaceRecpies has a method called getSmeltingResult? You need to do that for your own recipes.

Its only still there for compatibility on things that haven't been updated to the new style yet. The method you're using takes in a metadata value, not a blockstate, thus is out of date.

1) Does your ItemWrapper properly compare item stacks in equals and generate a hashcode? 2) Does your furnace try to pull a result from your hashmap?

I'd use the armor item's onArmorTick method. That way you're not having to check the player's inventory all the time, even when they're not wearing armor.

Pretty much. e.g. List<OutputWrapper> list = new ArrayList<OutputWrapper>(); list.add(new OutputWrapper(1, Items.APPLE)); //apple because why not list.add(new OutputWrapper(0.2, Items.GOLD_NUGGET)); //arbitrary this.addSmeltingMulti(Items.BONE, list); That would mean that when you smelted a bone, you'd always get an apple and 20% of the time you'd get a gold nugget. You'd probably want to limit your secondaries to a maximum of your total output slots (e.g. if you have 3 output slots, have no more than 3 output items per input item). This is assuming that your random is based on floats. If you do integers, you may have to refactor to match your desired design goal (e.g. if you always roll rand.nextInt(100) then you pass in "20" as your 20%).

You don't need the Tuple. You want something like this: private Map<ItemWrapper, List<OutputWrapper>> smeltmulti = new HashMap(); Then this: public class OutputWrapper{ public final float chance; public final ItemStack item; public OutputWrapper(float c, ItemStack i) { chance = c; item = i; } }