TheGreyGhost

Hi Largely a style choice, I don't think there's any consensus. Personally I think it adds unnecessary clutter, and scope hiding is asking for trouble, so I only add it if my intentions are unusual and I want to make them obvious. Others find it more clear to use this all the time. Still others give their member variables a prefix eg m_blockMetadata. If you're consistent I reckon it doesn't matter. -TGG

Hi Which slots in particular? Perhaps you could show a screenshot? Perhaps it is the first slot that gets rendered after rendering something else, so it might perhaps be due to an OpenGL render setting such as the colour, lighting, ALPHA_TEST or BLEND, that the vanilla slot code sets to something normal. You could try tracing through the vanilla for the first item render and see what commands it uses, then copy those in front of your render code. This class might be of interest to you https://github.com/TheGreyGhost/SpeedyTools/blob/Working/src/speedytools/common/Utilities/OpenGLdebugging.java I've used it in the past to check what the OpenGL settings are; it's not complete, but dumpAllIsEnabled() works and has showed up problems for me before- dump for a good render, dump for a bad render, and spot the difference. Doesn't show everything but you might be lucky. -TGG

Hi A couple of questions that will help us 1) What do you expect to see? 2) What are you actually seeing? (Screenshot?) -TGG

Good places to start are RenderBlocks.renderStandardBlock RenderHelper for item lighting OpenGlHelper EntityRenderer.enableLightMap and EntityRenderer.renderWorld -TGG

Hi A blocks' renderer is only updated when it changes or refreshed You have basically three choices: 1) If you want all blocks of that type to change instantly, you could use an animated texture for the Block similar to the Clock. 2) If you want each individual block to change, you could change the block's metadata (0..15 only) when you want the texture to change, or 3) You could use a TileEntity for that block with a TileEntityRenderer, and either store information about each block in the TileEntity (to have each block independent), or have the TileEntityRenderer use your variable for all blocks it renders (to change the texture for all blocks of that type). That's the short version. Let us know if you need more explanation and we can point you to tutorials. that 2 should be replaced with the metadata of the type of leaves you want. You'll probably find some of the pages on this site helpful http://greyminecraftcoder.blogspot.com.au/p/list-of-topics.html especially the ones on "minecraft classes", and "blocks" -TGG

Hmmm coincidence? I am guessing that the failure to find Material.rock is something to do with incorrect deobfuscation, since it works ok in Eclipse but not in the jar. The bin folder might not have the proper deobfuscation applied (not sure to be honest but it seems possible). It might be worth reinstalling your Forge from scratch and trying the build again. -TGG

No I think it is probably this one crateedgesix.mirror = true; // line 114: oops - used before creation crateedgesix = new ModelRenderer(this, 95, 3); -> you need to swap the order of these two lines. -TGG

No worries, you're welcome. We got there in the end -TGG

Hi Malkuthe I think we're going round in circles a bit here... Let me try to recap what the problem is. 1) The server receives some sort of event or notification or Message that a player has logged on 2) It then finds the information for that player, bundles it up into a Message, and sends that to the client. 3) The client gets the Message, reads out the relevant fields, and writes it into the PlayerInformation class. It seems you have two issues, then? In step 1- how does your server know which player has logged on? In step 3 - if you register this class on a dedicated server side, Minecraft doesn't like it, and even if you check the side, it still doesn't like it because some of the client classes don't exist. The step 1 problem solution depends on which event, notification, message etc that your server is using to tell when a player has logged on. The step 3 problem you can fix either by not registering your SimpleNetworkWrapper on the server side and making sure none of your server side code creates or calls SimpleNetworkWrapper, or alternatively using the proxy methods I described in my last post. -TGG

Hi Probably either the alpha values in your bitmap are not right, or alpha testing is turned off try GL11.glPushAttrib(GL11.GL_ENABLE_BIT); GL11.glEnable(GL11.GL_ALPHA_TEST); // render here GL11.glPopAttrib(); -TGG

ah yeah, mental blank, sorry. Try this instead. switch (ctx.side) { case CLIENT: { EntityPlayer entityPlayer = Minecraft.getMinecraft().thePlayer; } case SERVER: { EntityPlayer entityPlayer = ctx.getServerHandler().playerEntity; } default: assert false : "Invalid side in TestMsgHandler: " + ctx.side; } If that doesn't work due to the Minecraft.getMinecraft(), try creating your own "get the player from this context" method in your proxy class i.e. CommonProxy:: public EntityPlayer getPlayerFromMessageContext( MessageContext ctx); CombinedClient:: @Override public EntityPlayer getPlayerFromMessageContext( MessageContext ctx) { switch (ctx.side) { case CLIENT: { EntityPlayer entityClientPlayerMP = Minecraft.getMinecraft().thePlayer; } case SERVER: { EntityPlayer entityPlayerMP = ctx.getServerHandler().playerEntity; } default: assert false : "Invalid side in TestMsgHandler: " + ctx.side; } DedicatedServer:: (or alternatively - just place into CommonProxy and let CombinedClient override it) @Override public EntityPlayer getPlayerFromMessageContext( MessageContext ctx) { switch (ctx.side) { case CLIENT: { assert false : "Message for CLIENT received on dedicated server"; } case SERVER: { EntityPlayer entityPlayerMP = ctx.getServerHandler().playerEntity; } default: assert false : "Invalid side in TestMsgHandler: " + ctx.side; } -TGG

Hi >If this is a packet that your client sends to the server, the server knows from the packet information which client it came from. The information you need is in the MessageContext ctx, for example public IMessage onMessage(MessageClientPlayerInfo message, MessageContext ctx) { switch (ctx.side) { case CLIENT: { EntityClientPlayerMP entityClientPlayerMP = Minecraft.getMinecraft().thePlayer; } case SERVER: { EntityPlayerMP entityPlayerMP = ctx.getServerHandler().playerEntity; } default: assert false : "Invalid side in TestMsgHandler: " + ctx.side; } Is that what you need? -TGG

Hi Show a screenshot of what you actually see? Also your code for creating and rendering the GUI? -TGG

Hi In this case you can get the player from the event when the client logs in. Your server receives information somehow that a client has logged in. If this is an event, the player will be given to you. For example public PlayerLoggedInEvent(EntityPlayer player) If this is a packet that your client sends to the server, the server knows from the packet information which client it came from. At a pinch, you can get to players on the server side as described here http://greyminecraftcoder.blogspot.com.au/2013/10/server-side-class-linkage-map.html But that shouldn't be necessary. -TGG

Hi I don't really understand from your question who is sending the packet and who is receiving it. The client always knows who the player is, Minecraft.getMinecraft().thePlayer When a packet arrives at the server, it knows which client it received the packet from and hence also the player for that client. If you need to send a packet to the client from the server, the server will already know who the client is without having to read it out of a message. Perhaps you could explain in a bit more detail what packets you are planning to send back and forth, and how they are triggered. -TGG

Hi Pure guess: WorldProvider.getBiomeGenForCoords WorldProvider.registerWorldChunkManager and WorldChunkManager.getBiomesForGeneration -TGG

Hi Just a guess- Are you calling registerBlocks() in preInit? (If not - you should be, i.e in your public void preInit(FMLPreInitializationEvent event) { Also - did you build using gradlew.bat build? Your output files should then be in build/libs. -TGG

Hi Looks like it's been completely replaced with methods in other classes eg ClickEvent. -TGG

Hi Changing the lighting model in Minecraft will be very difficult, because it does not work like you think it does. See the link(s) I posted earlier. You can change the colour of the block light in the light map to make it more orange, that will affect every torch and glowstone in the game. And even that is rather difficult. I would suggest to forget about it and try something easier -TGG

Hi There seems to be some of the crash log missing? It doesn't say what the exception is, which would be helpful. Anyway it seems to have something to do with the proxy, so perhaps you have changed the name of the proxy class, or deleted or moved it? @SidedProxy(clientSide="testframework.clientonly.CombinedClientProxy", serverSide="testframework.serveronly.DedicatedServerProxy") Perhaps these are wrong, misspelled, you have moved the proxy class or renamed a package? see here for background info http://greyminecraftcoder.blogspot.com.au/2013/11/how-forge-starts-up-your-code.html -TGG

you sound surprised? :-P

Hi These links tell a bit more about debuggin Null Pointer Exceptions http://www.cs.man.ac.uk/~johns/npe.html http://www.terryanderson.ca/debugging/run.html In your case, the error message says java.lang.NullPointerException: Initializing game at net.wowcraft.model.ModelCrate.<init>(ModelCrate.java:114) So the symptom shows up at your ModelCrate constructor on line 114. You pasted a few extra lines into the crash class so the error is actually at line 109 crateedgesix.mirror = true; // line 114: oops - used before creation crateedgesix = new ModelRenderer(this, 95, 3); This a common problem with the code generated by Techne. -TGG

Like this perhaps? http://www.minecraftforge.net/forum/index.php/topic,13154.msg68940.html#msg68940

Do you mean you want to create a light source which illuminates the surrounding blocks with (say) red light instead of the yellow light from a torch? Or do you mean you want a torch which looks red, but still lights up the surrounding blocks with yellow light? -TGG

Hi I've sent you a PM about this. -TGG