Draco18s

Mm, true. I don't use the function in survival though, so I tend not to think about it. Creative, its super extra useful.

+in creative

This isn't related to your problem...but OH GOD WHY. You're essentially telling Minecraft that your TileEntity will never be invalid. Yes, even if you break your block and place a chest there, your TE is still valid. Good job. Why is your base TE class implementing ITickable when your subclass does fuckall with it? Leave this off and let the subclass implement it (or not). By making all of your TEs ticking you consume system resources to do nothing. Good job. As for your problem. Use the debugger. Why is your IItemStackhandler getting created with 0 size? The debugger can answer this for you.

Just remember to group them by functionality. "This ore appears in the nether" isn't really important. If you've only got 12 ores across all dimensions, you can still squeeze that into one block + metadata.

If you want to use variants for your ore types you need to use a single block (BlockModOres) with a variant property, then distinguish your different ores by variant, including in the blockstate file. Here's the best example I have: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/flowers/block/BlockOreFlower1.java https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/api/blockproperties/flowers/EnumOreFlower1.java https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/resources/assets/oreflowers/blockstates/oreflowers1.json You'll have to pretend that some of the block properties (Props.FLOWER_STALK,Props.HAS_2D_ITEM) don't actually exist, as they're handled magically* elsewhere (and not relevant here). Additionally, the enum field for ore type is just a convenience mapping for my useage. A flat enum like you already have is fine. *I use a custom statemapper.

Go download JD-GUI. Have fun with it.

Well, there isn't an event that corresponds to "LivingEntityUseItemEvent_But_Left_Click" because items aren't used on entities on left click. That's an attack.

All of your ore blocks declare a variant which is not present in your blockstate.json

Do your blocks have variants? Because the issue is that the blockstate file doens't have the variant (or there's an issue with the data inside that variant). Post your block code for your copper ore.

The Fake World code is sprawling and in several files. If you're interested in knowing what I did, peruse my repository. Everything you need is there. I recommend starting here: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/industry/entities/TileEntityFilter.java#L169 Follow the references. If you have specific questions, ask.

https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/industry/world/FakeWorld.java

I did this for a tile entity of mine. It's a massive headache. The way I went around doing it was to register a dimension, use that dimension as the place to "store" the block/TE information that I wanted. I mapped the six slots in my TE to six locations in the extra dimension (while possible to have two TEs use the same locations, it's not a concern, as the TE checks the BlockPos and if it isn't correct, changes it--there would be GC overhead involved, but the likelyhood that a player does this is small). The chunks in that dimension are chunkloaded while my TE has need of them (any given TE will chunkload at most 1 chunk). And of course, in order to get the world reference, I had to pass things through my Proxy class because the client and server worlds are different. This was less of a hassle than creating a World object that wasn't connected to anything at all (also possible).

This won't work. ItemStacks do not override Equals (or the == operator). You need to check Item bitem = Item.getFromBlock(block); if(entry.getKey().getIem() == bitem) { }

Don't override isOpaqueCube, getBlockLayer, or shouldSideBeRendered. Don't forget to call super() in your constructor.

#PostYourCode

Post the error you get in the log. The whole thing. If you feel like it you can read them too and find a "Caused By" that actually tells you something.

function int getRadius(int distance_from_top_of_tree) { return distance_from_top_of_tree; }

Sounds like your f(n) is equal to n, you probably want n/2

That's what f(d) does. It computes the radius based on the distance from the top of the tree. Presumably f(0) is 0, and f(n+1) is greater than or equal to f(n).

More like "Eh, I'm already not doing professional Java work, I'm now more incentivized not to." I'm sure it works Fine, but it's not "what I do" so I don't see a reason to make it "what I do." I like modding Minecraft because there's a million billion things I don't have to worry about and I can make cool stuff.

/me adds it to the "list of things to stay away from," keeping NPM company. Also http://www.stilldrinking.org/programming-sucks

Calculate the distance of the current leaf position from the top. Perform some math, r = f(d)

THAT is a definition I can work with. I'll probably still refer to the value in object.value as a field or property interchangeably, though, as it comes down to an implementation detail inside the class that isn't relevant when talking about "that thing that is named 'value' and is part of the definition of the thing named 'object' " How often does this come up when not dealing with ASM or [thing I don't have a word for, that is what Forge does, patching? (de)obfuscation?]? It's a question that I cannot even attempt to analyze because the only Java work I've ever done has been for Minecraft via Forge. That is, outside of Forge and Forge-like software, how often is binary compatibility an issue?

Its not that difficult to do, if you open the JAR file as a zip and find the MANIFEST.MF file (inside the META-INF folder) and open it in a text editor, if it has the FMLCorePlugin value set, then it's a coremod (more accurately: if it is not set, it cannot be a coremod, if it is, you would have to examine the indicated class in JD-GUI to look for the annotations* that declare the class for being loaded for the class transformation events--ie. coremodding--but the only reason that it would be set would be if the developer went out of their way to set it because they need to perform those operations). *Deliberately vague.

This is mostly a question directed at @diesieben07. One of these days I'll figure out why a Field and a Property aren't the same thing. I certainly recognize the difference between these as a declaration: public float value1; public float value2 { get; set; } The problem is that from outside the class (i.e. seeing only someObject.value1 and someObject.value2, both of which can be read and written), they behave / appear to behave the same way (ignoring the fact that value2 can be made read-only or write-only). In trying to look up the difference, I got these three descriptions (thanks Stack Overflow): (Eesh, how vague.) Which...doesn't help (underscoring added for emphasis). The only seeming distinction is the fields are (usually?) protected* and properties are (always?) public. Wait, if fields are protected, why mention that "unless specified, they aren't static"? Is a static field still protected!? *protected here meaning to refer to either protected or private.