Draco18s

When the GUI first opens you should be able to get the reference from the player's held item (that is what opened the GUI...) and save that reference. That said, good fucking luck making sure what you just described works.

Loader.isModLoaded ("MOD_ID") Should be what you should do. If that's true, do stuff.

The NBT classes are just a unified way for Minecraft objects to serialize data. Serialized means that it can be written to disk. You can store all of the simple data types (integers, floats, strings) as well as NBT objects.

You'd have to delete the old one too If you absolutely need both classes, you have to full-path one of them when you use it.

Add this line anywhere the inventory changes: if (worldObj != null) worldObj.markBlockForUpdate(xCoord, yCoord, zCoord); That tells the server it needs to send the changes to the client.

Actually, it's just a convenience thing. You can totally do it inside the block's constructor (which is what I do, because then as many properties of that block that I can get away with are inside that block's class--liquids have things that are required elsewhere, etc. etc). Also, "initialize Block event"? Are you using an event handler of some kind?

And it didn't run, ergo something was wrong with it.

And....read signature.

I would look at that loop definition again. You have a mistake, evidenced by the fact that it is not spamming the console.

i == 100, eh?

http://jd.benow.ca/#jd-gui

That means there's an error that will prevent the project from launching. If its not in the source code, then there's an issue with the build path. Right click -> build path -> configure and look for more ! in that window.

Um. Yeah. Don't do this: customRenderItem = new RenderItem() Just because you created an instance of that class doesn't mean that all of its properties are set. The crash isn't happening in your code, it's happening inside RenderItem. And what's null there? renderManager . Because creating a new RenderItem doesn't magically make that property defined. Seriously:

The itemstack, the player, the world, the x/y/z location that was clicked on, the side that was clicked, then the float version of the coordinates (x/y/z), which are not round integers (e.g. if you click the center of the top face of a block you'll get 123.5, 66.0, 432.5).

Override onItemUse

In the code you have shared I do not see anything that would produce an NPE

Keep in mind that some Forge Liquids aren't liquids at all, but gasses.

= null will get you nowhere. As you can see, it's referencing the public property of the TileEntity. Thus the value is handled by the TE thusly: https://github.com/Draco18s/Artifacts/blob/master/main/java/com/draco18s/artifacts/entity/TileEntityDisplayPedestal.java#L236-249

Ok yeah, I am not sure what the problem is, but here's one thing: EntityItem ghostEntityItem = new EntityItem(tileAltar.getWorldObj()); Don't do that. You're creating a new entity every time the game renders the world. Make it once, save it. https://github.com/Draco18s/Artifacts/blob/master/main/java/com/draco18s/artifacts/client/ModelPedestal.java#L60-80

What is out dated about it? You don't decompile the mod any more and instead include it in your build path. Everything else is fine. You change the @mod annotation, just as it lists, and you add the compatibility layer as described. Java is not Javascript.

AFAIK, this is not possible with 1.8 yet.

Does this help? The black part is part of the file name, as armor has two layers and you need to supply both.

Do you not know how to use bit fields? http://en.wikipedia.org/wiki/Bit_field Edit: Sorry, that quoted section is from an old version, but the idea of bit fields is still accurate, just which field does what with which half of the door has changed. The newer sections are longer and less succinct.

Clear indicator that the user is not making a simple mistakes and has no idea WTF they're doing. This is three incredibly grievous errors caused by a lack of understanding of programming at a core level, not merely a typo or an accidental mistake. The fact that they have managed to release functional mods is irrelevant, as there's a lot of crap you can get away with when you're just adding new blocks and items because the workhorse is actually all of the stuff that Vanilla and Forge do for you. This is not "oops, I accidentally assigned null rather than comparing" this is "I don't know how to use objects." Eclipse won't let that compile. For two reasons. 1) null cannot be cast to int: Even adding an explicit cast will crash the program at runtime (I tried once, just to see). 2) objects (even simple types) cannot be cast to booleans implicitly: And Eclipse should have warned him about his uninitialized variable: Sure. We all make mistakes. We programers are fueled by insanity, Mountain Dew, and severe sleep deprivation. But there's no excuse for incompetence of this level and having to walk through each and every person how to solve simple errors is not worth my time. I thank people like diesieben07 and shieldbug1 for putting up with my stupidity regarding rather complex data manipulation, storage techniques, and ASM. But at least it's simple errors with incredibly complex devices ("oh that's why it wasn't working, because I had to reinstall stuff, I forgot the launch parameter to tell Forge to look for my coremod class"). But you know, if you are unhappy with the way people who don't know WTF they're doing around here are treated...there's a report button right here ↓

A friend of mine runs a server with over 240 mods. It lags like a mofo, but not from the sheer number of recipes, but rather from the sheer, ungodly weight, of how many different blocks and items there are and all the TileEntities spawned in the world (because why run one tech mod when you can run FIFTEEN including ComputerCraft with all of the addons).