Draco18s

Nevermind, I get it. I was missing something that hadn't been spelled out well. When I went looking at the Explosion particle class, there it was. public int getFXLayer() { return 3; }

Then don't use addSubstitutionAlias

Possibly look at the class for a method related to setting the registry name...

You override the read/write methods and make them save the fields to NBT and read them back again. You don't invoke these methods, you implement them.

Ah, you let the Particle class handle rendering. Yeah, I need to set GL flags so that my particle renders on top of all other world objects (think vanilla's Glow effect for those new arrows). Managing to make some progress on my own, extending ParticleExplosionLarge rather than Particle solved the inability to use the world renderer. No idea why, as it doesn't do anything special, except that if I use its renderer and extend Particle things don't work.

almost makes me think we need to rename those methods to readFromNBTModdersDoNotCallManually and writeToNBTModdersDoNotCallManually

motionY on the player needs to be applied on the client, because of how vanilla handles player input

World#DestroyBlock bypasses all the code that is specific to the player harvesting blocks. If you want to harvest blocks you need to call the code responsible for harvesting blocks. If you want Silk Touch to work, then use your IDE to figure out where the code already references Silk Touch.

FFS You don't have an inventory variant.

First, don't make a thread about two unrelated topics. Second, you can't. You must use more than one block.

Got a github? The last time I did particles was 1.7 Edit/Update: Basically what I'm trying to do is recreate an effect I did several years ago: https://github.com/Draco18s/Artifacts/blob/master/main/java/com/draco18s/artifacts/client/RadarParticle.java The particle spawns at a block location, but renders over everything (due to using GL11.glDepthFunc(GL11.GL_ALWAYS); ). The problem I'm having now is that it doesn't seem to matter what I do with the VertexBuffer, I either crash the game because it's already drawing (ParticleLargeExplosion doesn't have this problem, I can't figure out why) or I get an Index Out of Range error when setting the first vertex position.

Anyone tried this yet? Looks like vanilla's particles are all registered with a particle registry ( ParticleManager and associated EnumParticleTypes ), but I don't see any Forge hooks to register custom particles. On top of that, the last time I played with particles, using a custom sprite (animated or otherwise) required binding a texture sheet and making sure that afterwards, you rebound vanilla's or things would break (vanilla particles would now be using the new texture sheet).

You do not modify Minecraft vanilla code. Do not do it. That is the wrong way to do anything. Doing so is not Forge modding and may in fact not be compatible with any other mod.

Also pretty sure you could have searched the item class for other things besides "addInformation" like "information" or "tooltip" or even just "List<String>" because you know one of the types of the parameters.

diesieben07 told you to use rayTrace from the Item. You said ItemStack doesn't have that method. Item and ItemStack are not the same thing.

Item.class != ItemStack.class

Do the first method. Looking up the SRG name isn't that hard.

Alpha values of...if I recall correctly, 0.12 and below are all treated as 0.

What is likely occurring is that mobs in not-nearby but still loaded chunks have their AI turned off. You can issue commands all day long, but they'll never do anything.

Generally speaking: Packets. The real question is: Why are you creating an object to store player variables? Use Capabilities.

ModelLoader must be called during PreInit not Init.

so do this only you'll have to move it to the right value on the X axis. Looks like it would sit at (1,0,0) to be correct? Just a guess.

Are you trying to create a NEW block that acts like a skull or are you trying to REPLACE the skull block class with a new one?

If the method is not directly invoked anywhere (i.e. an event) you can get away with a throws declaration (otherwise you'll be passing the throws up the chain of execution). Be aware that if you have an unhandled throws and it does throw the exception, the game will hard-crash instantly. Buuuut, try-catch is slower. By the way, you'll want to get the field once and store it and only have the throws on the actual set call (getting and setaccessible-ing you'll do once-ever and wrap in a try-catch).