Draco18s

Yellow is RED + GREEN. https://en.wikipedia.org/wiki/Additive_color

Funnily enough, I was actually contacted about working on the XBox version of Minecraft. If it weren't for the fact that my C++ skills are virtually non-existent I'd have taken it.

Oh. I know why him removing ITileEntityProvider "erases his data." He doesn't have @Override marked and/or isn't dealing with the IDE error involved when he removes the interface. So he's not overriding the correct method, so when the game runs it treats the block as not having a TE.

We posted at the same time. Anyway. The annoying thing I find about IItemProperties is that you will end up with a bunch of model json files (I much prefer blockstate files in this regard). I haven't found a way to just "give it a different texture" as the base model file (e.g. this one* in my own mod), the format is such that it expects a "model" tag, not a "texture" tag. I tried just supplying a new texture and it threw a Missing Model at me for my efforts. I think it has to do with the fact that an item model is still made out of baked quads, so in order to "change texture" you're actually just displaying a different model (which was run-time generated from a pre-specified texture in that model file). *The "time" string should be changed, but as I was working from the vanilla Clock as a starting point I haven't changed it yet, it's just the name of the property that was created. In this case it should be "rainfall" as it is arbitrary, but needs to match.

As I've found it large comes down to "if it's been a few days, post a comment asking why it's not been accepted." The entire process is ungodly tedious with several points of failure that it is very easy as a programmer to overlook and which Lex will come along and go "You did X wrong" and then proceed to mark every occurrence with "..." as if you're somehow only barely intelligent. The "how to do this properly" list of guidelines is very sparse and doesn't teach you how to look at the patch file and find these problems on your own. Took at least four rounds of review before I fully understood how I was supposed to be doing things. Or in one case for me, "rejected because it alters vanilla behavior" which I thought was the whole point (as opposed to "rejected because you should have gone about it in by doing X instead of Y").

BreakSpeed seems like the one to use to me. But again, what are you trying to achieve, not how you plan to code it, but what you want to happen from the player's point of view as he's playing the game. e.g. Goal: "If the player tries to mine coal with an iron pick, it starts a fire in a random nearby tile." Code: "I want an event that lets me check the player's held item so that..."

Skipping over the "where to start" because don't. You will not find Forge-specific details on starting to coremod. There used to be slight hint here and there, but the Forge team is working to make it so that coremodding is not needed at all. Instead, make a pull request to get the change you want implemented into Forge itself. I recently did that myself. On to the other question, alternatives: Block/Item substitution OreDictionary ("requiring pistons in recipes") or outright modifying the list of recipes to find entries that don't use oredict recipes. Events - almost everything you'd want to be able to do as a result of coremodding has an event. If it doesn't: Make a pull request

You may have to combine models as well, which is doable,

Your TE's constructor must take 0 parameters or it will be unable to be recreated when the game is loaded from disk.

world.getTileEntity for one.... You were told already how to do the other...

It's a method you haven't overriden, therefor it exists in one of your class's parent classes.

Entities have a UUID field. Get it. Save it into a field of your TE.

Yes, that change would indeed make it spin faster. Because math.

Also, don't create your own PropertyDirection, use the one from BlockDirectional

Also, why this? for (Field f : Items.class.getDeclaredFields()) One shouldn't have to use reflection to register blocks/items/models IMO

Actually, that was Dropbox. http://superuser.com/a/1131164/528962

In your IDE you can look for classes that extend the Event class from forge. Right Click -> Open Type Hierarchy

Oh sorry, you were right the first time. I didn't realize the event was declared as a static class inside the OreDict. What's your problem?

public void OreRegisterEvent(OreRegisterEvent e) { }

https://mcforge.readthedocs.io/en/latest/events/intro/

Subscribe to it, do whatever you want to.

OreRegisterEvent

https://github.com/Draco18s/HarderStuff/blob/master/src/main/java/com/draco18s/ores/entities/TileEntitySifter.java#L263-L293

You mean the ItemStack "damage value", right? In that case: [0, Short.MAX_VALUE] . A short would have a maximum value of 32,767 yes. Which is 'approximately the same value' as I said. Also, it's 1 less because I believe the exact value of 32,767 is used as the WILDCARD_VALUE

Cannot set property PropertyEnum{name=half, clazz=class net.minecraft.block.BlockSlab$EnumBlockHalf, values=[top, bottom]} as it does not exist in BlockStateContainer{block=spaceextended:double_vitallium_slab, properties=[variant]} Your block's variant statecontainer object does not contain the states you are trying to use.