Draco18s

You access scoreboard information through the scoreboard. It's got some private values, but reflection fixes that.

Where do you call RenderShuriken.registerRender()?

Why are you using both the ModelLoader and the ModelMesher? I told you to replace the one with the other.

BTW: String.valueOf(targetField.get(object).toString()).toString() How many times do you really need to convert to a string?

The second one works. The first one is an old, out dated, unreliable method that has been deprecated in favor of the latter.

This isn't realted to your problem but, public EntityBullet(World worldIn, EntityLivingBase shooter, float size, double speed, float damage) { this.damage = ItemGun.damage; Why the hell do you pass the damage to the constructor and then get the damage from the item? public static float damage; public ItemGun(float damage, float spread, double speed) { ItemGun.damage = damage; Second, why the hell is the variable static? As soon as you try to create two guns with different damage values, the second one will overwrite the first. Now: protected void onHit(RayTraceResult raytraceResultIn) This method is protected meaning that it can't be called by any class outside of this class (and any subclasses). You are not calling this method meaning that it is never called. What did you expect to happen?

Other mods? No. Other items in the same mod? Yes.

That would strip other, nearby trees of their leaves, leaving bare logs. Because it's soooo unique... Seriously, *I* wrote a tree-killing algorithm three years ago. And I wasn't even the first. TerrafirmaCraft and RotaryCraft both did it before I did.

Yes, using the right field name definitely does. But having the wrong one throws a NoSuchFieldException which is what the OP was getting.

Notice how I can literally not tell what class a field belongs to in the CSV: Yes, I know there's an IRC interface that makes things non-ambiguous, but that's rather a bit cumbersome.

No. Also stop using xyz and use BlockPos natively. Also don't use Block objects except when absolutely necessary.

Odds are you have the wrong SRG name (not vanilla name, btw, the vanilla name would be something like aaa1). Looking at the MCPBot exports there are two fields with the MCP name "footer." You're using the first one. The other one has the SRG name "field_179702_b"

There isn't. </thread>

Like I get any other block. world.getBlock(pos) only with an offset in a direction. world.getBlock(pos.offset(facing)) #Seriously? #NotThatHard

Well, rather, your modID isn't set. You may have given your code a package name, but your mod ID is still "tutorial."

READ your error. Caused by: java.io.FileNotFoundException: tutorial:models/item/tutorial_item.json

What are you trying to attach a capability to? You can't install a mod while the game is running which means that the event should work just fine.

That's because you're using ItemBlock. The base ItemBlock class doesn't give a shit about metadata. You want ItemMultiTexture or create your own (look at ItemCloth as an example).

Simplified example is simplified for ease of comprehension.

Basically this: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java#L45-L54 You need to know all the valid states the block can be in (as an item) and then register an item variant model for it: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java#L161-L168 Be aware that that class is effectively a ClientProxy class and I did stuff the way I did so that I had main class syntax similar to 1.7's GameRegistry.RegisterBlock(...) (And it was written before the registry events were added) The important bits are to determine the variant string for the blockstate variant and register an item model (the usual way) with that string.

And after your item and block creation. I.e. last. Also, if it crashes post the fucking crash log and the code that actually crashes.

Actually, no. Particles are one of the things you can't quite figure out by looking at Vanilla code. Spawning them, yes. Actually having your custom particle class render correctly and not fucking things up, no. You have to bind your texture, do some GL settings (resetting them later) and doing some translations (and popping them off later). Basically everything I do here: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/ores/client/ProspectorParticle.java#L55-L61 and here: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/ores/client/ProspectorParticle.java#L96-L98 Even the inbetween lines (62-95) aren't a direct copy of the vanilla code.

Block#onAddedToWorld is called during chunkgen.

For example: Imagine both player use the spell that holds the reference to the other. These two EntityPlayer objects now have hard references to each other. Both players then log out. The garbage collector comes along and sees that EntityPlayerA holds a reference to EntityPlayerB and EntityPlayerB holds a reference to EntityPlayerA. Both objects still reference the other and therefor cannot be GC'd without potentially breaking something, so GC leaves them alone. GC has no way to determine that this is a closed and isolated loop due to the space-time complexity of making that determination. See: https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Reference_counting Both players log back on again and repeat the process. Every time they do, it allocates two new EntityPlayer objects that can never be GC'd.