TheGreyGhost

Hi I don't understand how your code is supposed to work. I think you might be confusing "server side" with other clients. There doesn't need to be any raytracing on the server, unless you want your server to raytrace each player's line of sight and send the resulting location to all other clients using packets or IExtendedProperties, which seems unnecessary to me. What I think you should be doing is performing your raytracing on the client for each of the other players. The server has nothing to do with it, except that it communicates between the clients to tell where the other players are looking, which it does already. If you want to stick with the server doing the ray tracing, I suggest you add a few System.out.println statements to your server calculations to se if they're working correctly and narrow down where the problem is. -TGG

Hi There are probably a couple of problems. For example, you need to override onDataPacket and getDescriptionPacket for the TileEntity. This example code for 1.6.4 shows you a working example. https://github.com/mnn/jaffas/blob/59b59f01a1f2f6b21b0dc87e5a15e6761a3f3f19/src/minecraft/monnef/jaffas/food/block/TileEntityPie.java#L117 Should still work in 1.7 with some tweaking (i.e. Packet name change) The @Override question - something like this @Override public void readFromNBT(NBTTagCompound tag) { (Google @Override to see why it's important) A better way to track your program flow, instead of q = 1/0, is to use eg System.out.println("readFromNBT"); I'm not sure why your q=1/0 appears to show that this code isn't reached. Perhaps your compiler is optimising it out, and that code actually is executed. Try the System.out method instead and see if that's really the problem. -TGG

Hi Having @SideOnly(Side.Client) and if (!world.isRemote) doesn't make any sense together. onNeighbourBlockChange does some unusual things too. Did you look at a vanilla block such as the iron door or the piston or the note block? -TGG

nice

Hi I'd suggest you use an IItemRenderer for your item, and return false for the ENTITY_ROTATION ItemRendererHelper. There are a few tutorials around on IItemRenderer. Also this link with background information (see the Item Rendering sections) http://greyminecraftcoder.blogspot.com.au/p/list-of-topics.html -TGG

Hi The packet size limit used to be 32k, it might be bigger now (not sure offhand). I would recommend splitting into smaller packets no larger than 5k or so, and limiting the number you send as much as possible. From what you describe, it doesn't sound like you need to send much information. -TGG

Hi I don't know why your rendering is swapping the colours around in different views. I'd suggest that you can fix it by using an IItemRenderer. It's a bit more effort but gives you a lot more control over rendering in different views. A quick google should show up several tutorials on it. -TGG

Hi I think you need to override onDataPacket and getDescriptionPacket for the TileEntity. This example code for 1.6.4 https://github.com/mnn/jaffas/blob/59b59f01a1f2f6b21b0dc87e5a15e6761a3f3f19/src/minecraft/monnef/jaffas/food/block/TileEntityPie.java#L117 Should still work in 1.7 with some tweaking (i.e. Packet name change) -TGG

Well it helps too that I have been coding C++ for quite a while and made that mistake myself probably a couple of dozen times over the years -TGG

Hi That is caused by the vanilla minecraft code, which converts a 2D icon into "thickness" slice. The gaps are caused by the way it cuts it into slices. Look in ItemRenderer.renderItemIn2D() for more clues. The only way to fix it is to copy the renderer and optimise it for your larger icon (or, if it's just this one item - create a proper model for it) -TGG

Hi So you don't actually want texture blending, you just want different textures for the different parts of the model? Based on my work with blocks, you can switch textures if you make sure you flush the Tessellator in between switching. Most of the rendering code just queues up commands on the Tessellator, so if you do this code: 1) change texture using GL11.bindTexture 2) do Tessellator commands 3) change texture using GL11.bindTexture 4) do more Tessellator commands 5) flush Tessellator (to OpenGL) the actual order that the OpenGL sees is 1) change texture using GL11.bindTexture 3) change texture using GL11.bindTexture 5) flush Tessellator commands (2) and (4)(to OpenGL) Whether this applies to you or not depends on what you're rendering. Could you show your code? -TGG

Hi You might find this topic interesting, it might be related to your issue. http://www.minecraftforge.net/forum/index.php/topic,14315.msg73758.html#msg73758 Easiest solution = derive from EntityArrow not Entity. Not 100% sure it still works but it's worth a try. -TGG

no worries

You have forgotten a break; in your switch so it is falling through from EQUIPPED into EQUIPPED_FIRST_PERSON -TGG

Hi It looks like you cut and pasted fragments of your Item initialisation and recipe code, but I'm guessing you haven't initialised the item properly by the time you create the recipe. Your recipe then contains an ItemStack with a null Item, so when you first use it (the crafting tries to render it) tries to use the null item reference and crashes. Use preInit for items and postInit for recipes. See here for more background information. http://greyminecraftcoder.blogspot.com.au/2013/11/how-forge-starts-up-your-code.html -TGG

If you want to make sure your particles render last (after the blocks) then that is a good way to do it. It's pretty straightforward. It's funny though because I could have sworn that particles render last after blocks, (in EntityRenderer.renderWorld), and here's a comment taken straight from Forge MC 1.6.4 //Forge: Moved section from above, now particles are the last thing to render. Ah - when I look in 1.7.2 the particles are now back in the middle and I find this comment // ToDo: Try and figure out how to make particles render sorted correctly.. {They render behind water} So I guess they broke something moving the particle render Anyhow your queued render should work I reckon. -TGG

I'm surprised you can decrease the amount of damage that a player takes just on the client side. Normally the server keeps track of all that kind of information. Perhaps the "client side" code is actually running on both sides? You might find that it appears to work for a while, and then your client suddenly loses health when the server resynchronises the health datawatcher. -TGG

Hi I suggest you derive your new Entity from the Squid class, make sure you can spawn it and it acts like a Squid. Then override one method at a time to implement the new behaviour you want (if any). What specifically are you trying to do that isn't working? -TGG

Hi You need to initialise the Block before the Item. So the order of this is the wrong way: TD_Items.init(); TD_Blocks.init(); -TGG

Hi This link may help. Talks about JDK, installing forge, etc. http://www.wuppy29.com/minecraft/modding-tutorials/wuppys-minecraft-forge-modding-tutorials-for-1-7-set-up-part-1-jdk/#sthash.TFaTXRwp.dpbs -TGG

Hi Yeah it gets complicated real fast when you start trying to do alpha transparency "properly". You could add an independent rendering step, sort of a custom TESR render like you say and I'm sure it's possible (I've done something very similar myself), although it was a lot of work to get it right and you'd have to be real careful to make sure it doesn't overload the game if there are too many TESRs. Re x,y,z : from memory the render x,y,z are relative to the player position, i.e. translated so that the player is at 0,0,0. You can tell pretty easily where the player is looking from its yaw and pitch. For more clues look in EntityRenderer.renderWorld(), which also deals with the Camera Frustrum (eg so that things behind you, outside of your viewing frustrum, don't get rendered). -TGG PS nifty site, thanks for the link

Hi When alpha blending, the rendering order of the faces is important because if you draw the near face first, the further-away face can get culled, and also because the result of blending A onto B is usually not the same as blending B onto A. You could try turning off depth buffer rendering when rendering your transparent faces, so that front faces don't totally hide the rear faces. But that might not help; you may need to sort the faces in your TESR to make sure you always render them from furthest-first to nearest-last. eg here for more background info http://www.opengl.org/archives/resources/faq/technical/transparency.htm 15.070 http://www.opengl.org/wiki/Transparency_Sorting http://www.openglsuperbible.com/2013/08/20/is-order-independent-transparency-really-necessary/ Minecraft has pass 0 vs pass 1 to make sure that transparent (alpha blended) is rendered after non-alpha blended. See this link, the "Rendering Transparent Blocks" section http://greyminecraftcoder.blogspot.com.au/p/list-of-topics.html (Although- offhand I'm not sure how that directly applies to TESR. I think that TESR are rendered after all the blocks are rendered, including alpha (pass 1) blocks). -TGG -TGG

Hi Well that's confusing. I'm out of ideas. This link should work for that utility if you are still keen to try it. https://github.com/TheGreyGhost/SpeedyTools/blob/master/src/speedytools/common/utilities/OpenGLdebugging.java -TGG

Hi You'll probably find this link useful http://greyminecraftcoder.blogspot.com.au/p/list-of-topics.html Look under the "Block Rendering" sections -TGG

Hi Try this http://www.wuppy29.com/minecraft/modding-tutorials/wuppys-minecraft-forge-modding-tutorials-for-1-7-releasing-your-mod-standard-setup/#sthash.MW1oULXB.dpbs You must use gradlew build because it turns all your readable names (like rock) back into the obfuscated minecraft names. If you just export using eclipse, your jar contains references to all the readable names, which don't exist in the minecraft code. -TGG