Leaderboard

Minecraft.getMinecraft().entityRenderer.enableLightmap(); You are enabling it(even though it should aready be) but not doing anything with it at all. If you are going to work with the lightmap - do so, set it's coordinates. Your issue is that you are using too much GL and not enough tessellator. tessellator.getBuffer().begin(GL11.GL_QUADS, DefaultVertexFormats.POSITION_TEX) -> tessellator.getBuffer().begin(GL11.GL_QUADS, DefaultVertexFormats.POSITION_TEX_LMAP_COLOR) And then you can simply have the lightmap coordinates in your VertexBuffer vertices. Or even better use a FastTESR. It's format is BLOCK([3]f pos, [1]hex color, [2]f uv, [2]s lightmap) so it already has the format that is fine for your cause. That is the preferred solution as if you do it correctly(and it is pretty easy to do so) you will achieve exactly what you need without any need for GL calls at all and will gain a significant performance boost.

Also you don't need custom packets. At all. TileEntities already have syncronization methods. https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/farming/entities/TileEntityTanner.java#L84 https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/farming/entities/TileEntityTanner.java#L174-L189

The IMessageHandler#onMessage implementation should call the IvVillager method that hires the villager (after checking that it's allowed). Look at the GuiHandler code you merged from my fork of the repository, I did the same thing there.

Oh that documentary. *Shudder* That thing is just full of wild ridiculous bullshit that they sort of half-rooted in science and half-rooted in a hodge-podge of Eastern and Western mythology. And the result aligns with none of them. The most absurd thing in that film is even presented as hard science: that hydrogen bladders were used for lift. That couldn't be farther from the truth. It would take a balloon ten feet in diameter to lift something a human. Think about that for a minute. I mean, your free to use it as inspiration for a mod, but it's not an authoritative reference on fuckanything. There's a reason the words "mockumentary" and "docufiction" exists.

Block::getBlockLayer controls the pass your block is rendered at. SOLID is the first pass and that is what the method returns by default. Solid pass has no alpha enabled in it's GL states so it just renders whatever colorvalue is in the buffer(most likely the color that is on those texture pixels, as it exists even with 100% transparrency). CUTOUT_MIPPED and CUTOUT have alpha enabled but no blend enabled and they are rendered after the solid pass. They simply cut any transparency value to either be completely transparent or non-transparent. Hint - CUTOUT is what you want to return in your implementation of this method. Finally the TRANSLUCENT pass is done after every other pass and it has blending enabled, thus it renders transparency with transcluency. I mean, you should have thought "hmm, my block textures are semi-transparent, I wonder if Vanilla has something like that... Oh yea, the glass block! I better look at how that is done" but whatever

What issues? Z-fighting? You do know that you can simply offset your faces you render in your TESR, right? Define 'fly over' Define "invisible rendering". If you are experiencing Z-fighting you can either offset your faces or provide the stone texture that has 100% alpha channel at pixels that are overlayed with your TESR.

Whether or not each side needs a Forge mod installed depends on what the mod does. If it adds a new Block or Item, both the client and server must have the mod installed. If it adds a new server-side command, only the server needs to have the mod installed (though the client will also need it installed if you want to use any non-vanilla localisations). If it changes client-side things like rendering, only the client needs to have the mod installed. Set @Mod#clientSideOnly or @Mod#serverSideOnly to true if the mod is client-only or server-only to prevent it from being loaded on the opposite physical side. Set @Mod#acceptableRemoteVersions to "*" (i.e. accept any version, including none) if the mod is only required on one side. Edit: acceptableRemoteVersions, not acceptedMinecraftVersions.

Mainly because it's better to be more strict then it is to be lenient. Combined with trying to make it clear to modders that different block states are different blocks. {A concept that Mojang is trying to force in code for a long time} Its more 'We want it to always refresh, but vanilla breaks that sometimes, so special case vanilla'

Send the villager's entity ID in the packet. Don't send the number of emeralds to drop, let the server determine that itself. Malicious clients can send whatever packets they want, they could tell the server to drop a hundred emeralds. You don't need to send the player, the packet handler knows which player's client sent the packet.

You could just let the standart model system to render the stone texture and model itself so the lighting is applied for you and you do not need to play with lightmap and combined light values and then render your glow overlay with the FastTESR. Or you could try to get the correct lightmap texture coordinates. You might need to get the combined light value for each side separately with offsets for that side, not sure on this one.

https://gist.github.com/ThexXTURBOXx/042210368d57c25ebb9244e1fb96b794#file-with-glow-L32 You can't bind a texture using FastTESR, It already binds minecraft's texture atlas and re-binds it if necessary. Add your textures to the atlas, get their holder objects(TextureAtlasSprite) using any method you like (BlockModelDispatcher, custom caches, from the texture map directly) get the UVs of that object and render using them. The difference between a FastTESR and a normal one is that a normal TESR renders each tile separately, while FastTESR batches them together. FastTESR allows 1 draw invocation for any amount of tileentities which return true in hasFastRenderer which is very good for performance for obvious reasons. That comes at a cost of using the atlas texture only(which you can workaround by adding your own textures to it with either standart resourceloading process or forge events) and a loss of ability to manipulate GL states which is fine for the most part. Yeah, looking at your code - you can't do that. You need to add your textures to the texture map and use their uv's. No custom texturemaps allowed for FastTESR. You can add your textures to the map by defining them in the blockstates/model or by adding them directly to the map with forge's TextureStitchEvent.Pre event. Any method works fine. The second one offers more flexibility though since you do not need to have that texture defined anywhere and you can get the reference to your TextureAtlasSprite right there and then. https://gist.github.com/ThexXTURBOXx/042210368d57c25ebb9244e1fb96b794#file-with-glow-L23 Just get that blockpos from your tileentity with te.getPos(). No potential rounding errors with casting doubles to ints and no need to create a new blockpos object 12 times each frame And obviously return true at te's hasFastRenderer. If you don't - there is no point in even having your TESR as a FastTESR

The texture issue means that your UVs are incorrect. The code you've provided is not enough to determine what exactly is wrong with them as they are obtained at TileEntityGlow's coordX/coordY/maxX/maxY which are apparently lists? I don't see how they are initialized and thus can't tell what is wrong. Post your new code related to rendering so I can see what may be wrong with lightmap issues. There are vanilla items since MC made the change where items/blocks atlases were merged into 1 texture.

I've explained how to use lightmap in this thread: It is just x and y coordinates on the lightmap. You can return something like x : 240, y : 0 to achieve full glow effect or calculate it based on combined lightvalue as I've shown in the topic I've linked. Additionally do not forget to override TileEntity::hasFastRenderer in your tile to make your FastTESR actually 'fast'