Tomalla

So ... does it fix the problem or not If it does, disable the lighting when rendering and enable it when you exit the scope.

I'm surprised nobody has ever had such a problem before. Having some data on the client side is essential for my plans and it's going to be a core mod anyways. I'm thinking of putting a custom client manager of sort either in Minecraft class or FMLClientHandler class ( and so the initialization problem would be a goner ). Any thoughts which one's a better option? Maybe other ideas? I'd really appreciate it.

I feel like it's not the problem with the overlay itself. Are you using a custom helmet? Maybe there's the problem.

But I've told you that already: You need to put your texture file inside of the minecraft.jar file. Open it up with any archiver like WinZIP, 7-Zip and paste your texture in there.

It's not really that amazing Though I'm glad I could help

Doesn't matter, it will be streched to fit the entire screen anyways.

It's just a matter of a custom texture file. Make your new overlay with transparency ( in GIMP for instance, but could be pretty much anything ), save it in PNG format and paste it into jars/bin/minecraft.jar/... Then in my paste change this part: %blur%/misc/pumpkinblur.png ... into: %blur%/<your path to the new texture inside the minecraft.jar> That's what I was rambling all about all this time This method has one big disadvantage: you will have all of these HUD elements like: experience bar, handy inventory at the bottom of the screen, health and hunger levels covered by the overlay texture. There's no way around it unfortunately. Unless you modify the Minecraft. Or a miracle happens and the Forge team puts some render handlers in there to have some control over layering the overlays but I don't think it's gonna happen any time soon Cheers

Alrighty then ... with this code you will get the following result ( in my case when wearing a golden helmet - just change it ): Bear in mind though, that it will cover all of the existing HUD elements ( just as in the image ). Also the helmet overlay is not drawn when a menu is opened, because that would cover the entire menu Here's the code for the renderer: http://paste.minecraftforge.net/view/6cff4e04 Also, add the following line in your mod init method: TickRegistry.registerTickHandler(new RenderHUD(), Side.CLIENT); That should do the trick. Let me know if that's what were you looking for

It's not really that complicated. The reason why I didn't explain a thing on how to implement a TickHandler is because I didn't know if you want to use them It's just a copy-paste job, I'm sure you'd handle that I'm sorry to hear you're eventually dumping the idea though. Cheers!

Well there's no other option. You either render it with in your TickHandler class ( but your helmet overlay will be rendered over existing HUD elements, like experience bar, hearts and stuff ) or you modify the stock Minecraft GUI classes which handle this. If you're going to modify the method rendering the HUD, just add another condition and copy the method that renders the pumpkin overlay changing the name of the texture. I don't think the TickHandler will be of use in this case, because just like I've said it would cover all of your existing HUD elements.

If you want to see how it's implemented, take a look there: net.minecraft.client.gui.GuiIngame.java, line 85 It's hard coded and there's no rendering handles around for you to use. The only option I see is to make your own TickHandler, which should receive the RENDER TickType. Put your rendering methods in the tickEnd(...) method and monitor the client if he's wearing your helmet. Edit: I forgot that it will overlay the current HUD elements. That might be bit of a problem indeed ... Ah well.

But the glass block is. You've asked for glass, you've got glass. What else do ya need then? I mean glass block Oh I don't know, then I suppose 90% of the blocks in game must not be normal to you. Fine then: a glass block is not normal. But I feel like I'm missing the point

You change your constructor to receive four arguments instead of two, so no wonder you get the error. But the glass block is. You've asked for glass, you've got glass. What else do ya need then?

Glass, like a stock glass block in Minecraft? Just follow the basic block tutorial on the Forge wiki and the actual BlockGlass.java, but there's nothing fancy really. The transparency of the block is due to the texture itself ( in comparison: the ice block uses blending and is a bit more difficult to implement ).

Some methods in Minecraft instance might get handy: Minecraft.getMinecraft().isSingleplayer() && !Minecraft.getMinecraft().getIntegratedServer().getPublic() This condition is met when playing "Singleplayer" and the server you're running is not opened to LAN.

Yes I know the client is evil, the client cannot be trusted. But the server does not have to know everything. The editing mode is just the client's business. Once my custom entity on the client side is being interacted with, it sends the packet to the server with the type of the edit ( the client's editing mode ) and other data associated with it describing what has changed. The server doesn't have to know beforehand what the editing mode actually is. Another example, which is something I'm planning to implement as well: I want to make a SoundManager wrapper class, responsible for the sounds being played on the client. The SoundManager instance is on the client side and is accessible via Minecraft instance ( Minecraft.getMinecraft().sndManager ). The question is: where should I initialize the wrapper to be instanced and accessible by each client, the way the SoundManager is? If I initialize it in one of the methods of the mod itself ( i.e. as a field in the mod class ), it's being shared between all clients. I'm hopeless.

http://www.minecraftforge.net/wiki/Upgrading_To_Forge_for_1.3.1#Key_Bindings

Alright, since it seems I've got problems with describing the problem, I'll try to explain what I want to achieve. I've registered a custom entity. When a player right-clicks on it, it does something. This depends on the editing mode the player is in. The player can change the mode by pressing a Tab key for example. When a player interacts with my custom entity, I want it to check what editing mode this player is in and do something with it. Every player can have different editing modes. Imagine this situation: there are two players in different "editing mode" each. They right click the custom entity and it either executes action A or action B, depending on the editing mode. Now the question is: where should I store the information about the "editing mode"? And to generalize the problem, how can I store entire class with custom data which I can attach to each player? I hope everything is clearer now.

You must be doing something terribly wrong. Changing colors of the vertices is supposed to mess up the position of other vertices of the blocks in the chunk. About this 'tessellating' & 'not tessellating' errors. When renderWorldBlock(...) method is called, the Tessellator is already up and running - by default you just call 'Tessellator.addVertex(...)' and leave it as it is - then after all of the vertices are added to the buffer, the Tessellator is being flushed - the textures and vertices colors are all set to the last GL11 call that was setting them up, because they were "floating" in mid-air and were not affected by these GL11 changes at all. Once they all are flushed, the current GL11 setting are used. That is why we're flushing it in this process. We want GL11 to be set differently to render it with different options. The draw() method flushes the Tessellator, while startDrawing() initialized it. When you leave the method renderWorldBlock(...) you MUST make sure the Tessellator is up and running ( so you either have not called draw() or startDrawing() methods, or the last one you called is startDrawing()). Also, once you enter the method renderWorldBlock(...), the Tessellator is up and running so calling startDrawing() to initialize it again results in a crash. Show me your code, because there must be something wrong with it.

That's the thing - I don't want to keep these instances on the server for every client. My idea was to keep them on the client side. If server wanted this data for a specified player, he would query the player and get from him the data he wants ( not necessarily using packets - maybe one simple function deriving from a player class? I don't know if it's possible ). This client - server communication part seems to cover the main problem, which is storing the data for a client. If we dumped the need for client-server communication - can player hold any custom data on his own? Something like the Minecraft instance, which reassembles the client, really generally speaking.

The problem is simple: I need to store some data on the client side, i.e.: the "mode" the player is in, maybe registered actions etc. It doesn't really matter. What does matter is, that every client would have its own instance of this data, separate from other clients and the server. Also, if it's possible, I'd like the server to be able to read this data from the particular, specified player. I don't quite know where to start. Where should I initialize the object? Do I need to register it somehow? I'd appreciate some hints on this. Cheers

Holy mother ... I've spent too much time programming in C++. It's like ... a sorcery of sort, changing class members accessors on the fly? I had no idea it's even possible. Java is full of surprises I see. It seems it works, but I'd appreciate if you actually took a look at this code and see if there's nothing more to modify in it: http://paste.minecraftforge.net/view/ed9c5d02 Thanks for telling me about these ... how are they called? Reflections? Cheers!

This option is the easiest: use the player.getLook(1.0F); to obtain the normalized vector the player is heading. Then get his position, add this vector and make an explosion at these coordinates - exactly 1 meter in front of the player. My other idea is to use Minecraft.objectMouseOver object to obtain the coordinates of the block the player is currently looking at. If during the event call objectMouseOver is already updated ( so that there's no block being destroyed there ), just monitor this variable and store the coordinates somewhere. Just my few cents.

GL11.glEnable(GL11.GL_LIGHTING);

A little update on the code: http://paste.minecraftforge.net/view/b6538f5b There was a chance for a custom block renderer to get called multiple times in a row, leaving custom texture binded when rendering the base block. Just bind the default one at the end of the call and the problem's gone.