V0idWa1k3r

Which part of it? I am not sure at which stage you are registering your blocks/items as the method is called init, so I explicitly told you that you must at least register them at pre-init to avoid issues. You should really use forge's registry events(RegistryEvent.Register) - they are nicer and more understandable and guarantee that everything loads as needed. They are normal events that you can listen to using SubscribeEvent. You are currently registering the model for your itemblock using ItemModelMesher(Minecraft.getMinecraft().getRenderItem().getItemModelMesher()). Do not. It is buggy and forge has an alternative called ModelLoader. Just call ModelLoader::setCustomModelResourceLocation. Does the same thing but without bugs or issues

If you are using Intellij 14 or later you might want to look at this: Even if you are not you might want to look at that topic. It is quite helpful as it covers common steps and issues.

Do not use ItemModelMesher(Minecraft.getMinecraft().getRenderItem().getItemModelMesher().register). It is outdated, causes bugs and obscure issues. The tutorial you saw that told you to use it is outdated. Use ModelLoader. Blocks and items must be registered at least during pre-init. Models must be registered at least during pre-init. The best way would be to use forge's registry events to register your things. Caused by: java.io.FileNotFoundException: xmt:blockstates/blocktowncentre.json *looks at the screenshot posted* xmt -> blockstates -> towncentre.json Your blockstates file name does not match your registry name. Same goes for your itemblock as you are using the same registry name.

A lot of deprecations that currently exist don't necessarily mean that it will get deleted. Currently Mojang moves to blockstates system and those methods may move to there respectively(and they have, they just callback the methods in the Block currently). Or they may not move there. 1.11.2 - those methods are still there. neighborChanged is one such example. There is no non-deprecated alternative apart from one in IBlockState. It may get deleted. Or it may not. Same goes to the MapColor. You may create your own IBlockState implementation to be safe as methods there are not marked as deprecated. Conviniently, Material.WATER returns true at Material::isReplaceable(). You might want to handle that too by replacing the water block with your interaction block using the flowIntoBlock method?

What exactly are you trying to achieve? Most likely you can just create a standart json model, bind it in your blockstates file and let standart model rendering take things from there.

You should use custom IBakedModels for your items if you need something complex, and forge's animation api if you need your items animated. That method only exists to allow rendering of tile entities as items (vanilla examples - chests, mob skulls, banners, etc.). And as you've pointed out yourself it is clearly marked for deletion.

Ah, indeed, you are correct. WorldGenMinable only offsets the ores it generates based on the vein size but not the base point. Hmm, not sure how I got confused with that, my bad. In this case you would be fine with your previous code. Although you may just be experiencing too much worldgen in general - 75 tries per ore per chunk is quite a lot, considering that vanilla by default only has a maximum of 33 for it's very common andesite/diorite/granite... Well, to be fair that's not really a lot, but could still cause some issues, though unlikely

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.