SerpentDagger

Instead of drawing a whole arrow/flame, draw (progress / total) of the arrow/flame. You can still use the same textured-rectangle-drawing method you always use. You can always look in some source classes to get a better idea of what you're doing, too.

Perhaps you just want to render a block there instead? I'm not sure exactly what your intent here is, but that might be what you're looking for.

I'd suggest you take a look at EntityMinecartCommandBlock, as it seems extremely similar to what you want.

Do you want the arrow at the top of the radar to always point upwards (the direction the player is facing), or North? Regardless, the screen positions of the mobs can be determined in the same way. - Assuming the player's position in the radar is (0, 0), then, without rotation, a mob's position can be (a, b). - What you want to do is rotate the point around (0, 0) by the amount the player is rotated from North (alpha, in my diagram), which is equal to EntityLivingBase#getRotationYawHead(), plus some number (I think 0 radians). You can take the rectangular (a, b) coordinates of the mob, and turn them into polar (r, theta) coordinates, as shown in the diagram. - Then, you add the player's alpha to the mob's theta, to get the new mob's theta and the position is rotated. - Now you just need to turn that position back into rectangular coordinates for the renderer, as shown in the diagram. Edit: Definitely use Math#atan2() for the derivation of theta from (a, b). It'll make your life much easier. Also, all of Math's methods use radians, not degrees. I've included a conversion table in the diagram.

In my 3D graphing calculator mod, the complexity of the graph being rendered can be extremely large. As such, I'm looking for the most efficient way possible with which to render the graph. I store all the vertices of the graph within a Vec3d[][], and iterate over that array during FastTESR#renderTileEntityFast(), the code for which is shown below. Is there a more efficient method of achieving this?

What exactly do you mean by this? I'm happy to help where I can, but I need a better idea of what's actually going on, what should be going on, and how the problem exists in between those two states. (Pictures would be an easy way of demonstrating these things.)

It is indeed.

Unless there's a reason you need to, you should definitely use a FastTESR here instead of a normal one, to have much lower performance impact. That would fix your transparency issue, too, since the settings are already correct. Otherwise, I think you need to GlStateManager#enableAlpha(). As an aside, what's with the translatef() and isGlobalRenderer() calls?

Could you show us an example picture? No idea what you're referring to.

You can use RayTraceResult to store the result of ray-casting on a World object. (That's how it works in 1.12, at least. Not sure if it's different in 1.14, or if you're even using 1.14) Edit: Whoops, my bad, it's easier to use Entity#rayTrace() in your situation.

There might be some built-in capability for this, in which case you can ignore me, but this wouldn't be difficult to do "from scratch," so to speak. You could fairly simply store a boolean for each chunk, whether or not it's been affected by your ore generation, and do some block replacement logic on the chunk if not (then toggle the boolean, naturally). You would only need to run this check when a chunk was loaded, so you could use the event that fires when a chunk is loaded (I'm not sure what it's called in 1.14. From a brief search, it seems to be ChunkEvent.Load, but don't quote me on that). I haven't done world generation yet, so I can't advise you on keeping runaway chunk generation from happening, but you should look into that if you haven't already.

Your problem seems to be similar to this one. If the block is a TESR or FastTESR, then you should be able to solve it with the same solution as I suggested there. (That is a 1.12.2 post, however, so the method names might be a little different. I suspect the underlying rendering code is pretty much the same, though.)

Seems like you're trying to implement a class that isn't an interface. Make IHasModel an interface, then remove IHasModel and take a look at this. (Code-Style #3, among everything else.)

I think this might be your problem. lol (Or maybe the repo's out of date?)

You can override Item#isEnchantable(), and alter the return conditions. In your case, you'd probably just want to return true.

You can get the inventory of an EntityPlayer object, check through it for your ItemStacks, check if they're large enough, and, if those checks are passed, shrink the stacks by your amounts.

After scouring the rendering code, I found that the problem was because the vertices weren't sorted in relation to the player's view, and that I could return true from TileEntity#shouldRenderInPass() during pass #1 instead of pass #0 to opt-in to the vertex sorting. The transparency now works perfectly.

Unless it does more than I think it does, I suspect your block should use a FastTESR instead of a TileEntitySpecialRenderer, and in fact, that might make it easier to solve the problem. I think what's happening is that the vertices (and by extension, the quads) aren't being rendered in the correct order. Minecraft sorts the vertices into the correct order under certain conditions, so that transparency looks right, but it doesn't do that for TESRs because it never gets its hands on your BufferBuilder (whereas all FastTESRs share a BufferBuilder within their shared Tessellator). It does, however, sort the FastTESRs' batched vertex buffer, which is why you could make things easier by switching over. If you do end up using a FastTESR, you should opt-in to the vertex-sorting render pass by returning true from TileEntity#shouldRenderInPass() during pass #1 instead of pass #0. Otherwise, you should be able to sort the vertices within the TESR yourself, by using BufferBuilder#sortVertexData(), passing in the (x, y, z) coordinates of the player's eyeballs.

Which is the part you don't understand? For a general overview of the process, I'm sure there are numerous online sources, which is why we prefer specific questions or clarifications here. Edit: I just realized this is in the wrong Forum. You should be posting modding help requests in the Modder Support forum, not the Suggestions one. Suggestions is for new Forge features.

You can export Blender models in .obj format, and use .obj models for your item, as explained in this post.

You can get the Entity that caused the death by using livingDeathEventObject.getSource().getTrueSource(), and go from there.

Problematic Code #1, Code Style #1, #2, #3, #4 Your chests aren't instances of IHasModel, so their Item models aren't being registered. (It's almost like IHasModel is useless because all Blocks and Items need models!) Even if they were, you've commented out the registerModels code in the copper chest anyways, which probably wouldn't help matters. Edit: You'll also have a rather brown-looking iron chest, since you just copied the copper chest's Json over to the iron one.

There's an extra comma in the line above (meaning in line 6) which makes the compiler expect another entry to be on line 7, where there isn't one. You should get a JSON checking plugin for Eclipse, or use an online one, since these sorts of things crop up every now and then and are generally tedious to find.

For the damage, you can check/set the ItemStack's damage with ItemStack#getDamage() and ItemStack#setDamage(). For the inventory searching, you can get the player's inventory through the EntityPlayer object, use that to check for the ender pearls, and get an ItemStack of them to interact with and change.

Fabulous! That was it, the frustum check is now properly ignored. Thanks a bunch. Having played around with it for a while now, that was definitely the major issue of the two, so having it fixed is a huge improvement.