Leaderboard

Here's an example from one of my ongoing projects, this is subscribing to a different event but in the same kind of fashion https://github.com/MistaOmega/Opes/blob/master/src/main/java/mistaomega/opes/setup/ClientEventHandler.java

Oh hell yeah, sorry for my assumption, best of luck with it. To me it looks fine, although, I have my setup in my main class, for an event listener though, it looks right at first glance, which is why I suggested going through the usual debugging things to see if there's any obvious point it stops working.

You aren't using your own IRecipe type.

Are you actually trying to install Forge for 1.5.2 or are you mistaking it for 1.15.2?

1.12 is no longer supported on this forum. Please update to a modern version of Minecraft to receive support.

1.12 is no longer supported on this forum. Please update to a modern version of Minecraft to receive support.

Howdy The code is from this example project https://github.com/TheGreyGhost/MinecraftByExample (mbe04 AltimeterBakedModel) The definition for the vertex format of BLOCK is public static final VertexFormat BLOCK = new VertexFormat(ImmutableList.<VertexFormatElement>builder() .add(POSITION_3F) //[x,y,z] .add(COLOR_4UB) // colour info .add(TEX_2F) // texture .add(TEX_2SB) // lighting (blocklight + skylight) .add(NORMAL_3B) // normal .add(PADDING_1B).build()); but you're right, the lighting is often not used / is added during rendering. If you put your code into a github I'll have a look in the next day or so to figure it out. I think it's almost certainly a block setting or voxelshape problem that's causing the lightmap to be wrong, it won't take me long to confirm it. Cheers TGG

Ah ok, now I understand what you mean. That's nothing to do with the vertex normals information, it's because of back face culling. Each quad has a direction - a front face and a back face. Usually, the back face is not drawn. The direction that the face is pointing is determined by the order of the vertices. If you are looking at the front of the face, the four vertices should be in anti-clockwise order. So if the face is pointing the wrong way, you just need to reverse the order of your vertices. For example: your left-right draws in the order of maxY, minZ maxY, maxZ minY, maxZ minY, minZ which is clockwise https://3.bp.blogspot.com/-Lh9ked7q9Lg/UejFhn9OfbI/AAAAAAAAAAY/oYem6d_fSk8/s1600/MinecraftCoordinateSystem.png Instead, add the vertices in the opposite order, i.e. minY, minZ minY, maxZ maxY, maxZ maxY, minZ -TGG

I linked you a tutorial and you can't even follow it.

The position of the player is stored in PlayerEntity getPosition() getPosX/Y/Z() and lot more similar things

Howdy I don't see you put any lightmap information into your vertex, but I presume you are using the Block vertex format? In my previous digging through the rendering code, I sometime found that to be important. DefaultVertexFormats.BLOCK // IVertexBuilder::addQuad and FaceBakery; see also DefaultVertexFormats.BLOCK. // Summary: // faceData[i + 0] = Float.floatToRawIntBits(positionIn.getX()); // faceData[i + 1] = Float.floatToRawIntBits(positionIn.getY()); // faceData[i + 2] = Float.floatToRawIntBits(positionIn.getZ()); // faceData[i + 3] = shadeColor; // faceData[i + 4] = Float.floatToRawIntBits(textureU)); // faceData[i + 5] = Float.floatToRawIntBits(textureV)); // faceData[i + 6] = baked lighting (blocklight + skylight) // faceData[i + 7] = normal; You could consider using the face bakery to generate your quads, like this /** * Returns a quad for the given digit * @param digit the digit (0 -> 9) * @param isBlank if true: this digit should be blank (is a leading zero) * @param minX: the minimum [x,y,z] of the digit quad (from the viewer's point of view). units = model space i.e. 0->16 is 1 metre block * @param maxX: the maximum [x,y,z] of the digit quad (from the viewer's point of view). units = model space i.e. 0->16 is 1 metre block * @return */ private BakedQuad getQuadForDigit(int digit, boolean isBlank, Direction whichFace, double minX, double minY, double minZ, double maxX, double maxY, double maxZ) { // generate a BakedQuad for the given digit // we can do this manually by providing a list of vertex data, or we can use the FaceBakery::bakeQuads method // FaceBakery::bakeQuad is much simpler and suitable for pretty much any block-style rendering, so I've used that here // If you want to manually provide vertex data yourself, the format is an array of ints; look in // IVertexBuilder::addQuad and FaceBakery; see also DefaultVertexFormats.BLOCK. // Summary: // faceData[i + 0] = Float.floatToRawIntBits(positionIn.getX()); // faceData[i + 1] = Float.floatToRawIntBits(positionIn.getY()); // faceData[i + 2] = Float.floatToRawIntBits(positionIn.getZ()); // faceData[i + 3] = shadeColor; // faceData[i + 4] = Float.floatToRawIntBits(textureU)); // faceData[i + 5] = Float.floatToRawIntBits(textureV)); // faceData[i + 6] = baked lighting (blocklight + skylight) // faceData[i + 7] = normal; // When constructing a face manually in this way, the order of vertices is very important! // 1) must be added anti-clockwise (from the point of view of the person looking at the face). Otherwise the face // will point in the wrong direction and it may be invisible (backs of faces are usually culled for block rendering) // 2) ambient occlusion (a block lighting effect) assumes that the vertices are added in the order: // top left, then bottom left, then bottom right, then top right - for the east, west, north, south faces. // for the top face: NW, SW, SE, NE. for the bottom face: SW, NW, NE, SE // If your face has ambient occlusion enabled, and the order is wrong, then the shading will be messed up // FaceBakery: // Vanilla uses it to convert from the elements in a block model, i.e. // "elements": [ // { "from": [ 7, 0, 7 ], // "to": [ 9, 10, 9 ], // "shade": false, // "faces": { // "down": { "uv": [ 7, 13, 9, 15 ], "texture": "#torch" }, // "up": { "uv": [ 7, 6, 9, 8 ], "texture": "#torch" } // } // }, // see https://minecraft.gamepedia.com/Model#Block_models // In order to use the FaceBakery::bakeQuad method, we need to provide: // 1) A suitable cuboid 'from' and 'to', in model coordinate (eg the full 1 metre cube is from [0,0,0] to [16, 16, 16]) // 2) the corresponding [u,v] texture coordinates for the face: [minU,minV] first then [maxU,maxV], again in texels 0->16 // 3) the face we want to make the quad for (eg up, down, east, west, etc). Vector3f from = new Vector3f((float)minX, (float)minY, (float)minZ); Vector3f to = new Vector3f((float)maxX, (float)maxY, (float)maxZ); // texture UV order is important! i.e. [minU,minV] first then [maxU,maxV] float [] uvArray = getDigitUVs(digit, isBlank); final int ROTATION_NONE = 0; BlockFaceUV blockFaceUV = new BlockFaceUV(uvArray, ROTATION_NONE); final Direction NO_FACE_CULLING = null; final int TINT_INDEX_NONE = -1; // used for tintable blocks such as grass, which make a call to BlockColors to change their rendering colour. -1 for not tintable. final String DUMMY_TEXTURE_NAME = ""; // texture name is only needed for loading from json files; not needed here BlockPartFace blockPartFace = new BlockPartFace(NO_FACE_CULLING, TINT_INDEX_NONE, DUMMY_TEXTURE_NAME, blockFaceUV); // we have previously registered digitsTexture in StartupClientOnly::onTextureStitchEvent AtlasTexture blocksStitchedTextures = ModelLoader.instance().getSpriteMap().getAtlasTexture(AtlasTexture.LOCATION_BLOCKS_TEXTURE); TextureAtlasSprite digitsTextures = blocksStitchedTextures.getSprite(digitsTextureRL); final IModelTransform NO_TRANSFORMATION = IDENTITY; final BlockPartRotation DEFAULT_ROTATION = null; // rotate based on the face direction final boolean APPLY_SHADING = true; final ResourceLocation DUMMY_RL = new ResourceLocation("dummy_name"); // used for error message only BakedQuad bakedQuad = faceBakery.bakeQuad(from, to, blockPartFace, digitsTextures, whichFace, NO_TRANSFORMATION, DEFAULT_ROTATION, APPLY_SHADING, DUMMY_RL); return bakedQuad; } If that doesn't help, I'd suggest you add a breakpoint to ForgeBlockModelRenderer::renderModelSmooth (or much easier - ::renderModelFlat if you turn off ambient occlusion) and watch how your block's quads are rendered to the buffer. I've also had this problem arise previously with blocks which used the skylight+blocklight value for rendering but which had a calculated skylight+blocklight of 0 due to the block's settings (I forget which, sorry). The breakpoint I suggested above should show that, if it's the cause. -TGG

1.7 is no longer supported on this forum. Please update to a modern version of Minecraft to receive support.

Update: ITS WORKING Screenshot: Next on the list: Smooth Lighting

I have tried many fixes to stop these errors but everything I have tried fails. Please help guys. I have tried using command prompts, but I can only use Power Shell windows and it shows this

1.12 is no longer supported on this forum. Please update to a modern version of Minecraft to receive support.