Nephroid

If you know what glPushMatrix() and glPopMatrix() do, glPushAttrib(ALL_ATTRIB_BITS ) and glPopAttrib() are similar, but they work with most blending options, lighting changes, etc. Edit: After taking another look at your code, I'm guessing you don't exactly know what glPushMatrix() and glPopMatrix() do, since you don't have any transformations in between those two lines. glPopMatrix() resets any OpenGL transforms ( glScale , glTranslate , glRotate ) that you do after the corresponding glPushMatrix() call. Since you don't have any transforms, you don't actually need to push/pop the matrix. Also, it's better practice to make your ResourceLocation s static and final (and away from any other OpenGL code), since it's unlikely that they will be changing during your rendering. You don't want to make a new ResourceLocation every frame when you only need to make one at the beginning. Here are two documented examples of modifying the overlay that might help you (the GUI overlay doesn't really change between 1.8 and 1.7): https://github.com/Nephroid1/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/overlay_simple https://github.com/Nephroid1/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/overlay_advanced

I have 2 examples of custom overlays, with explanation inside the code here: https://github.com/Nephroid1/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/overlay_simple https://github.com/Nephroid1/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/overlay_advanced Though these are working for version 1.8, the same concept applies to 1.7. The first one just changes the vanilla overlay a bit, and the second one adds in a custom HP bar. These should be enough to solve the rest of your problems.

TGG has a working example here: https://github.com/TheGreyGhost/MinecraftByExample The particular file you want to look at is this one: https://github.com/TheGreyGhost/MinecraftByExample/blob/master/src/main/resources/assets/minecraftbyexample/models/block/mbe01_block_simple_model.json "particle": "blocks/lapis_block"

http://www.minecraftforge.net/forum/index.php/topic,14048.0.html#post_update_forge Look under the troubleshooting section in that thread; you'll find the solution there.

If you're going with multithreading, you will most likely have race conditions in your code if you're not careful. If you don't know what race conditions are, I suggest you don't use multiple threads. Given their non-deterministic nature, they are one of the most painful things to debug. Also, when dealing with threads, you can run into deadlock. These seem like infinite loops (i.e. the program won't move on), but they are caused when two threads are waiting for each other to finish before moving on to their next tasks. That is, thread 1 waits for thread 2 to do something, but thread 2 is waiting for thread 1 to do something else (which thread 1 can't do because it's waiting for thread 2... and so on). These are much harder to spot than infinite loops, since there's no exact line in the code that causes this. (An unfortunate thread execution order/race condition can result in deadlock.) To actually improve your coding skills, start with a better understanding of the foundations first. Don't go head first into something complex like multi-threading, since that will only frustrate you when you run into problems and lack the foundations to reason through them.

ClientPacket.createGuiPacket("gui"); Does this method send a packet to the server, or does it just create one? If not, this is where you'd want to send your packet to the server. You'd probably also want to include information about the player and tile entity in the packet too.

If you step through all the breakpoints, it should crash. You probably just didn't step through enough. If there's a breakpoint on a line, the program pauses before executing that line. I would look here: Caused by: java.lang.NullPointerException at net.minecraft.network.NetHandlerPlayServer.processPlayerBlockPlacement(NetHandlerPlayServer.java:620) ~[NetHandlerPlayServer.class:?] Go into the NetHandlerPlayServer class, and put breakpoints around line 620, on every line inside the processPlayerBlockPlacement() method.

I don't see anything too obvious. Your error log/stack trace might be helpful too.

A quick Google using ".sid to .ogg" gave this: http://soundconverter.org/ I think that's faster than waiting for a reply here.

If you use Eclipse, you can set a breakpoint on the line of code where it crashes (look in your error log/stack trace for the exact line). Then you can run Minecraft in debug mode, and it'll pause right before executing that line. When it pauses, you can check the values of all variables by hovering over them. I'm not 100% sure, but your null pointer probably isn't relevant to the actual problem. (It's more likely that you actually solved your problem, but a small mistake somewhere causes a null pointer which crashes the game.)

What I'm saying is you can generalize the box blur algorithm to things that aren't grids. A grid is essentially a Cartesian plane graph, where each node is a pixel (square region), and two nodes have an edge between them if their respective pixels are adjacent. A generalization of the box blur algorithm is apply it to an arbitrary planar graph instead of a Cartesian plane graph. Each node just represents a polygonal region (like the Voronoi partition above) instead of a square region. Since the Voronoi partition works by using a set of points, the the graph construction is pretty trivial (just take those points and have them be the nodes of the graph, and each point would represent the region that the point is in, like the image above). Of course, I'm assuming that taking the Voronoi distribution and just applying a box blur to the image isn't what the original poster wants (since that distribution is a biome map, not a height map), and he wants to map biomes to the regions without changing the shape of regions themselves.

A simple blurring algorithm is to make each pixel the average of the surrounding pixel values and itself. To generalize it to your image, instead of having a square pixel grid, the "pixels" here can be other shapes (the different regions in your image), and it doesn't have to be in a grid. You can represent each region of your image as a node of a graph (graph) where nodes are connected if the regions that they represent share a border: http://upload.wikimedia.org/wikipedia/commons/thumb/a/a4/Four_Colour_Planar_Graph.svg/400px-Four_Colour_Planar_Graph.svg.png[/img] For each node, you can do a depth-limited breadth first traversal to obtain the surrounding nodes. Then you can just average the values, and set that source node to the average value. In the case of a regular image, each pixel would be a node, and the graph is like a Cartesian plane, but in your case, the nodes are arbitrarily arranged, but the graph is still planar.

These two events look promising: RenderWorldEvent.Pre RenderWorldEvent.Post They effectively let you push/pop the OpenGL transform matrix before/after the world is rendered, which is probably what you need. That is, you'd handle those events like this: onEvent(RenderWorldEvent.Pre event) { glPushMatrix(); // Save the current transform "state" of OpenGL // Do whatever OpenGl transforms you need to zoom out // For example, glTranslatef(100f, 100f, -100f); } onEvent(RenderWorldEvent.Post event) { glPopMatrix(); // Reset the OpenGL to what it was } Here's a good event tutorial/reference, in case you need it: http://jabelarminecraft.blogspot.com/p/minecraft-forge-172-event-handling.html

Here's how I think of Guis on a high level, which might help. Most Guis have 2 parts: something that extends GuiContainer and something that extends Container. The GuiContainer is on the client side, so it should handle all of the drawing. The Container is on the server side, so it should handle all of the logic. These two components are "registered" using the getClientGuiElement/getServerGuiElement methods. When you're instantiating your GuiContainer and Container, you should pass the tile entity to both of them, and also the player inventory if needed. So it's more accurate to say that you "connect" the Container to both the player inventory and the tile entity. However, you don't connect the tile entity to the player inventory, since the Container acts like a "mediator" between the two. (For example, the Container can "take" something from the player's inventory and "put it into" the tile entity's inventory.) Since the GuiContainer also has the reference to the player inventory and tile entity, it automatically knows whenever the player inventory or tile entity changes. (The client/server things are done under the hood, so it's sufficient to just say that it magically works.)

I believe if the material of a block is solid, even if it doesn't have a collision box, a player will suffocate in it (when it's stacked 2 blocks high). I ran into something where I could walk through the blocks, but they would push me out when I tried to stay in them.