Draco18s

You would need a new entity to handle the lightning. The native lightning entity arcs down from the sky.

My main class is draco18s.wispy.WispyBase so the first directory I see inside my zipped folder is "draco18s"

Open up the zip in something like WinRar At the zip root should be a folder called firstdwarf If there isn't, you've done it wrong.

(new SynapseIslandGen()).generate(world,random,chunkX,Y,chunkZ); <-- lets not use the random values we selected at all! Brilliant!

This won't return different icons when the item takes damage: @Override public Icon getIconFromDamageForRenderPass(damage, pass) { if(pass == 0) { return iconA; } else { return iconB; } } Just because a value is available doesn't mean that the function has to do anything with it. If you were to use this code, you would get the same icon all the time, and it would look like iconB rendered on top of iconA.

This. NBTdata is already a File object (sort of) so there's no reason to convert that to a string. Using NBT files is actually really super easy. You can in fact treat NBT files as config-like objects (someone I know is doing that, just due to the sheer volume of information being stored).

You CAN'T save an NBT to a string, it's a compressed data file. Literally. It's bzipped. The whole point of NBT is to serialize data to save it to a disc, why on earth would you want to turn it into a string? The toString() function exists because all complex data types inherit from Object, and Object has a toString() function. It's useful for printing things to the debug window.

And don't modify what the config tells you is there. Don't subtract 256, don't pass go, and don't collect $200.

Thank you very much, and to everyone who replied. The +/- 256 is from the Olden Days when items started at 256 (because blocks were 0-255) but had their own IDs. So the +256 was to offset them to avoid conflicts with blocks. It's not needed any more, but the offset is still there as part of some legacy code. You don't need to worry about it being exact. In fact, de-offseting it will make your mod slightly less compatible with other mods, as when the user goes to try and solve an ID conflict he'll see this: I:SomeOtherModItemID=4744 I:YourModItemID=5000 And be like "why the fuck are these two items conflicting? They don't have the same ID!" But surprise, surprise, both IDs get shifted up by 256 (5000, 5256) then you downshift yours again (5000, 5000) and there's a conflict.

Because IDs lower than 4096 will conflict with blocks. Highly not recommended.

That would be a block ID, not an item ID.

At least he didn't do Block MyBlock = new MyBlock() like someone else did here a while back. They couldn't understand why MyBlock.nonStaticVar would throw an error.

Short answer: Yes. Long answer isn't one I can give, as I don't know the operational details behind event handling.

Gravity doesn't exist in Minecraft. Every entity (which includes falling sand!) manages its own downward acceleration.

Use PlayerSleepInBedEvent .

Fer the love of god. MovingObjectPosition movingobjectposition = getMovingObjectPositionFromPlayer(world, player, false); if(movingobjectposition != null) { //If the object it isn't fucking NULL, then we can work with it int x = movingobjectposition.blockX; int y = movingobjectposition.blockY; int z = movingobjectposition.blockZ; world.spawnEntityInWorld(new EntityLightningBolt(world, x, y, z)); System.out.println("Target X: " + x); System.out.println("Target Y: " + y); System.out.println("Target Z: " + z); } return itemStack;

...Because you took out the first line of the function without taking out the rest of the function. Go learn Java

Yes, because it is wholly unnecessary.

Two things: 1) You haven't shown us your RendererTransmutationPillar class 2) You know you're going to need a client proxy, right? Your code as-is will crash a standalone server. Server will hit the "ClientRegistry" line and go "WTF is this?" and shit the bed.

Yes, and it works just fine. Edit: The reason you would need to render in the second pass is if you don't want the block obscuring other blocks ("ambient occlusion"). But a fully solid block with an overlay don't give two shits if stuff behind it isn't rendered when the overlay is rendered. It can't obscure itself, so the pass number is irrelevant.

If its an all-the-time thing, the one on the right looks way better. If its an angle-of-view issue, that would be annoying. No idea what the problem is.

I did mine a little differently, but same idea. https://github.com/Draco18s/Artifacts/blob/master/draco18s/artifacts/client/RenderArrowTrap.java I didn't bother with passes, I just rendered twice.

Could've mentioned that sooner. :U

Gee golly willackers. Did you try fixing your custom icon file at all during that? Or did you blindly assume that Forge was at fault?

Is your image file a png? Was it saved as a png with the png extension (as opposed to a jpg that's been renamed to png)? Is the file not corrupted?