tofer17

Agree. Have you looked at MinecraftForge.EVENT_BUS ? Most mods add features/behavior rather than altering vanilla code. Imagine what happens when your mod mangles vanilla functionality and then what happens with the rest of our mods?

Have you tried world.getStrongestIndirectPower(x,y,z) > 0 ? The "isIndirectly..." method doesn't always work as intuitively as you (or, rather I) might think.

In my experiences I've seen other mods that create their own versions of those things. For example "MyBoat" which extends the vanilla class and/or whatnot except that it drops as you desire. There are implications about how it gets crafted and so forth, I guess. Alternatively, I just started playing with it, you can investigate "MinecraftForge.EVENT_BUS" and perhaps there's an event you can listen for and, to it, respond as you desire when the situation merits. Were I you I would steer clear of overriding the base Minecraft code since who knows when/if/what will change from release to release. IMO, that's not the way to go and is, in fact, what Forge helps establish (that is, a means to make mods work release to release as much as possible with less impact). I am not sure if that helps except to provide some avenues to explore, and maybe others have better ideas, too

Playing around in net.minecraft.client.renderer.EntityRenderer I found, in the renderWorld(...) method: ForgeHooksClient.dispatchRenderLast(renderglobal, p_78471_1_); Which lead me on to register (and @SubscribeEvent ) a class to onRenderLastEvent(RenderWorldLastEvent event) . That method: [*]Fetches all of my TileEntities into a list [*]For each, computes its distance to the player [*]Sorts the list farthest first to nearest last (the AlphaTileEntity class implements Comparable ) [*]Then renders each in that order And it works without needing a TESR at all. Ideally I should check if the TileEntity is in view, but I skipped that for now. Before I paste in the code I'll demonstrate the effect seen using the TESR and without (via RenderWorldLastEvent). Using a TESR: Via RenderWorldLastEvent: Following are my classes (I simply altered the value of oldSchool in the ModBase class to affect usage of the TESR or not). AlphaRenderer (the TESR): And AlphaRenderLastEventHandler And there you have it!

Well hooray, I've simplified the problem into a reproducible study! But not so much. The issue persists. I've simplified my project into a set of 7 classes (OK, well, I detest that CommonProxy gets annotated as "serverSide" and "clientSide" is "ClientProxy" so the extra class is "AbstractProxy" of which "ClientProxy" and "ServerProxy" extend); nest 'em? nah. And I would prefer to utilize an Interface for shared values but, for this simplification, it's OK and they're just stuck in the mod's core class. I will digress about "par1" all over the place and truly go over the edge regarding line-placement of opening and closing, "{" and "}," brackets. It's "x" it's not "par1" or "var1" or whatever. And no, I have not turned my computer off and then on again. My ambition is to a) figure out Git Hub, b) commit this study there, c) mutate it so there are two blocks: the first that doesn't render correctly to showcase this issue (and that's what I have right now), and second to path-find this notion of a trailing renderator (prefer "executrix" at this point for dead folk like me at this point) in order to properly render the second-kind-a-block. But not until Monday. And besides codes, I'll post screen shots of the issue. BTW, hadn't mentioned this, but I'm using "forgeSrc-1.7.10-10.13.0.1180.jar" and no other mods than this one; in Eclipse Kepler SR2. My windows-8-pro computer has 8 logical i7 processors @ 3ghz, 16gb ram, small ssd drive , and a wicked graphics adapter .

@TGG: Hey, all that got me thinking (thank-you) and as I was experimenting with face-render-order I discovered a few things. I found your post about order-independent rendering especially helpful even though it didn't help in my situation. First: I think you are correct that TESRs don't render in the 0/1 passes but after. I know this because I was enabling Depth-writing since it brought up another issue I wasn't worried about right now. But, I fixed it so that my block rendered in pass-0, and then disabled depth-writes in the TESR and it is no longer an issue! Yet, and here's the thing: a vanilla sign (that uses a TESR) doesn't get alpha-blended. (*, see following) Secondly: sadly, the face rendering order didn't pay off and I tried numerous combinations. It's easy to draw the faces farthest-first. But, and we all have a big one, how am I to render the farther-block's faces when Minecraft decides to stimulate the nearer TESR first and the next farther second? Culling seems not to be the issue. (**) Thirdly (and *): launching Minecraft and looking through the nearest transparent block (of mine) at a sign: the sign is not colored at all. Scooting over and looking through another transparent block (of mine), however, does correctly render the sign colored. I tried many various glBlendFunction's to no avail and even came across this interesting site: http://www.andersriggelsen.dk/glblendfunc.php (you gott'a love the death star). Fourthly if you are still keeping count: I'm starting to think I need my TESRs when invoked to renderTileEntityAt -> to message to a singleton of this. Once the singleton figures that all of the rellevant TESRs have signaled, then it computes transparency order and has each render in the proper order. But, geeze. That sounds like reinventing the wheel! Fifthly: to determine the player's view bearing-- which way the player is looking-- I need to interrogate the differences between the player's X:Y:Z and the X:Y:Z provided in the renderTileEntityAt call. Or is there a simpler method like, dunn'o, "public static Vec3 PlayerHelper.playerIsLookingTowards()"? it's another case of reinventing the wheel and so be it if so. Unless something is obvious, I think I'm going to have to reproduce the effect in simplified code/classes. It may just be a limitation in Minecraft. So: why aren't beacon-beams transparent? Oh, but they DO use some alpha-blending (32/255).. ** PS: I'm using culling simply because I like the effect better. I can disable it all the same. But I still have all these issues with it on or off. -- Chris.

Being new here... but, why not use separate images? The trade-off being of course having to maintain that image flipped around in different ways AND the client having to load multiple copies of what otherwise can be handled (as previously mentioned) with simplistic UV manipulation. I do think the UV approach more elegant because you can also play with other factors such as scaling and normals but i digress (UV is how I would do it-- can be just darn confusing).

I have a TileEntity that employs its own TileEntitySpecialRenderer. I'm using the Tessellator out of convenience, and settinng various Gl-caps-- especially a texture with alpha values between 0.0 and 1.0. It's a little bit crazy to explain the problem so just imagine a simple block whose 6 faces are all a single 16x16 of 1:1:1 RGB texture at 0.5 alpha. Now imagine that there are two of these buggers in the world at head height and arranged like so "R-B" where "R" is this block and it happens to be Red ( tessellator.setColorRGBA_F(1.0f, 0.0f, 0.0f, 1.0f) ), "-" is air, and "B" is another TileEntity instance other than the fact that it knows to be Blue. You are looking directly at "R" and so "-B" are behind it in that order. However, what I am experiencing is that, depending on the order of placement, and/or the order the entities are loaded (it seems), one might or might not see the Blue block. And then, usually if you swing around and look at things the other way (as in, "R-B" -swing around-> "B-R") then, through the Blue block you can see the Red block (which is the correct result). And, moreover, if you look such that you can see both blocks in your field of view (e.g., fly 10m over 'em both and look down) then BOTH render just fine and as expected. What gives... why is this? Here are my caps I am enabling/disabling: GL11.glDisable(GL11.GL_LIGHTING); GL11.glEnable(GL11.GL_CULL_FACE); GL11.glDisable(GL11.GL_ALPHA_TEST); GL11.glEnable(GL11.GL_BLEND); GL11.glEnable(GL11.GL_DEPTH_TEST); GL11.glAlphaFunc(GL11.GL_GREATER, 0.1f); GL11.glDepthMask(true); I've tinkered with all of those (enabling/disabling/trying differing values) but the results never align with my needs. I've also tinkered with Block.getRenderPass() and Block.canRenderInPass(int pass) methods and-- they have impact but no combination of settings appears to work properly. FWIW, My tessellator logic draws 8 quads per face (e.g., CW then CCW). User right-clicks the block with Dye-in-hand to change the color (and this works); color is saved/loaded via NBT and tile-updates (works great). The real issue is the weird alpha occlusion behavior. It's like, I want the TESRs to render in reverse order of how MineCraft decides to. And. To make matters worse: I have another TileEntity (call it "X") with its own TESR and, guess what? Sometimes you can see it "through" the "R" or "B" block; and other times you cannot (yet it renders by itself just fine all other times). Does MineCraft's rendering engine have issues relating to render-order and how can I control or give hints to the engine to render "R" and "B" blocks after rendering "X" blocks (and whatever else)? Thanks!