V0idWa1k3r

You still have this call. Remove it. You are not specifying the uvs here. pos, color, lightmap, tex != pos, tex, lightmap, color. Ordering matters. Same applies to the code you've copied from RenderGlobal.

lightmap is a vertex property. You can't just call it for a buffer as a whole and call it a day. This will not work. If you are specifying position, texture, lightmap and color you need to provide them. You are not providing the uvs. RenderGlobal::drawBoundingBox is written to only handle position and color. You can start the drawing with any other format and it will not work bacause it is not coded to. You need to provide your own code for doing that. This is the reason I originaly suggested using OpenGlHelper::setLightmapTextureCoords.

I do not really know if you 'need to' but you 'should' do it. You can get the current lightmap coordinates at OpenGlHelper.lastBrightnessX/OpenGlHelper.lastBrightnessY. Idealy you would just put you lightmap coordinates directly into the BufferBuilder by specifying a format that supports them though and using BufferBuilder::lightmap for each vertex.

I tried a lot but could not replicate the issue. I do have an idea of where it could be coming from. The lightmap coordinates might be wrong. You will need to manualy set them to something like 240, 240 with OpenGlHelper::setLightmapTextureCoords to achieve full brightness.

It might be an issue with MCP mappings where mods use latest mappings but your deobfuscated MC is not. I remember thePlayer being renamed to player and theFontRenderer to fontRenderer at some point. I suggest checking the actual names of fields in Minecraft class.

https://github.com/adudewithapc/Brighten-Up/blob/master/src/main/java/thatmartinguy/brightenup/block/BlockLamp.java#L34 Block::setLightLevel accepts a range of [0 - 1] and you are passing a 3. https://github.com/adudewithapc/Brighten-Up/blob/master/src/main/java/thatmartinguy/brightenup/block/BlockLamp.java#L93 Block.lightValue is an integer that should be in range of [0 - 15]. In your case it is 45, as you are passing a 3 in your Block::setLightLevel. Your light cycle is actually going to be 225 -> 90 -> 45 -> 0 (due to the way NibbleArray(the thing that stores the light values) functions it gets translated to 0 -> 9 -> 12 -> 0). If the code logs HIGH that means that you are either full of energy or your LightLevel calculations are off. Debug it further to see which case it is.

Yes it will. And the next thing it will do is load your TE from NBT data, which contains your storage data aswell. In the end you will end up with the new storage object being identical to the one you had when leaving the world.

From what I can see here you are only sending a packet to the player if this condition is correct: the getter is fine, but the energyLevel is not. You set it 2 lines above as and then you reduce the energy level by loss of energy. If something modifies the energy level of your tile you will not have that change handled here. This way of handling energy changes only handles energy loss, not gain and that is what you are observing. You need to figure out a different way of handling energy changes, maybe have something like energyLevelLastTick as a field in your TE, have that set at the end of your update and compare against it at the beginning. As long as you read and write your energy storage to TE's NBT data it won't reset. What makes you think that it resets?

This is something you will need to use QUADS for. You need to specify 4 vertices per quad(4 corners) and 6 quads(faces) make up a cube if positioned correctly. The ordering(CW vs CCW) also matters. You might need to experiment with it a bit to get the desired results. Vanilla uses models to abstract from direct rendering so I can't quite provide an example of direct rendering here.

If you look at RenderGlobal::drawBoundingBox method you will see that it uses a different GL mode of 3, which is GL_LINE_STRIP. The difference is that LINES requires you to specify a beginning an an end for each new line you draw, where LINE_STRIP assumes that the end of the last line is the beginning of the new one. You are not using the correct GL mode here. You know they say that a good question already contains an answer? This is one very good question. You know that there is a block in game that does X. The next logical step - lookup how it does X in it's code. In your case you need to override TileEntity::getRenderBoundingBox and possibly TileEntity::getMaxRenderDistanceSquared if you want your tile to be drawn more than 64 blocks away.

You already get a random blockpos to generate the structure at. Just check the block below it with World::isAirBlock for example. You can get any blockstate at any position using World::getBlockState. You should also inspect the way vanilla does things like that before asking for help. Vanilla code usually contains samples for 90% of commonly used things.

ItemStacks can't be null in 1.11 and onwards. Your IInventory contains null ItemStacks right here hence the crash you are getting. This is one of the reasons to not use IInventory and use capabilities and things like ItemStackHandler.

You have the Random as a parameter in the generate method. Get a random number from it and compare it to some other number. This is basic java.

Before drawing the box using RenderGlobal's method you must offset your BufferBuilder or GL's matrix to where you actually want to render the box at. RenderGlobal renders a [minX, minY, minZ] to [maxX, maxY, maxZ] box. You are currently offseting by x/y/z of the BlockPos in the world, and you must offset by render x/y/z + delta vector of the BlockPos in the world and your TE's pos, similar to how you draw a line.

Because the generate method is consistent and fires once per chunk generated every time a chunk is generated. You must introduce some kind of condition(or multiple) to make the generation occur less often. The condition is up to you - it can for example be a surface check(so you check if the structure can actually fit in the space it has selected and there are no other blocks in the way) or a simple random check(so you only generate it in X% of the chunks - that is the most common way of doing so).

In your pre-init/init/post-init handler. The structure generation is something the server needs to know about.

This is better, although you usually want to offset your posX and posZ by 8 so you don't extend into an ungenerated chunk, but considering the size of your structure you might trigger cascading chunk generation anyway. How can you not know what to do when you do have correct IBlockStates obtaining in some places already? This for example is correct in getting the specific IBlockState, although the cast itself is redundant. How is it that you have these lines yet you do not know how to convert other blocks to IBlockStates? Is this even your code? You also might want to change the setBlockState to also include flags and slightly modify them. You probably do not want to trigger block updates every time your structure places a block as that will slow down your generation considerably. You also should not forget that you also need to register your world generator.

You can't cast a Block to a IBlockState as Block is not an instance of IBlockState. Your IDE shoud've marked every line like that as an error and that code would not even compile. This is the entry method that gets called once each chunk. Yours is absolutely empty so your code will never run. This point of mine still stands. Your method is still empty, even after the changes. This is the method that gets called as a chunk generates, not any other method.

Additionally ItemStacks can't be null in 1.11 so your inventory class contains issues you will need to fix.

You can't pass the x/y/z like that. BlockPos rounds anything you pass to it to an integer. For rendering the double precision matters. If you want to render an outline around a block I recommend not reinventing the wheel and seeing how vanilla does it at RenderGlobal::drawSelectionBoundingBox/RenderGlobal::drawBoundingBox. That method even is public so you can just offset the matrix/BufferBuilder, call it and you are done. I would also recommend debugging if your methods are called at all.

Your render registration must be done in pre-init for entities. For items/blocks use ModelRegistryEvent. Registering items/blocks must be done in RegistryEvent.Register that is appropriate for the object(RegistryEvent.Register<Block> for blocks, RegistryEvent.Register<Item> for items/etc). Even if you are not yet using new versions of forge you should still use event registration system so you will not have to rewrite all your code when you do decide to update. At the very least you should register your models and renderers using pre-init, not init, if you refuse to use the ModelRegistryEvent for one reson or another. Why are you using RenderManager directly? You should use RenderingRegistry::registerEntityRenderingHandler(Class, IRenderFactory). Client-side only code can't be located in common classes or you will crash the server. It must either be located in your client proxy or in a class that you know for sure will not get loaded on server.

Looks correct. What is ? Is it pointing to fixed coordinates in the world? Is it being synced to the client? => te.BEGIN_LINE_POS.subtract(te.getPos()); Vec3d::subtract already returns a new Vec3d object. EDIT: there was an issue in my example. This line: is supposed to be bb.pos(x + posDiff.x, y + posDiff.y, z + posDiff.z).color(1, 1, 1, 1F).endVertex(); As you need to specify the end position relative to render coordinates aswell, my bad. Change that line in your code too and it 'should' work provided that everything else is correct.

Almost. You should not subtract the start vector as the start vector is the start of the line for rendering. Subtract your TE's position instead - that is the logical start of your line.

So in your packet the constructor that you are using in your TE reroutes to which conviniently sets every field in the packet but the field.

Define "doesn't work". Is it still crashing you? Are you not recieving it? Are the fields not updated? Posting your new code also helps. At this point you might want to use git for your code so it is both easier for you to update us with the changes you've made and for us to see your latest code.