Draco18s

Ah, cool. I'll try and remember that. I'm done doing my manipulation, and everything works the way I want, but there was a lot of poking around in the dark.

Well, there's two problems, still: 1) ItemStacks don't work as keys properly (do not override equals or hashcode) so you'd have to iterate over the map manually (furnace recipes does this) or you can create a wrapper class (like I did for blocks; BlockWrapper , as I needed more information than ever a IBlockState would hold, specifically a wildcard value) 2) Array is the wrong type. You want List<ItemStack> but that doesn't handle your random chance values. You'll want another wrapper, storing the probability and the item.

You'll want a custom class that holds your outputs and their probabilities, and you just need to store that in a HashMap<ItemStack,Outputs> I do something like that here: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/flowers/FlowerDataHandler.java#L34 Tuple is just a generic class that wraps around two or more datatypes as a relationship. I probably should use a custom class for it, but I was thinking more in terms of the map from blocks -> flowers

The other thing that I had trouble with, was being able to see the JSON equivalent of what I was doing. That is, I couldn't figure out how to write my changes to a file. I'm sure there's a way, I just couldn't figure out how.

They're super easy. http://mcforge.readthedocs.io/en/latest/networking/

That is "save to disk" not "send packets" it's right there in the name. "Packets."

Not pass it a null item.

Good odds that your ModBlocks.CRATE object is null at the time you create the recipe, so the item it's trying to render is null and it crashes.

So I shoved a test event handler for this event into my project (because seriously, it shouldn't be that hard) and.... Nothing. The Forge event bus does not see my handler so my code is never executed. I can't figure out why. This is irrelevant. If the getter returns a copy, then doing this makes no difference. If it doesn't, then this makes no difference. It's not a "new instance" when you store a reference in a variable.

By the way, you've misspelled "weight"

Let's look at what Config.getFloat does Float.parseFloat(prop.getString()) < minValue ? minValue : (Float.parseFloat(prop.getString()) > maxValue ? maxValue : Float.parseFloat(prop.getString())); Oh, hey, its just parsing a string.

And how would you do that differently? Use an number-based ID? I don't have an alternative. I don't know. But I can still not like it.

Show your code.

That...sounds excessive.

(Imports aren't actually compiled in, they're syntatic sugar. Using fully qualified names instead won't fix the problem, whereas importing a class that isn't used, won't)

The config class does it for you. Same thing with all the config options. If they aren't there, you provide a default value.

From existing loot tables. Ok. Subscribe to the LootTableLoadEvent. And then do magic. And by magic, I mean I figured most of this out by trial and error and a single existing post on the forums. https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/farming/FarmingEventHandler.java#L285 with references to https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/util/LootUtils.java If anyone else has any advice on how to do this better, I'm all ears. My biggest complaint/issue with the loot table system is that in order to detect a given loot table, I need to compare strings.

It works like this: Rather than getting a value from the config file, get a Property. The property then contains both get and set methods.

Again, you can totally do that, and the code I linked does something similar.

What are you trying to do? Create your own loot table, or modify an existing loot table?

Yes, that is correct. (player's guide to using it: http://reasonable-realism.wikia.com/wiki/Filtering_Hopper ) I could pass a non-null world, but it wouldn't make a difference as the TE's author would (reasonably) assume that the block-at-the-TE's-position was its own block. I know my own code says "hold on, this isn't me" and allows full access to all slots, same as if a null side was passed (to handle cases like blocks being set to air before the block has a chance to drop all the TE's contents--because that was a problem at one point) but that may not be universally true (as I think aforementioned issue was fixed). The other reason my millstone block does that is that it needs to do that before requesting properties from the blockstate, as to not cause an InvalidPropertyException (or whatever it actually throws when you try to get/set a property that doesn't exist). I suppose that I could use two different TEs for my millstone block (one for the edges that accepts items and one for the center that processes and allows extraction) but I originally coded it to just be the same TE and use the Sided interface nature of things to make the distinction. But again, the point is, "if I managed to do this in this way, someone else might do it too." And it wasn't until I was coding my filter block that I realized that my getCapability method was insufficiently built to handle possible problems (took me three attempts to properly make sure that what I was doing would work).

And your goal is...? (Also, you're not entirely correct)

new Configuration(event.getSuggestedConfigFile())

Yes. Which I am. That is also not the problem. The problem is not the TE creation but invoking getCapability as I've said three times now. getCapability DOES NOT PASS A STATE

Sorry, it's Block.REGISTRY