Reika

Yes, because it already started drawing. What you need to do is stop drawing and then start drawing again for your rendering. When done, and you stopped your drawing, start drawing again for the renderers internal "draw-stop" I used to use this, but as of 1.7.10, this crashes.

I am having a problem with my ISBRH (ISimpleBlockRenderingHandler) pipe renders, in that the alpha of the liquid inside visibly flickers between two values as the camera moves, leading to a very broken appearance. The liquid renders on pass 1, while the body of the pipe (which is rendering fine) renders on pass 0. I have checked for things like multiple calls, lighting, blend mode, and everything else I can think of, and nothing has worked. I used to have the Tessellator "reboot" with a .draw() and .startDrawingQuads() before doing my rendering (and doing it again after), and did not experience the issue. As of 1.7, however, the rewrites to the tessellator mean that such an approach immediately crashes: Removing the .draw() and .startDrawing() calls fixes the crash, but introduces the alpha problems. Any ideas? My code: @Override public boolean renderWorldBlock(IBlockAccess world, int x, int y, int z, Block block, int modelId, RenderBlocks renderer) { RenderableDuct tile = (RenderableDuct)world.getTileEntity(x, y, z); for (int i = 0; i < 6; i++) { if (renderPass == 0) this.renderFace(tile, world, x, y, z, dirs[i]); else { //Icon ico = tile.getOverlayIcon(); //if (ico != null) //this.renderOverlay(tile, world, x, y, z, dirs[i], ico); if (tile.isFluidPipe()) { this.renderLiquid(tile, x, y, z, dirs[i]); } } } return true; } private void renderLiquid(RenderableDuct tile, int x, int y, int z, ForgeDirection dir) { Fluid f = tile.getFluidType(); if (f == null) return; Tessellator v5 = Tessellator.instance; //v5.draw(); float size = 0.75F/2F; float window = 0.5F/2F; float dl = size-window; float dd = 0.5F-size; double in = 0.5+size-0.01; double in2 = 0.5-size+0.01; double dd2 = in-in2; IIcon ico = f.getIcon(); float u = ico.getMinU(); float v = ico.getMinV(); float u2 = ico.getMaxU(); float v2 = ico.getMaxV(); double du = dd2*(u2-u)/4D; GL11.glColor4f(1, 1, 1, 1); GL11.glEnable(GL11.GL_BLEND); GL11.glEnable(GL11.GL_CULL_FACE); GL11.glEnable(GL12.GL_RESCALE_NORMAL); //v5.startDrawingQuads(); v5.addTranslation(x, y, z); int mix = tile.getPipeBlockType().getMixedBrightnessForBlock(Minecraft.getMinecraft().theWorld, x, y, z); ReikaLiquidRenderer.bindFluidTexture(f); v5.setColorOpaque(255, 255, 255); if (f.getLuminosity() > 0) { v5.setBrightness(240); //ReikaRenderHelper.disableLighting(); } else { v5.setBrightness(mix); } v5.setNormal(dir.offsetX, -dir.offsetY, -dir.offsetZ); --- lots of .addVertexWithUV --- v5.addTranslation(-x, -y, -z); //v5.draw(); GL11.glDisable(GL11.GL_CULL_FACE); //v5.startDrawingQuads(); //GL11.glEnable(GL11.GL_BLEND); //GL11.glEnable(GL12.GL_RESCALE_NORMAL); Sample images:

I used access transformers for the first time today to avoid the need to reflectively call or set fields or methods, to avoid the performance overhead of reflection (as the code is called very frequently). This became a problem when changing an EntityLivingBase method (dropFewItems(ZI)V) from protected to public. When running the gradle script, I was spammed with errors as it tried to apply my changes, as the subclasses of EntityLivingBase all override that method and keep it as protected. Since a protected field cannot override a public one ("cannot reduce visibility" error), this is not unexpected, but poses a serious problem: Even if I were to patch all of the vanilla entity classes to use the method as public, what happens with mods, who likely also override the method and keep it protected? Is there some handler in Forge to fix this and avoid a crash, or to change the visibility for all subclasses of a given class?

And if the player is not logged in?

In the process of updating my mods to 1.7, I have run into two barriers with the changes to the FakePlayer class. Both of these stem from the fact the get() function now requires WorldServer, GameProfile instead of the previous World, String. What this then means is that in the cases where I only have the string name of the player, or wish to get a FakePlayer clientside, I have no means to do so. How would I do this?

No, what I'm saying is that for functions you figure out you can make a method in your own class that calls the other method. Like this: public void markBlockForRenderUpdate(int parX, int parY, int parZ) { World.func_147479_m(parX, parY, parZ); } It is still bit of a pain, but can help improve the readability and might save you some headache for those methods you use a lot. Clever. I like that. I am actually going to do it whether or not functions get renamed, because by "funneling" all my calls through something I control I can reduce the amount of changes needed from update to update.

The problem is, if I submit a name, if it goes through at all - something my experience has taught me is unlikely - that it will have to wait until a new MCP build, something which may well not happen again until a new MC version comes out. Given that said version will be MC 1.8, there is no point in trying to get further 1.7 updates. That would work if it was my own class, yes. The problem is where I am calling functions, like in the world class, which happens to be where my worst problems are. By the way, markBlockForRenderUpdate is now func_147479_m.

Normally, yes, but the problem here is that there are, depending on the class, dozens or hundreds of methods with SRG names that are not readily distinguishable. A line-by-line search could probably do it, but that is so time-consuming and inefficient it would be better just to wait until more code is given proper names. The problem is compounded by the naming of all the arguments as p_*, because that makes everything "look" the same as each other and unlike their 1.6 counterparts, and greatly stifles at-a-glance comparisons. I have had to do it too, but it was always "backwater" code like obscure parts of the render engine or chunk provider stuff. Now it is in what I call frontline code; furnace recipes, common world operations (markBlockForRenderUpdate being the most recently discovered example), various entity methods and fields... Some, like EntityFallingBlock, have literally every field as an SRG name. Other classes do the same with their methods. This is actually another case where I would like to be able to edit the source; that way, as I work out names and fields, I can rename them as needed. I could also fix the p_ names of the arguments.

1) Those are not obfuscated names those are unique SRG names Fair enough; I misused a term. I realize that, but in past updates, the new names arrived fairly quickly, often within weeks of the update. Forge for 1.7 has been out for months, and the fact that 75% of the code is still unreadable seems very odd to me. I was suspecting that something had gone wrong with the installation. Welcome to minecraft modding, this is just a thing of life. As for not being able to read the source, it is there, you can read it, you just cant MODIFY it. And you can EASILY find references of anything. So, learn to your use IDE better I guess. Half of the way I reverse-engineer this sort of code is by forcing various parameters and testing their effects. This is no longer possible in this version, hence my point. Also, you say "Welcome to modding", but as far as I have experienced, unless you are one of the first mods to update, it is a rather rare occurrence; as mentioned above, I have never before seen this much code still scrambled this late into a version's life, and I have been modding since before the fiasco that was 1.3. We have superior functionality to 1.6, All of the things that were named in 1.6 are still named in 1.7, the things that are GONE are GONE not renamed or anything stupid like that. I am not talking about code, but was again wondering if there was some other repository of updated names and/or a way to edit the source in the dev environment. I understand your disapproval of the latter when used to make mods, but if only done in the developer environment for the sake of debugging, that is not an issue. *notes renforcment of lack of attention to detail.* More like having two adjacent tabs and posting in the wrong one. Simple mistakes are easy to make. If it comes down to it, I may well try hybridizing the MCP and Forge environments, so that I can at least get editable source, allowing me to debug as I see fit. It may well not work, but in lieu of a better approach...

I am trying to port my mods from 1.6.4 to 1.7.10 and have run into a very serious problem: Large swaths of the code are still functionally or even completely obfuscated. The really high-traffic functions have their names set, but their arguments are still things like "p_345983459", and most of the code is still field_this and func_that. I cannot possibly develop when so many of the functions I rely on are unnamed and hidden in a mass of 300+ obfuscated names, and the fact that I can no longer modify the vanilla code to check references and effects of various parameters means I cannot work it out on my own like I used to. I have tried updating to the newest version of Forge, which did not help; is there some way I can get some level of functionality like that which I had in 1.6? EDIT: I just realized that I accidentally posted this in the wrong section. Can a moderator please move it to the correct location? http://www.minecraftforge.net/forum/index.php/board,73.0.html

Render code only runs when the player is looking at something, so optimizing it there will have no effect. I have tried distance LOD modeling, but it was both very noticeable and not particularly helpful. I did do it with thermal and pressure calculations, as that saves a lot of load, but things like the power system (probably one of my biggest load sources), glitches when "stepped".

I do that with some code, but a lot of it is part of a sort of physics engine; if I slowed that down, it would be extremely noticeable.

Yes, I did account for that. 65536 iterations across an empty loop took 295 ns, and I simply subtracted that off. I am doing it this way, though instead of EnumMap I am using TileEntity[6] and accessing it by dir.ordinal(). Given that it takes me only 3 ns to call a function, I think that will work perfectly. Testing confirms this; 65536 calls of getBlockTileEntity, 2.4 ms. 65536 calls of getCachedTE(dir), which fetches from the array, takes less than 80 microseconds. This seems to translate roughly into a 20FPS gain in a singleplayer creative superflat, and should only increase from there. I have seen a lot of that, but had no idea what it was for. Is it as simple as you are implying?

Yes, that is what I did, because the alternative - pooling them - would be even slower. That said, it should be negligible. That explains a lot. HashMap.get() is O(log(n)). Should it really be that big a difference? I do not like how messy an array will be. Block.updateNeighborTile() solves that issue nicely, and my only recently having learned it is why I am only now trying caching. Then why do so many people in high places - including the developer of the mod I have seen called "the leader in optimization" - say otherwise?

The thing is, there is no reason why iterating over a list 16000 entries long should be as fast as a hashmap get, or why there is such a large disconnect between my observations and "accepted knowledge".

I am trying to optimize code in RotaryCraft (for those not familiar, a large tech mod that has a bit of a reputation for being computationally intensive). One of the things that seems like a good start was the repeated calls of getBlockTileEntity(x,y,z), as I have heard that that function is terribly inefficient from a variety of developers, including KingLemming and LexManos. So I set up a caching system using a HashMap<ChunkCoordinates, TileEntity>, to store the six adjacent TileEntities, and update the cache with the Block type's onNeighborTileChange() function. It works as intended, except for one thing: No performance gain. And not because the new system is slow, but because getBlockTileEntity is not. I tested both normal terrain and superflat, and also with a 40x20x40 block of furnaces (to inflate the size of the chunk's loadedTileEntity list). Every time, there was negligible difference between getBlockTileEntity(x,y,z) and fetching the TE from cache. I took some timing data with System.nanoTime(): Base Delay between nanoTime() calls and print: 293 ns Additional Delay to call world.getBlockTileEntity once: ~800ns Additional Delay to call from cache once: ~700ns Additional Delay to call world.getBlockTileEntity 512 times: ~4.4 microseconds Additional Delay to call from cache 512 times: ~6.5 microseconds Additional Delay to call world.getBlockTileEntity 65536 times: ~1.2 milliseconds Additional Delay to call from cache 65536 times: ~1.2 milliseconds I also tried to call it 2M times per tick, but the game froze. Why, however, am I getting these results?

Or, if your PC can handle it, you could just run a dedicated server, a client with "Reika_Kalseki" as username and a client with a random username in Eclipse, connect both clients to the server and see the results. I tried that, and Eclipse tends to crash one of the two clients after a few seconds.

No idea, because they are using modpack-release versions of the mod and thus cannot have system prints.

That was one of the first things I tried. The result was as expected: EntityClientPlayerMP['Reika_Kalseki'/1564, l='MpServer', x=-1148.29, y=8.16, z=-427.23] of class net.minecraft.client.entity.EntityClientPlayerMP

I am trying to render additional pieces onto the player model using the RenderPlayerEvent.Pre event. I basically watch the event and fire the .render() for a custom ModelRenderer class. The render is only supposed to run on me (so only my player entity has a special model). It seemed to work beautifully, until I joined a server and others around me noticed that when I was in their field of view, they too had the special model parts...but rotated to fit the orientation of my player. Needless to say, I would like to fix this, as would everyone else with random floating body parts. Here is the code: @ForgeSubscribe public void addReikaModel(RenderPlayerEvent.Pre evt) { RenderPlayer render = evt.renderer; EntityPlayer ep = evt.entityPlayer; float tick = evt.partialRenderTick; if (ep != null) { if ("Reika_Kalseki".equals(ep.getEntityName())) { //render.setRenderPassModel(modelReika); ReikaTextureHelper.bindFinalTexture(DragonAPICore.class, "/Reika/DragonAPI/Resources/reika_tex.png"); GL11.glScaled(1, -1, 1); GL11.glFrontFace(GL11.GL_CW); modelReika.renderBodyParts(ep, tick); GL11.glFrontFace(GL11.GL_CCW); GL11.glScaled(1, -1, 1); } } } The very weird part is that I am using variable "ep" (the render player instance) to check the name of the player we should be rendering "on", yet somehow the rendering also happens for other players. However, the argument is still actually my player, because the rotation is that of my player entity.

No idea?

I cannot make an implements conditional. And that class needs to exist in "vanilla RotaryCraft" as well.

You misunderstood. If I make a direct reference to a BuildCraft class, my mod becomes dependent on the existence of that class (users without will with crash with NoClassDefFound).

How can I use any of its classes directly without making them required for my mod to compile (and therefore making RotaryCraft dependent on BuildCraft)?

I want to make an interface between my mod's power system and BuildCraft's MJ system. However, I have no idea how to do this. I have dug into other mods' code, but they all seem to hardcode everything, using reflection to fetch classes, then variables, then values. To me, this seems like a stupid idea, as as soon as anything in the target mod changes, I need to rewrite my system. Is there a better way? Note: I need full control over things like conversion ratio and behavior of converting machine. Ideally with my own TileEntity that takes in my power (already done) and produces MJ.