TheGreyGhost

Hi Problem 1: oak You need to handle the wood metadata as well. Different metadata is used for different types of wood, or eg different colours of wool. http://greyminecraftcoder.blogspot.com.au/2013/07/blocks.html Problem 2: http://www.minecraftforge.net/forum/index.php/topic,23256.msg117993.html#msg117993 -TGG

Hi InitMapGenEvent looks promising. It appears to allow you to return a customised generator for mineshafts. So you could add a check on the biome to your customised mineshaft generator, similar to the stronghold one: eg public MapGenStronghold() { this.structureCoords = new ChunkCoordIntPair[3]; this.field_82671_h = 32.0D; this.field_82672_i = 3; this.field_151546_e = new ArrayList(); BiomeGenBase[] abiomegenbase = BiomeGenBase.getBiomeGenArray(); int i = abiomegenbase.length; for (int j = 0; j < i; ++j) { BiomeGenBase biomegenbase = abiomegenbase[j]; if (biomegenbase != null && biomegenbase.rootHeight > 0.0F && !BiomeManager.strongHoldBiomesBlackList.contains(biomegenbase)) // duplicate for mineshaft { this.field_151546_e.add(biomegenbase); } } for (BiomeGenBase biome : BiomeManager.strongHoldBiomes) { if (!this.field_151546_e.contains(biome)) { this.field_151546_e.add(biome); } } Do you know how to use Forge events? -TGG

Hi Is there a reason you're not using the Gradle version of Forge for 1.6.4? I had major head damage trying to install the non-gradle 1.6.4. I got it to work eventually, but in contrast the gradle version was much easier to install (and much easier to build for release too). The gradle version is 9.11.1.964, not .965 http://minalien.com/tutorial-setting-up-forgegradle-for-intellij-idea-scala/ Failing that, I found these instructions for 1.6.4 manual install with IntelliJ to be very helpful http://www.minecraftforge.net/wiki/Forge_Development_in_IntelliJ_IDEA -TGG

Hi You might find this link useful http://greyminecraftcoder.blogspot.com.au/2013/08/lighting.html Make your texture grey scale (or fully white if you want uniform colour) colorMultiplier returns a colour in RGB format. If you return 0xFFFFFF it will be white (no colour change) return 0x0000FF it will be shaded blue etc Try it and see.... -TGG

Hi If you want these all over the place, like grass, I would suggest using ISBRH. It's pretty easy, easier than TESR actually, and the rendering code itself will look exactly the same. Don't worry about the 1.8 update, that is months away and I really doubt it will be hard to adapt your render code to it. Some background info here (1.6.4 but still very similar) http://greyminecraftcoder.blogspot.com.au/2013/07/block-rendering.html -TGG

Hi Try adding GL11.glBlendFunc(GL11.GL_SRC_ALPHA, GL11.GL_ONE_MINUS_SRC_ALPHA); just after your GL11.glEnable(GL11.GL_BLEND); -TGG

Hi > QUESTION- Now that I have that and it works, how could I go about swapping the texture for an RGB value (preferable), or hex? You can probably achieve this by overriding Block.colorMultiplier(). Change the return value to the colour you want; assuming you are encoding your 1024 colours using a mixture of block and metadata, you will probably need IBlockAccess.getBlockMetadata(wx, wy, wz) too -TGG

Hi You might find this post useful http://www.minecraftforge.net/forum/index.php/topic,19719.msg100829.html#msg100829 -TGG

Hi Show your main mod class? Just to confirm - if you put System.out.println("Proxy called"); into your commonproxy and/or clientproxy, does it get called? Where do you call proxy.registerProxies()? -TGG

Hi Looks like you might be calling your MinecraftForgeClient.registerItemRenderer(ZMod.byrne, new ItemRenderer()); before ZMod.byrne has been initialised. -TGG

I'm sorry, I don't understand the symptoms of your problem. Could you show the full code please, highlight the method in your code that returns null? -TGG

Hmmm well it's for sure not your renderer. My guess is that the collision is causing your entity's position to be updated. You could confirm that by adding a System.out.println of the entity position to the onUpdate() method, posX, posY, posZ. Maybe you are using the collision boxes wrongly - eg vanilla uses this method below for all Entities except boats and Minecarts, so maybe yours should return null as well. /** * Returns a boundingBox used to collide the entity with other entities and blocks. This enables the entity to be * pushable on contact, like boats or minecarts. */ public AxisAlignedBB getCollisionBox(Entity p_70114_1_) { return null; } -TGG

Hi Show your code? getEntityData() is for storing your own information. entity.writeToNBT() might be what you actually need. -TGG

Hi Your render code looks ok to me. That symptom is weird, I'm not sure what might be causing it. I'd suggest trying something to narrow it down a bit: Add System.out.println("render at [x,y,z] = [" + p_76986_2_ + "," + p_76986_4_ + ", " + p_76986_6_+"]"); to your doRender. Then watch what happens when you throw a snowball at it. -TGG

Hi The vanilla and forge code show the way forward.... TileEntity:: /** * Called when you receive a TileEntityData packet for the location this * TileEntity is currently in. On the client, the NetworkManager will always * be the remote server. On the server, it will be whomever is responsible for * sending the packet. * * @param net The NetworkManager the packet originated from * @param pkt The data packet */ public void onDataPacket(NetworkManager net, S35PacketUpdateTileEntity pkt) { // your code here } Similarly getDescriptionPacket should return the same S35 packet. -TGG

Hi you need to override onDataPacket and getDescriptionPacket for the TileEntity. Otherwise there is no way for the server to tell the client what the contents of the jar are. 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) -TGG

Hi A general comment about alpha blending is that the order of rendering the faces is very important. If you render the rear pane alpha first, then the front pane alpha next, it will look different to rendering the front pane alpha first and the back pane alpha second. This is because of the effects of depth testing, and additionally the way alpha blending calculates the final colour. In your case, when the furthest-away faces are rendered first, then the closest faces are blended over the top, you will see the furthest-away faces. But if your closest faces are rendered first, when the furthest-away faces get rendered, they are behind the closest faces so they get culled i.e. not drawn at all. You can see this very clearly in the top screenshot, which looks like it must have rendered left - back - right - front. You can turn off writing to the depth buffer using GL11.glDepthMask(false); but the faces still wind up looking different depending on which one is rendered first. I have solved this problem in the past by writing an IBSRH which made sure to render the furthest faces first, by checking the player position relative to the block. -TGG

Hi I think the answer is "yes" to both your questions - see this page for more info http://greyminecraftcoder.blogspot.com.au/2013/07/rendering-non-standard-blocks.html in particular setBlockBoundsBasedOnState() -TGG

Hi What symptom makes you think that the EntityPlayer is different in the two cases? -TGG

Hi Perhaps the easiest way is to create your own Item with the specific texture you want? Use it for the CreativeTab's icon and nothing else? -TGG

Hi That's quite odd. It looks to me like it's trying to render as a standard cut-down block using your texture for all six sides. What is this line in there for? renderer.renderStandardBlockWithAmbientOcclusion(block, (int)x, (int)y, (int)z, lightValue, lightValue, lightValue); First thing I would I suggest you try: add System.out.println("renderWorldBlock()") to your method and see if is still getting called when the rendering goes strange. -TGG

Hi I'm going on guesswork here since I've never messed with fog. If you cancel the event, all the vanilla code around fog is skipped. So you must reproduce that code in your event (or, alternatively, only cancel the event when you want to override the default fog.) And even when your armour is affecting fog, you might need to copy some of the water fog commands into your event to get it to match vanilla water fog effect, i.e. Fogi, Fogf. I'm not sure why "unless I cancel the event at all times, even when the player is in air, it doesn't render any fog at all." Do you mean - if you intercept this event it alters the way vanilla fog works, even if you don't cancel the event? That would be strange. -TGG From vanilla:

Hi Show your proxy and main mod classes? It sounds like you are not calling your proxy code correctly. -TGG

Hi Disclaimer: I've never used the ModelRenderer. However the vanilla code looks like this ModelRenderer:: public void render(float p_78785_1_) { if (!this.isHidden) { if (this.showModel) { if (!this.compiled) { this.compileDisplayList(p_78785_1_); } I think this "compileDisplayList" means that it will accept the scale factor on the first call, but after that it will ignore it (i.e. it caches the display list and doesn't update it again). So I would suggest that you either use GL11.glScalef(factor, factor, factor) before the call to the render(), or if that doesn't work, use multiple copies of ModelRenderer, one for each size of shot. (Or just discard your cubeShot and generate a fresh one every time you change the size). -TGG

Hi Step 1 I would suggest is: put System.out.println("renderTileEntityAt"); into your renderTileEntityAt() method. If it gets called, you have a rendering code problem. If it doesn't get called, you probably have a registration problem. -TGG