Draco18s

getMetaFromState/getStateFromMeta only handles the metadata encoded information (16 unique states) getActualState handles all the other states: TileEntity, World, etc.

Look at BlockWool, it has a color enum already. You'd want something just like it, only with fewer colors (or you can re-use it). Alternatively, I did my enums like this: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/blockproperties/Props.java#L17-L68 I created an interface to get/find metadata values, name, etc. My approach was simpler as it only required a single interface that I could apply to every enum rather than having an arbitrary approach involving a META_LOOKUP array. (Although it looks like my getByOrdinal(int) method is broken in that repo, and I currently don't have access to my dev; long story short, there's already a way to get an enum by ordinal and that method is just a wrapper, but is supplied by the interface: EnumWhatever.values[n] ).

Blockstate json files: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/resources/assets/harderores/blockstates/hardiron.json That block has an IProperty integer for its variants, but enum values work as well: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/resources/assets/harderores/blockstates/millstone.json#L27

Is your main mod class called SpearMod ?

Go look at what the super method does. Do what the super method does, only use your own Mod ID instead of "minecraft."

Ugh. Getting the super return, substringing it, and concatenating it.... It's almost like there'd be an easier way to do that.

Yeah, it's just superfluous code. It is technically a bug, but one that doesn't mean anything.

Go find MovingPositionedSound and then go find it's super class. Which is unsurprisingly called...PositionedSound.

It's a new system, but it's not that hard to understand and there are several tools out there (like McCrayfish Model Creator) that make things easier.

I apologize, I thought that json was poinging at one of the block models you created. Undo that, that's the item model. There might be a problem there as well, but I can't see it. That said, there's still the same problem: Your olportal_ew.json file (and the other one) has a "portal": texture definition, but the elements uses "#olportal" so these are not hooked up to each other.

Change "all": "chemmix:blocks/olportal" To "olportal": "chemmix:blocks/olportal"

"texture": "#olportal" "all": "chemmix:blocks/olportal" ...seriously? You defined a variable called "olportal" and then said "set the variable 'all' to [texture]"

Double click on a class to open it and look at the object hierarchy window.

A Minecraft modding tutorial wouldn't help you with the problems you have. You need to have a stronger understanding of OOP first.

Everything in the cpw package moved to net.minecraftforge. Rather than typing out imports, let your IDE do it for you. Remove all your import lines, then hover over each object one after the other and import the right thing (or hit ctrl-O). Also, do not do Main instance = new Main() , that "new Main()" portion is unnecessary and will be overwritten by Forge when it instantiates your mod.

If you want it to glow in the dark, you can do that with baked models.

There's two gradle commands. Did you run both?

"Skipped" means that the file needing to be downloaded is already current. It's not an issue.

AH HAHAHAHAHA This will never work. If someone is cheating, they can decompile your mod and make it report whatever the fuck they want. Only one thing is ever true about a client/server interaction: Assume the client is always lying.

You done gone fucked up. Start over by reinstalling Forge.

I think it needs to extend a Capability object/interface of some sort, but that would be a valid interface for the custom one, yes. You'd then need to implement it. I'm away from dev, so I can't check.

Do not strip that off! Unlocalized names are GLOBAL, if you add an item with the unlocalized name "item.thingy.name" (or I should say, that's what shows up when you go to put it into your localization file) and localize it to "Awesome Hat" and then another mod comes along and creates an item with an unlocalized name of "item.thingy.name" localized to "Neat Wand" guess what? Both items in-game will display with the same name, depending on which mod loads second. Instead, if both mods left their mod ID in the unlocalized name, this would not happen.

getRegistryName().toString() ResourceLocations aren't implicitly converted to strings.

ModelLoader does not exist on the dedicated server. Do you understand why the proxy system exists?

Shame it will still crash a dedicated server because it has client-side-only code in a common place.