Abastro

minecraft version should be provided for these kind of question, because rendering system changed a lot in 1.8

If you had read my post more carefully, you'd see I already override isOpaqueCube, and isCollidable, per the Java-doc, is 'only used by Fire'. I do override canCollideCheck based on state, but my problem is not being able to walk through the block or not, it is getting the block not to render at all when it is ethereal. As it is, it always renders like it is a solid block, even when it should be invisible. The ISmart/IFlexible block model interfaces do not allow for cancelling the rendering altogether, which is what I need it to do. Maybe if I try it in the cut-out layer... As getRenderType(IBlockState state) does not exist, you should make your own model invisible for the invisibility state. So what was the problem with ISmartBlockModel?

I think the TGG's example: https://github.com/TheGreyGhost/MinecraftByExample/blob/master/src/main/java/minecraftbyexample/mbe15_item_smartitemmodel/ChessboardSmartItemModel.java#L61 would be fine to use for the case. It seems that you can just simply use that with your own textures.

Learn Java and how minecraft works. Please. The lightning has to be somewhere so the coordinates are necessary.

Are you doing that on dev environment?

As the 'Gui class' has client-only contents, it should be constructed and registered in the proxy. Tutorial on proxy: http://www.minecraftforge.net/wiki/Basic_Modding

Ernio already told you how to do that..

First, you should make the entity save and load the UUID of the owner.

Wait, I think you missed point, 'this' cannot be null in any time. GC only collects the died entity only when it is not running any code.

Oh, I didn't know that can throw NPE while ticking entity.;

That is just a tag on the Crash when mc crashed while updating(ticking) an entity.

As in, the line it is pointing to in the crash report? this.worldObj.createExplosion(this, mop.getBlockPos().getX(), mop.getBlockPos().getY(), mop.getBlockPos().getZ(), 1.5F, true); So only two possibilities are: worldObj is null(impossible), or mop.getBlockPos() is null(also impossible) Yeah, that is why I was stumped, too. Perhaps it will help figure it out that the following file for 1.7.10 worked. https://bitbucket.org/The_Fireplace/devons-random-things/src/f24522e68bb28fd2b065836a9f564eaf30e9dbc1/src/main/java/the_fireplace/devonmod/entities/EntityChargedCoal.java?at=master Then.. Try debugging to find exactly what is null.

As in, the line it is pointing to in the crash report? this.worldObj.createExplosion(this, mop.getBlockPos().getX(), mop.getBlockPos().getY(), mop.getBlockPos().getZ(), 1.5F, true); So only two possibilities are: worldObj is null(impossible), or mop.getBlockPos() is null(also impossible)

Exactly what line the NPE got out?

Oh I didn't know doing it on PlayerLoggedInEvent would be more efficient. (I assumed that his entity is extremely rare, and I realized that it wouldn't now)

Yes, if it is the name of the armor material.

That is not good.. Changing static field is really bad. You should just have many models in the renderer, and gets the model you need using the age of the entity.

You should be able to store the nickname field, so I assume that you don't know how to reset the nickname when the player logs in. .. and I just realized doing that in Entity#onUpdate will be better. In the onUpdate, check if the player with the saved UUID exists in the world, and set the name field with the player's nickname.

It seems to be just named wrong. It just represents the name of the armor.

So the print statement prints, but it does not spawns any particles? There is nothing wrong in spawning code. Check the value of worldObj.isRemote, it might always be false, which means that it is server side. And you cannot spawn any particles on server side.

That was what I had been telling you... You should store the 'owner nickname' field with the UUID. You should also put that into the DataWatcher. Also when the player logs in, you should reset the nickname from the player, since the nickname can be changed.

No, do not sync THAT field. I said: make field representing 'nickname of the owner'. and sync the field(nickname) when the owner logs in!

No, make your own field representing the nickname of the owner. And sync the field when the owner(player with UUID) logs in.

Ah I see. then make independent getter/setter method or field for the nickname of the owner. Also you should sync the nickname field when the owner(player with UUID) logs in.

You should also save the owner's UUID too, because his/her nickname can be changed. also the owner instance can be null. So do not call it as getOwner().getName(), instead make independent getter/setter method or field for the nickname of owner. Also you should sync the nickname field when the owner(player with UUID) logs in.