V0idWa1k3r

The way I see it implemented usually is either using the ParticleManager.addParticle while checking for user settings for particles(although the last step is mostly ignored) or with custom from-the-ground-up built particle systems. Obfuscated names should be in your %username%/.gradle/caches/minecraft/de/oceanlabs/mcp/whateveryouareusing... or MCPBot

Well, technically there is absolutely nothing stopping you from using reflections on that map field to check if the given key has any value associated with it if you are so insistent on using the ParticleManager...

The error message is pretty self-explanatory. Set<Biome> is not a Biome array and can't be cast to one. BiomeDictionary::getBiomes returns a Set<Biome> and you need a Biome[]. As for your first issue you should look here:

Yes, you are right, I misunderstood the question a little bit

You will need to use one of forge's render events, like RenderWorldLastEvent. You can get the block the player is looking at with the World::rayTraceBlocks method. I believe it's HitResult returns you the BlockPos of the block the player is looking at with EnumFacing of the side the player is looking at. Your rendering position would then be the raytraceresult position offset by that facing. To render a blockstate in the world you can look at RenderFallingBlock class. There might be some issues with transparency but in theory you can just enable blend with appropriate source and destination factors and either use gl's color method or manually override vertex color data in the vertexbuffer you are rendering your block with using VertexBuffer::putColor. Just do not forget to properly offset your rendering, or you will be the third person in a row with the rendered object 'following' the player/not rendering

Define 'extract'. If you mean get the ItemStack for the recipe manager you would get your slot with the method I have mentioned above and call Slot::getStack(). If you want to remove the item from the slot you can use Container::putStackInSlot(int slotID, ItemStack toPut)

You can't. There is no model or a blockstate file for a chest, because Mojang hardcoded the rendering of the chest into the game's code. See TileEntityItemStackRenderer::renderByItem. It literally checks if the block if the itemstack being rendered is a chest and renders it as a tile entity if it is

You can create your own model that would seem just like a chest. I mean, a chest model isn't that complicated, it is a 14x14x14 cube with a 1x2x1 lock . There is a way to bind TileEntitySpecialRenderers to Item+meta pairs(ForgeHooksClient::registerTESRItemStack) but it is marked as deprecated and is commented as 'Will be removed as soon as possible', so I wouldn't use it.

Problem №1. Chests don't have a normal inventory model. Their rendering is built-in. Problem №2. You need to register your TileEntity with GameRegistry::registerTileEntity

You mean when in third person view? Just check that the entity you are drawing the box around isn't the client player. Define 'teleporting around'. It is already translated using partial ticks so it should move smooth with the entity it is drawn around. If that entity is being teleported then the box is obviously going to follow the entity.

Pretty much something like that, yea. The particular implementation is up to you

I don't think you have fixed it as it is still clearly following the player with some of it's vertices. You should really use the RenderLivingEvent to not suffer with translations that much as it already has everything figured, you would just use the X/Y/Z it provides. VertexFormat is a way to tell OpenGL what data do your vertices carry. Like position. Or color. Or texture coordinates. When you start drawing with Tessellator's VertexBuffer you specify the format - the way vertices are packed. You should then follow that format when declaring your vertices. If your format is POSITION_TEX which is basically position followed by texture coordinates your vertices should include both (pos(xyz).tex(uv)). If you are not planning to use texture coordinates don't use the format which includes them. There is a POSITION format which only requires position. Or POSITION_COLOR.

Yes, you need to specify your AABB correctly. With appropriate XYZ coordinates. Something like (posX - 0.5, posY, posZ - 0.5, posX + 0.5, posY + offsetY, posZ + 0.5) Your vertexformat is position + texture coordinates yet you are only providing the position to your vertex. Why does your format even include texture coordinates if you are disabling the texture units with OpenGL in the first place? Also you do not need to call draw every n vertices. You can upload all your vertices first and then call the draw method.

Ehh.. What? It is fired each frame, as any other render event. I don't really get the 'player can be assigned later' bit too. Assigned to what? RenderLivingEvent only fires for entities which are, well, drawn on screen. The entity object you get in that event can't be null. And as far as I am aware MC will not render players on the client (and thus will not call the event) untill the full data but the skin has been recieved for that player. And if you really need it you can even wait for the skin to be recieved with a simple if check... I do not see the startDrawingESPs method, but I assume it simply renders the AABB you've provided. You are not offsetting enough. Say your entity is at 20 10 10. And the player is at -20 10 10. Right now you are translating the tessellator to 0 0 0... and rendering the box there. You know, at 0, yourEntityOffsetY, 0. Why are you not applying the X and Z entity coordintes to your aabb? Also your minY and maxY coordinates are the same for your aabb. Unless you are handling that differently in your render function that will not work.

There are 2 sub-events of the RenderLivingEvent - Pre and Post. I think you can figure out when they are fired by their names. And if you want your outline to be drawn over an entity you need to disable GL depth. A 'glowing effect'? Could you explain with a bit more details what are you trying to achieve? If you want the outline to be bright you need to pass appropriate lightmap coordinates to tessellator's vertexbuffer

There is a ClientChatEvent in forge that allows you to process messages the player is sending to the chat. If you cancel the event the message will not be printed to the chat. That event is client-side only. There is also a ServerChatEvent that does the same but on a server. If that is canceled the message will not display for other players, but only for the player who typed the message, I think.

Just store all your knowledges in a list/set/map in your capability.

You need a dev version of the mod. Also 1.7.10 is not supported on this forum.

Does not have what? The instance of itself? It sure does Or do you mean partial ticks? It also does... RenderWorldLastEvent is fired each frame after everything else but the player's first person hand has been rendered (hence the name). Update: Just tossing this out here, RenderLivingEvent is clearly superior for the effect you are trying to achieve. It even has the X/Y/Z variables signifying entity positon <-> camera position offset for your rendering right there, ready to go! No extra translations required

It is the event instance that the rendering is done at. Also that is a code example, you might need to tweak it before it starts working as you want it to work.

I believe I have already solved a very similar issue today

Depends. RenderManager still has those fields, they are just private. But I think that you want to use the viewerPosX/Y/Z ones. They require the RenderManager instance though. You might want to look at EntityRenderer and the way it handles player-camera-based transformations, if I understood your intentions correctly. What do you want to achieve? AxisAlignedBB can simply be instantiated (new AxisAlignedBB(x0, y0, z0, x1, y1, z1)). It changed a bit though(it's xyz fields are now final and it has a few new methods) so you might want to see how vanilla handles it now.

Show your code? The following line works just fine for me: Tessellator.getInstance().getBuffer().begin(GL11.GL_QUADS, DefaultVertexFormats.POSITION_TEX); Have you added GL11 to your imports? In any case you do not need to reference GL at all. GL_QUADS is a constant of 7. So Tessellator.getInstance().getBuffer().begin(7, DefaultVertexFormats.POSITION_TEX); Will work exactly the same, just look slightly more messy with that 7 out of nowhere

draw still exists, it is just not in the VertexBuffer, but in the Tessellator itself: Tessellator.getInstance().draw()

it is now called begin, and takes an integer and a VertexFormat as parameters. Integer is just the drawing method, the way your vertices are drawn by OpenGL. You can reference GL directly(for rendering quads you would use GL11.GL_QUADS, or for something more complex you can use other drawing indices). VertexFormat is the way your vertices are packet and uploaded to OpenGL. While you can define your own format there is no need to do so as all of them can be found in the DefaultVertexFormats class. Their names are pretty self-explanatory