V0idWa1k3r

Well your miners_portal field you are accessing is defined as a Block. and Block indeed has no trySpawnPortal method defined. Either define your fiield as a BlockMinersPortal or cast miners_portal to BlockMinersPortal before accessing it's methods.

Why are you passing a class as a second argument? You need to pass an implementation of IRenderFactory, not a class. You have quoted the javadocs for the method you are currently using(the one that takes a class and Render as arguments). As you've quoted it is marked as deprecated and is TODO-ed to be removed.

Additionaly some potential issues which are not directly related to your problem but are still worth fixing: ItemModelMesher is outdated and buggy. Use ModelLoader. And register your models in your client proxy during pre-init or in a ModelRegistryEvent(prefered) ?

You are already using a proxy, so you must be aware of how to use it correctly and do not need someone else to write code for you here. IRenderFactory is a functional interface you can either use a lambda/method reference for or you can create your implementation of it. Can you show your RenderDogOne class? Every Render child class needs a RenderManager as a parameter and yours does not have one so I would like to see what you are passing as RenderManager in your RenderDogOne constructor's super call. This is one of the reasons to use IRenderFactory - it has RenderManager passed to it as an argument.

Rendering for your entities must be registered during pre-init. Not init and not post-init. The way you are registering your renderer is deprecated and outdated. Use RenderingRegistry::registerEntityRenderingHandler(Class, IRenderFactory) instead of RenderingRegistry::registerEntityRenderingHandler(Class, Render) You can't have client-side only code in your common class like that or you will crash the server. Move it to your client proxy.

Almost. This is correct for the most part but there is one small, illusive and obscure issue. The BufferBuilder::color method has 2 overloads - 1 that uses 4 floats of [0 - 1] ranges and 1 that uses 4 integers of [0 - 255] ranges. As integer is the default number in java when you pass in a number without specifying it's type(like you are doing everywhere with color(1, 0, 0, 1)) it is assumed to be an integer. So the method with integers as params gets invoked instead of the one with floats and... well, you are passing 1 as alpha which considering an integer range of that method is practicaly invisible. You need to specify at least one number as a float so the correct method is chosen. In my original example I use color(1, 0, 0, 1F) Note the 1F at the end. By passing that number as a float I force the correct method to be chosen.

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.