Draco18s

What do you expect to get passed to ModelResourceLocation if id is solar:rune ?

The only reason people are likely not currently seeing the issue is because ModelLoader itself is not marked as Client-side (and doesn't get loaded, only validated to exist) which might change. Also, you might be interested in how I set things up. https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/EasyRegistry.java Those being effectively proxy classes, but with some static methods to allow child mods to use it.

JVM: Loading class MSBlocks. Hmm, it has a reference to ModelLoader in it, must make sure I can fetch that class when that method gets called Server has crashed: ClassNotFoundException It's not about whether or not it gets called, the fact that it exists is the problem: the JVM can't validate the MSBlocks class as valid java code.

setRegistryName("matterstoragesystems:BlockOreCerium"); setRegistryName already prefixes your MOD ID you don't need to do it again. Also don't put your model registration code in a common location, it must be in the client proxy or it will crash the dedicated server: ModelLoader extends a client-side-only class.

*cough* ModelLoader.setCustomModelResourceLocation(item, meta, new ModelResourceLocation(Solar.MODID + ":" + id, "inventory")); Also, that shit will crash the dedicated server. ModelLoader extends a client-side-only class.

Caused by: java.io.FileNotFoundException: solar:models/item/solar:ItemRune.json You're prefixing your MOD ID onto the result of getRegistryName. Also, your registry name should be in all lower case.

Errors you say? Post 'em

Don't ever use getUnlocalizedName for something that isn't display purposes. As you can see, it's gone and fuckered your resource path. You should be using getRegistryName.

See. This is where your IDE can help you. Right-click -> References -> Workspace This will search for all usages and other references to the method in the entire workspace (or project if you click project, which is the same unless you have more than one project imported). The method is only called by the dragon and the wither. The default implementation in Block is pretty much the only one that matters (it checks a bunch of blocks if it's the dragon, if it's the wither, it calls back to a static function in the wither to determine). Most things return true. Obsidian, bedrock, barrier, etc. return false.

It doesn't need to do either of these things. I've been using standard block models for my TEs (the furnace does this). I've also got a couple of non-ticking TEs (the potted plant is a good example).

Aaaaaaaand you've already gone past the limit of 4 bits.

You can't save twelve PropertyInts in block metadata: Metadata can only store 4 bits of information.

Also update. If you really want to use 1.8, then update to 1.8.9

1.7 code, but the principle is the same. https://github.com/Draco18s/HarderStuff/blob/master/src/main/java/com/draco18s/wildlife/WildlifeEventHandler.java#L335-L349 You have to do it this way because you cannot compare item stacks with ==, you have to compare their contents.

Personally, I still think it helps to have the classes in different files. There was another poster about a week ago who'd used the nested class structure and was having an issue that as soon as I suggested he use separate files he found and fixed his problem.

The "particle" texture is unspecified/missing.

You also missed the bit where I said that you'd need to have an IContainerListener otherwise hoppers break things. You assumed that I was saying that hoppers make an IContainerListener insufficient.

You're trying to register the renderer for your item before you've created it. proxy.preInit(); <-- register rendering ModItems.init(); <-- create item ModItems.register();

No one is going to steal your shit: no one cares them. There's also this thing called "copyright" which everyone cares about.

It's so stupidly hilarious how easy this is to figure out I'll both link it to you and laugh. https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/ores/entities/TileEntitySifter.java#L151-L160 A hahahaha

Also don't implement IMessage and IMessageHandler in the same class file, you'll invariably mess something up.

Cough, change in stack size, cough.

One way or another. Lex has indicated it'll never get merged anyhow.

Hoppers pulling from or pushing to YOUR container would require an update while the player is looking at the GUI.

Say...hoppers?