V0idWa1k3r

https://gist.github.com/ThexXTURBOXx/c4ed6ab9920b2d9bddd75645c1df218a#file-worldgen-L45 WorldGenMinable already offsets the positions for you so no need to do the +rand.nextInt(16). You still need to multiply by 16 or lshift by 4. Aditionally that is very likely to trigger cascading worldgen/chunk runaway as @jeffryfisher said.

Just let default implementation of BlockLeaves do the checks for you. If you want your wood blocks to "support" leaves, preventing them from decaying there is a convinient Block::canSustainLeaves method that does exactly that. For some reason you are not overriding it in your log class thus the default implementation returns false and the leaves just decay as there is nothing to support them.

If your fluid block extends forge's BlockFluidClassic there are canFlowInto and flowIntoBlock methods you can override to define custom flow behaviour and have a chance of setting your 'interaction result' block instead of flowing into water, replacing it with your block and having it replaced by water next update. Apart from that - yeah, water likes to replace stuff by itself. So do forge fluids. That can produce all sorts of behaviour if unhandled and even if handled... If the water flows over your block, for example, it will be replaced by water. As will most things that have blocksMovement returning false in their material. Not much that can be done here, vanilla behaviour. In this case your only chance is the neighborChanged method. If that is the reason for custom materials then you are doing it wrong, as there is Block::getMapColor. Is not fired upon neighbor block updates. It only has something to do with comparator logic (it is only fired at World::updateComparatorOutputLevel which is fired by some blocks when their comparator level changes, itemframes, tile entities which have their default markDirty method called, ender eyes placed in frames, tileentities being removed and apparently when a blockstate is set that returns true at hasComparatorInputOverride)... So not fired when water flows into a block.

TESR and rendering of tiles in general has nothing to do with chunkloading. In fact nothing client-related has anything to do with chunk loading. Chunk render buffers generation is the only thing that the client affects but that is not chunk loading. That is you seing the blocks in the chunk. That however is pretty efficient to begin with, and TESR have nothing to do with it as they are rendered each frame from the data you provide(including FastTESRs, they are just batched together into 1 draw invocation per howevermanyyouhave instead of 1 draw invocation per tile). Look into your console - there may be a message like "Needed to grow BufferBuilder buffer...". Even if you see it though it will only result in a lagspike every time the buffer needs to be resized, which is... 1? 2? It is not something that happens frequently. If there is no such message then your TESR has nothing to do with the lag directly. Inspect your game with any profiling tool like VisualVM or something to see what exactly is slowing you down. VisualVM should be included in your jdk.

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.

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.

RenderHelper.disableStandardItemLighting(); RenderHelper.enableGUIStandardItemLighting(); yourrendercode RenderHelper.enableStandardItemLighting(); For a better example including lightmap manipulations, depth, lighting, etc see GuiContainer::drawScreen

Yes, you get the coordinates exactly the same way(don't forget to multiply by 16/lshift by 4), get the biome at those coordinates and either hardcode it with a reference check(==) or do BiomeDictionary::areBiomesSimilar(biomeAtCoords, biomeYouWantOreToSpawnIn)

If you want your worldgen to only occure in a specific biome you can compare it to your biome object directly. Biomes, like blocks and items are singletons. BiomeDictionary is good if you want your ore to generate in 'similar' biomes (ex.: if you are adding a generic salt ore and want it to generate on beaches it might be a good idea to use BiomeDictionary::areBiomesSimilar to also generate in beach biomes from other mods)

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'

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.

Well, your IDE told you what arguments you need to provide. RenderItem can be obtained at Minecraft::getRenderItem(). To obtain a RenderManager you need to properly register your renderer using RenderingRegistry::registerEntityRenderingHandler(Class, IRenderFactory). IRenderFactory::createRenderFor has RenderManager as an argument.

I assume that 2 identical topics was some kind of browser lag, right? Is only fired when a player clicks on a block with a bounding box. Water has none. You need to manually raytrace the block the player is looking at at onItemRightClick for example. See ItemBucket to see how vanilla does that.

https://github.com/blahblahbal/Blah-s-Minecraft-Mod/blob/Structure-fix/src/main/java/blahblahbal/blahmod/world/BlahWorldGen2.java#L53 Why are you comparing strings? There is a BiomeDictionary class for biome checking. Why is everything about your code always stringly typed? https://github.com/blahblahbal/Blah-s-Minecraft-Mod/blob/Structure-fix/src/main/java/blahblahbal/blahmod/world/BlahWorldGen2.java#L61 You are not multiplying chunkX and Z by 16. Yes, WorldGenMinable indeed wants block coordinates and not chunk coordinates. https://github.com/blahblahbal/Blah-s-Minecraft-Mod/blob/Structure-fix/src/main/java/blahblahbal/blahmod/world/BlahWorldGen.java#L68 Why are you even holding dimension ID in an array if you are always comparing with the first element and never with the rest of the array? Why are you even iterating over that array then? Did you mean to type int dimID = dimensions[i]; ?

As far as I can tell from my tests you will need to register a IStateMapper implementation for your blocks(ModelLoader::setCustomStateMapper) and a ICustomModelLoader implementation. How you do that is up to you, really. I'm afraid there are not many examples out there with making them work with assets that are not included in resource packs but you could theoretically do it. The problem comes with custom textures though... I am starting to feel that implementing your own IResourcePack would be easier. I was able to find some information on how that could be done but it may be different in more modern versions of the game. You could look at how forge handles mod resourcepacks at FMLClientHandler::addModAsResource. It seems that there are 2 fields that hold resourcepacks for mods - resourcePackList and resourcePackMap. In theory you could 'inject' your resourcepack implementation in them using reflection but I am not sure that the game will not proceed to "bite the dust" afterwards.

I do not know if this is the correct way to do it(i'm pretty sure it isn't and the correct one is described in the topic you've linked) but you could add your dependencies as external jar libraries in eclipse as a workaround.

If your models are located anywhere within the assets folder then it is a matter of a setCustomModelResourceLocation invocation. If they are not - you need to use a custom ICustomModelLoader. It may be possible to do with a custom IResource/IResourcePack implementation but I have never done anything like that and can't really help you with it.

EntityPlayer::isPlayerSleeping?

You use it in the exact same way you would use RenderPlayerEvent. It also has a cancelable Pre sub-event. I do not currently see any event related to EntityItem rendering, that might be impossible to cancel.

As far as I am aware you do not need packets if you only want to see things changing in the gui. See how it is done in vanilla's classes, for example in ContainerFurnace (the methods that interest you are addListener, detectAndSendChanges and updateProgressBar). Vanilla uses get/setField that you should not have unless you are implementing IInventory which you should not do, but they are only a level of abstration, you can still send/recieve any numeric data you want with IContainerListener::sendProgressBarUpdate and Container::updateProgressBar. The only thing that changes is that you can't use IContainerListener::sendAllWindowProperties... but you can still send everything using sendProgressBarUpdate. Although custom packets will obviously work too, they are just a bit more complicated

The error log is pretty descriptive. Your blockstates file is invalid here, here and here. You are not defining the "texture variable" your texture should be assigned to. For example "textures": { "someusefulthings:blocks/remove_enchantment_off" } could be "textures": { "side" : "someusefulthings:blocks/remove_enchantment_off" }

So, I've investigated the issue. I have managed to achieve something somewhat similar. In fact, I've achieved pretty much the same picture of yours! The issue is very obscure, and it lies within the way the game renders it's sky. Or, rather, within the fact that it only properly colors the top half of the sky only (+ sunrise/sunset gradients ofc) and kinda leaves the rest for the fog. Usually the fog is dense enough and matches the sky color to hide the transition from 'skybox' if you could call it a skybox to a solid color. However if you remove the fog and just set the color... Well you get the background color of the color you've specified, but the sky is a different color! Thus you see this result. The only reason I was not able to replicate your issue is because I've had my own sky renderer enabled that eliminates the issue by rendering a propper-ish skybox... I am not sure if much can be done tbh. Even custom fog rendering with GL would not help here. You can however hide the issue by matching the color of the fog with the color of the sky - it is available at World::getSkyColor. Or do not touch the color event at all. That would work as by default it matches the color of the sky. (pretty similar to what Jay suggested) Or make the fog relatively dense with your color so it hides the sky. Apart from that the sky color is hardcoded and I do not see any hooks to modify that... The biome can return a custom sky color but there are no events in place to affect vanilla biomes. A WorldProvider can return a custom color implementation but yet again - no events... You could implement your own sky renderer but it will break with any mod that does the same(although something like this might be possible in the future, see #3665) I could be missing something though.