Draco18s

Block#setLightOpacity(0);

Thanks diesieben. I found you answering this question for 1.7.2, but the EPMP class wasn't mentioned and for some reason Eclipse absolutely did not want to raw-text-search the project (with working sets I can usually get it to locate things, last night though it just failed). Now I can get my pseudo "two requirements" hack to work properly. While a single player playing alone would be forced to get things in order, not having to craft a furnace made it possible to skip one. It's just for visual awesomeness anyway, the invisible achievement still shows up in the chat log.

As title. I can't seem to figure out where in god's name the right function is. I can see "hasAchievementUnlocked" in the Methods.csv but I can't locate a single item in the entire Minecraft codebase that has that name.

It's the effective humidity of the biome. Deserts are dry, jungles are wet. The canonical range is 0 to 1, but is technically unbounded. I've gone in an fiddled with levers and made the nether biomes negative and pushed the wet biomes up as high as 2 with no undo effects (technically speaking, there is a clamp on the values--between 0 and 1, I think--for when it uses them to get grass and leaf colors). I would roughly approximate the rainfall value as "that value + 1" in inches of rain per month, ignoring the Minecraftian "the entire world has the same weather state" effect. It's not entirely accurate, but its the translation I've used for my own mod, and no one has a good concept of how much rain their Real World location gets every month anyway. Temperature, by the way, roughly approximates 0.1°MCU (Minecraft Units) = 10°F. Freezing weather in Minecraft is right at 0.2°MCU which is pretty darn close to the Fahrenheit scale, although some biomes (cough, desert, cough) are artificially high or low so that the grass color matches the desired hue. Temperature canonically ranges from -0.5 to 2. Again, they're clamped for rendering the color, but I haven't figured out how. 0-2, I assume, but there might be some value transformation prior to that to account for the preternaturally cold regions with negative temps.

www.minecraftforge.net/wiki/Multiple_Pass_Render_Blocks

world.getWorldTime world.getBiomeForBlockCoordinates world.isRaining

There's already a function that converts worldTime into a sun angle. Ah here, world.getCelestialAngle(0) . The 0 is a time offset, so passing 0 means "right now" and passing 6000 would mean "the height 6000 ticks from now." The returned value is an angle (in degrees, iirc). I'm using it like this: float sunHeightVal = (float)Math.sin((event.world.getCelestialAngle(0)+0.25f)*2*Math.PI); As I'm interested in knowing how high in the sky the sun is. The +0.25 is needed as getCelestialAngle actually subtracts a quarter of a rotation out (see WorldProvider line 102), then I convert to radians and Math.sin that.

Again, you're going to have to insert some debug statements to determine the cause. I can't give you any more help from here.

Yup!

Ok, from that, I get the following: Looking at Render_Immersion_Tank.java line 37, I see the call to renderFaceXNeg. renderer.renderFaceXNeg(block, x, y, z, newIcon); Only two things could possibly be null here: block or newIcon . My bet is on newIcon . Insert some debug statements to figure out which path through your if statement the code is taking and what value newIcon has at each step. Work backwards until you figure out where the null is coming from and why.

A texture is just that a texture. If you want to render two at once, you need to render in multiple passes.

You got a crash, which is a Null Pointer, and you didn't bother including the crash report.

Packets.

Follow the chain. Where is that function called from? Trace it back until you find where the call originates with a block. And no shit it doesn't use your teleporter. The point is to figure out how the original function is used so that when you make the call passing your teleporter, you're doing it in the way that the system expects.

But where is transferEntityToWorld(Entity entityIn, int dim, WorldServer old, WorldServer new) called from? That's my point. I'm not saying "use this function" I'm saying "how is this function used in vanilla?"

My point was: Trace back the call structure. How is vanilla doing it differently than you are?

Right, that one specifies that the teleporter being used takes you to the nether (or back).

I can't read your code well enough to figure out what's wrong. But, just as a dead-simple method that flattens things (but is not necessarily) the best: for(x) { for(y) { for(z) { nbt.setInt(x+","+y+","+z, array[x][y][z]); } } }

Iiiiiin your sword class.

Ah, well that's a bummer. You might have to take a look at what calls transferEntityToWorld (there's two, btw) and see how Vanilla does it.

You can have the slot graphic portion exist separately from the background and draw it only when needed, like how the furnace draws the arrow filling up or the heat meter going down. Only instead of a progress bar, it'd be a yes/no type thing.

override getContainerItem(ItemStack stack)

I think so. I've only ever dealt with trans-dimensional teleport once, and it was only for players (required "feeding" an entity). And that was a while ago (in 1.6). But I was able to use what little I did know about the dimensions system to dig that up. No, I don't recall why I ever needed to access a reference to a specific dimension.

A few things I've learned having to deal with these events: There's four events you need to be concerned with. Chunk generation. There's a thousand different events here, you'll need to figure out which one you need, if any ChunkSave. Save the data, duh ChunkLoad. Read the data ChunkUnload. Cleaning up your data so you don't have a memory leak. [*]#4 there is not strait forward. ChunkSave will run after ChunkUnload, so you should either a) keep a Weak reference to the chunk object itself for mapping your data in a HashMap<Chunk, MySpecialData> or b) use the event to note which chunk has been unloaded, and then when ChunkSave happens, also remove the data from memory. [*]Chunk NBT is just like any other NBT, you can read and write to it very easily, you just have to translate your data structure into primitive types. You can actually cheat and just look at the world when the block updates. Examining the world doesn't take that much CPU time (I've clocked it: examining an entire chunk takes about 0.6 milliseconds† even when using world.getBlock instead of directly accessing the chunk block arrays). You'll lose a small portion of realism by taking shortcuts, but it'll be easier to code. e.g. searching NSEW in straight lines will be easier to write (but less accurate) than trying to A* to bedrock. †This is based on my own code and using Time.getNano().

Create a new class.