Leaderboard

@Legenes, @diesieben07 If it's ok to you, I'll mention you in my changelog false block is an air block that gets invisible when the lens of truth is hold

@LegenesYour code actually solved the Problem! Thanks to everyone.

While I respect diesieben07's objection to the common proxy approach, even the actual javadocs written by cpw for the proxy system suggest using a common proxy. So it is understandable that a lot of people have used it that way, and mostly It does works except logically you don't need code that runs on both sides to be in a proxy at all. So the term "common proxy" hurts our brains and I agree it probably further causes unnecessary confusion about the whole concept. So the more modern recommendation is to have all the common stuff just run directly in your main mod class (or wherever you handle the FML loading events like pre-init and such) and then only call the proxy methods for things that actually differ between client and server. For those, you create an interface (e.g. IProxy) and a client and server class that implement that interface each with their own version of the method.

You need to have the normal and inventory variant, even if you don't use them... And I don't think that the model's textures works that way... because you should set the texture in the blockstate. Yeah, the "cube_all" uses a "layer0" named texture, in vanilla, and a normal "all" texture in forge, so here's the correct one: { "forge_marker": 1, "defaults": { "textures": { "all": "whatever:blocks/yourblock_def" } }, "variants": { "visible=true": { "model": "cube_all", "textures": { "all": "whatever:blocks/yourblock_true" } }, "visible=false": { "model": "cube_all", "textures": { "all": "whatever:blocks/yourblock_false" } } } }

Metadata is limited to 16. Also metadata is an implementation detail. Use IBlockState properties.

Well if you want a damaged anvil to look like an undamaged anvil (but is still damaged) I would not like that as a player: I would never know when my anvil might just poof out of existence. If you want to change the anvil back to a less-damaged state, just change its state. (Other properties: sure, these exist, but none of them are "different" for the different stages of anvils, this is why I asked).

Correct, changing the cluster-size will change how much is in a vein and changing the cluster-count will change how many clusters in a chunk.

I recommend the line after "populate" {

Yours doesn't have an aluminum part in it, this is what the aluminum part I have looks like.

If you use the EntityJoinWorldEvent to remove the EntityFallingBlock when it is an anvil and replace it with your own entity that does the same thing, but modifies the chance for breaking.

No. That is hardcoded at EntityFallingBlock#fall and there are currently no forge hooks into it as far as I can tell.

You can use AnvilRepairEvent to control the chance of the anvil damaging when it is used to repair/combine items.

Just noticed myself but com is not a jar file