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.

Hello, I have an item that, when right clicked, opens a gui with a text field in it. When a button on the gui is pressed, it should update the NBT of the ItemStack associated with it. However, this isn't a conventional gui. When you open this gui, you can have this gui running in the "background" and do other things in Minecraft. This means that it should be possible to drop the item that opens the gui or place it in some chest, modify the text field of that gui, and update the NBT of that ItemStack, even if it is no longer in the player's inventory. I'm a bit stuck on getting the reference to the ItemStack though. I have @Override public IMessage onMessage(MyMessage message, MessageContext ctx) { if (ctx.side.isServer()) { System.out.print("[DEBUG] MyMessage received on server!"); // Somehow get the ItemStack on the server side that corresponds to this packet // This would be easy if it's always the player's held item, but it's not } return null; } Is something like this possible?

At some point, it's probably better to use TileEntitySpecialRenderer, which according to this, the 1.7 versions still work.

You can specify dependencies in the mcmod.info file.

Minecraft 1.8 is extremely different from 1.7, at least with blocks and items. The block/item tutorials for 1.7 will not work for 1.8. The best resource for learning how 1.8 works is the example/tutorial here: https://github.com/TheGreyGhost/MinecraftByExample

Thanks. I mainly wanted to see if it was possible to add a "default" tag to the .json files so that you don't have to specify the same thing multiple times (like the default case in a switch statement). For example, for a block, I'd want to have something like this: { "parent": "block/cube", "textures": { "down": "top_texture", "up": "top_texture", "default": "side_texture" } }

Can you post the code that sends the packet? I'm not exactly sure what you mean when you send packets while inside the Gui. Do you mean when you're rendering the Gui? Or when you're interacting with the Gui? When I want to send packets from the server to the client at arbitrary times, I register an event handler and send the packet based on when events are fired. If you want a Gui element (e.g. button press) to trigger a packet being sent from the server to the client, you'll need to send a packet from the client to the server. Then, when you're handling that packet on the server side, send a second packet from the server back to the client containing the relevant information.

I didn't realize you were using chunks; I was referring to world.setBlockState() . Sorry for the confusion.

If that's the case, the code you have posted right now isn't that relevant. You might want to post the code that actually sends the packets, and all of the packet related code.

Since GUI elements are client side only, if you want to want to have access to some variable on the server, you must send it to the client via a packet. You can then send that packet on the server side to the client at various times using events. This is different from reading from/writing to NBT. The NBT functions are only called when you want to "save" a value so that it persists the next time you need to use it; they cannot be used to send packets arbitrarily. This is likely what causes the "queuing" effect that you describe. See this for more information on packet sending.

Using setBlockState() with flag 2 will most likely fix your issue. The default flag, 3, schedules a block update for each block it sets.