Draco18s

You can try looking at the StringTranslate class.

Entities should totally run their movement code on the client side, as while the server will enforce what it believes is going on, if the client end isn't doing ANYTHING then the entity will jump around as it periodically gets packets from the server correcting its location.

You can also grab NBTExplorer and spy on the tags for any item.

Sorry, your other thread isn't something I can help with. Off-hand I'd guess that the box is too large for the texture or that the UVs are wrong.

No, I mean, why does it need to destroy the water in order to fly through it?

Maybe I'm missing something, but why does it need to remove the water at all?

And...as soon as someone tries to use this on a server, it will crash. public void load(FMLInitializationEvent event) { ClientRegistry.bindTileEntitySpecialRenderer(TileEntityHeads.class, new TileEntityHeadsRenderer()); <-- really, client stuff outside the proxy?

And by "changed" we mean "that was a vanilla bug, and it was fixed."

Ok, so a couple things--and this is not related to your described problem. 1) if (b != Blocks.air && b == Blocks.bedrock) I do not think this is doing what you meant for it to do. 2) worldObj.removeTileEntity(x, y, z); unless your intent is for chests (and other containers) to destroy their contents and not drop them, this is likely not a good idea. 3) } else if (b != Blocks.air && b == Blocks.water){ and } else if (b != Blocks.air && b == Blocks.flowing_water){ same problem as #1 Now, related to your actual problem: You do know that two water source blocks adjacent to each other will cause the non-source block between them to become a source block, yes? Ok good. If it's not that behavior, then I don't know what's causing your problem.

Good to know. Also I didn't write that system, I just know it works.

By the way, you also have this in your block class: TileEntityCoffeeMaker instance; That's a no-no, as the Block class is a singleton and you want to have more than one TileEntity instance. That's why world.getTileEntity(x,y,z) exists.

Couple classes involved: //sends the particle https://github.com/Draco18s/Artifacts/blob/master/main/java/com/draco18s/artifacts/components/ComponentOreRadar.java //renders the particle https://github.com/Draco18s/Artifacts/blob/master/main/java/com/draco18s/artifacts/client/RadarParticle.java //network handler https://github.com/Draco18s/Artifacts/blob/master/main/java/com/draco18s/artifacts/network/PacketHandlerClient.java

You mean like... if(side == 0) { return bottom; } else if(side == 1) { return top; } else if... ? Basic java.

See: http://www.minecraftforge.net/forum/index.php/topic,25120.0.html

setAngles applies to the body, setRotationYawHead only affects the head, as indicated by the method name. If that's not working, then it's clearly being changed by something else later. Double check your updateTick method.

Not going to watch the video to find out what they're doing. That said, here's a particle that works in 1.7 https://github.com/Draco18s/Artifacts/blob/master/main/java/com/draco18s/artifacts/client/AntibuilderParticle.java

Logger.setAngles(180, 0); ?

player.rotationYaw + 180 ?

Like I said, nbt is performing "well enough" for the moment, so I've been focusing on other tasks. But I'll look into it.

I'll take a look, but really what I need for it is a better runtime data structure. The data is constructed during chunk generation and is heavily accessed. It's just ever so slightly too slow for my liking to use NBT, but I can't figure out a better way to structure the data such that the data that's needed is held in ram and offloaded to the drive as needed; similar to chunk data, just not that much of it (I've got only a dozen or so values that need to be tracked per chunk, but it needs to be keyed by both location and string-name).

Ah! I didn't see that there was a comment-passed version. That makes so much more sense. The JavaDoc window that pops up auto-complete suggestions is not very wide, so anything beyond "string name" gets cut off and I've been using that particular getter for a while now (easily as far back as 1.6.2 if not earlier). Thanks as always, diesieben07!

And your goal here is to...?

You want per-world configs? This is Java, use your FileIO. All the tools you need already exist. The hard one to figure out was "DimensionManager.getCurrentSaveRootDirectory()" and I found that just by poking around with the classes I knew about, knowing that one of them had to know where the world's save directory was. File folder = new File(DimensionManager.getCurrentSaveRootDirectory(), "myPerWorldStorage"); folder.mkdir(); try { FileInputStream fis = new FileInputStream(new File(folder, s)); DataInputStream instream = new DataInputStream(fis); //read/write file instream.close(); fis.close(); } catch (IOException e) { //error handling } BAM. And proof that I'm not talking out of my ass: Mind, I'm saving nbt files that store run-time data not configs, but that's the rough outline of what you need.

You're missing: tc.setTag("Items", nbttaglist); in writeToNBT. Blame Ives. @Override public void writeToNBT(NBTTagCompound tc) { super.writeToNBT(tc); NBTTagList nbttaglist = new NBTTagList(); for (int i = 0; i < inventory.length; ++i) { if (inventory[i] != null) { NBTTagCompound nbttagcompound1 = new NBTTagCompound(); nbttagcompound1.setByte("Slot", (byte)i); inventory[i].writeToNBT(nbttagcompound1); nbttaglist.appendTag(nbttagcompound1); } } tc.setTag("Items", nbttaglist); //you're missing this line //tc.setInteger("siftTime", siftTime); //this is how you would set other variables that need to be saved, such as burnTime for a furnace }

java.lang.RuntimeException: class com.Looke81.BioWarfare.tileentity.TileEntityAgarPlate is missing a mapping! This is a bug! You didn't register your TE. Game crashes if you don't, hehe.