TheGreyGhost

well, my testing was 'worst case' using a map with a registered entry for every single section name in vanilla, but given how insensitive HashMaps are to scaling I don't think it would improve much even if there were only a few sections registered. Wouldn't be a problem if vanilla didn't call the section so many times, some of them 10,000 times per second... But anyway, so far I've always managed to find a suitable way to insert into vanilla, without ASM even, so it's no big deal :-) -TGG

Hi I'm not sure what effect you're talking about - do you mean the cracks? RenderGlobal:: public void drawBlockDamageTexture(Tessellator par1Tessellator, EntityLivingBase par2EntityPlayer, float par3) or the flying fragments when the block bursts? EntityDiggingFX -TGG

Well I must admit I was skeptical but I tested it and you are right, it does make a measurable difference. On my 4-year-old laptop, 36 seconds of gameplay resulted in 8.7 million calls to startSection with a total cost of 0.45 s for the hashmap get and null comparisons. That's about 1% overhead which is not a lot but is probably not worth it. -TGG

True, and the reason I don't think that matters is because the vanilla code still makes the call to startSection even if profiling is off? That's true, and very often that doesn't matter because you can access what you need through Minecraft and other singletons, especially on the client. If there's a suitable Forge event, that's obviously much better. But if there isn't, then why not use all these pseudo-events scattered throughout vanilla, which you essentially get for free? -TGG

{forehead slap} http://www.minecraftforum.net/topic/1881638-animation-in-resource-packs-a-minecraft-16-tutorial/ oops! -TGG

Hi I haven't used TileEntitySpecialRenderer in 1.7.2 yet, but the symptoms suggest your call to bindTileEntitySpecialRenderer isn't happening for the glass bottle, for some reason? breakpoints might help you figure it out again, in ClientRegistry:: public static void bindTileEntitySpecialRenderer(Class <? extends TileEntity> tileEntityClass, TileEntitySpecialRenderer specialRenderer) to check you are registering your bottle properly, and and TileEntityRenderGlassBottle.renderTileEntityAt(...) to let you trace through into TileEntitySpecialRenderer.bindTexture -TGG

Hi Do you have your code on GitHub or similar? If so, I could download and run it with my profiler to see if it helps. (Will take a few days, I have limited time at the moment) -TGG

Hi This link might help, it worked for 1.6.4 and might still be valid (not sure) -TGG

Howdy I had an idea the other day while browsing through vanilla looking for a suitable hook. Perhaps Profiler.endStartSection() could be modified to act as an event handler. For example, if I want to intercept the vanilla code flow so that I change the renderer settings immediately before rendering terrain this.mc.mcProfiler.endStartSection("prepareterrain"); this.setupFog(0, partialTick); GL11.glEnable(GL11.GL_FOG); this.mc.getTextureManager().bindTexture(TextureMap.locationBlocksTexture); RenderHelper.disableStandardItemLighting(); this.mc.mcProfiler.endStartSection("terrain"); // want to intercept here renderglobal.sortAndRender(entitylivingbase, 0, (double)partialTick); GL11.glShadeModel(GL11.GL_FLAT); EntityPlayer entityplayer; I have previously called Profiler.registerListener("terrain", myListenerObject); so that the call to this.mc.mcProfiler.endStartSection("terrain"); does something like IProfilerListener listener = listenerHashMap.get(sectionString); if (listener != null) listener.eventOccurred(); I can't imagine no-one has thought of it before, but I couldn't find anything similar in the forums, and I'm not sure why, since it would be almost trivial to implement and I can't see any obvious drawbacks? -TGG

Hi If you only want to dual texture for your custom blocks, you can just use an ISimpleBlockRenderingHandler and do whatever rendering you want. If you're worried about flipping back and forth between different textures, you could register multiple icons for your block and just change the texture coordinates between each one? You realise that Blocks are already rendered with 3 textures? Perhaps you can hijack pass1 for what you want to do? pass 0 (alpha blend off) pass 1 (alpha blend on) and multitexturing (lightmap)? Failing that, you could use a technique called ASM/reflection to insert calls to your rendering pass at the appropriate parts in the code. To be honest I don't know if the events you mentioned will give you control at the right spot, but I haven't found anything suitable previously. -TGG

Fair enough :-) Glad you figured it out! -TGG

hi Sorry dude, nothing leaps out at me. It sure is spending a lot of time doing lighting updates, but that's not unusual and vanilla normally "paces itself" to stop it causing game slowdown. And recheckGaps checkedPosition < toCheckCount doesn't actually seem to be taking much time at all. Those error messages [14:14:25] [Client thread/WARN]: Something's taking too long! 'root.tick.level.chunkCache' took aprox 286.612826 ms are a bit of a mystery to me too. It looks to me like the chunkCache for client side only calls this.clientChunkProvider.unloadQueuedChunks(); which should return false immediately, so I don't understand what's happening there. Unless you have accidentally replaced it with something that takes a lot of time? Could perhaps be related to garbage collection, if your world generation is creating and abandoning a large number of objects. In the absence of any better ideas, you could perhaps try removing parts of your code until the problem goes away - process of elimination. Unfortunately I'm stumped, sorry! -TGG

Keen :-) Perhaps what is happening is that nothing nearby is triggering a lighting update. Vanilla is very careful to only update lighting when it has to, and even then it does it pseudo-randomly over a long period of time, to avoid overwhelming the game with calculations. I think you probably don't want to use scheduleBlockUpdateWithPriority; to get rid of the light, you might be better to try .updateAllLightTypes(x, y, z); -TGG

Hi In single player I think you could manage this ok, but multiplayer would be a problem unless, when one player scopes a rifle, all other players see the game move at half speed. If you're willing to accept that, then I think you could probably make the game run at half speed if you mess around with Minecraft.timer; it is set to 20 ticks per second, you could make it 10 instead using a technique called ASM + Reflection. Likewise for the server side; MinecraftServer.run() there is a value you could change the same way. while (j > 50L) { j -= 50L; this.tick(); } No guarantee it would work but for single player only it might be fun to try and see... -TGG

Tried it but nothing changed. Are you sure? [22:46:14] [Client thread/ERROR]: Using missing texture, unable to load minecraft:textures/blocks/MISSING_ICON_BLOCK_168_blockGlassBottle.png This error message showed me that your block texture name hasn't been set correctly, and that vanilla is calling registerIcon on your behalf but is using the missing name. Are you sure the error message hasn't changed? If the error message is still the same, and if you know how to use your debugger, you could add a breakpoint to the following Block method: @SideOnly(Side.CLIENT) protected String getTextureName() { return this.textureName == null ? "MISSING_ICON_BLOCK_" + getIdFromBlock(this) + "_" + this.unlocalizedName : this.textureName; } That should show you pretty quick why the name isn't what you expect. -TGG

Hi Try putting a setBlockTextureName() in your block's constructor, or alternatively override registerBlockIcons() -TGG

Hi I don't think that will help you because the lightBrightnessTable is used to scale the brightness of both the sky light and the block light (from torches). If you multiply the returned value by (say) 0.5, I think everything will get darker, not just the sky contribution. (See EntityRenderer.updateLightMap) FYI some background reading on lighting: http://greyminecraftcoder.blogspot.com.au/2013/08/lighting.html I think you would probably need to change World.getSunBrightness method - unfortunately I can't think of any easy way to do it except for ASM. EntityRenderer.updateLightMap would also be a suitable place. Another possibility might be to create a derived class of WorldClient, and override getSunBrightness with your own method which returns a lower brightness. You would need to overwrite Minecraft.theWorld with your own derived class. I have done something similar before but there's no guarantee it would work. It gets difficult because you need to intercept the creation of WorldClient to create your derived class instead. Can get very messy very quickly. public class MyWorldClient extends WorldClient { @Override public float getSunBrightness(float par1) { final float MAXIMUM_LIGHT_FACTOR = 0.5; return MAXIMUM_LIGHT_FACTOR * super.getSunBrightness(par1); } } -TGG

Hi Try IPlayerTracker in 1.6.4 and GameRegistry.registerPlayerTracker for tracking players – login, logout, respawn, dimension change. -TGG

Hi Unfortunately I think what you're planning will almost certainly not work the way you have in mind. You mean this.worldObj.setLightValue, yes? Here is some background information about how block and sky lighting works http://greyminecraftcoder.blogspot.com.au/2013/08/lighting.html Torches and other blocks can give off light. But as far as I know, Entities can't, unless you're willing to overwrite the lightmap for all nearby blocks every time the entity moves, and somehow stop the vanilla code from changing it back. -TGG

Hi That's because rayTrace only looks for block collision. The vanilla code in getMouseOver then goes on to see whether the ray hits any entities before it hits the block. -TGG Reproduced here for your convenience: :-)

Ha, epic targeting fail on my part then :-) The bit masks are hard coded inside the AITask constructors, for example public EntityAISit(EntityTameable par1EntityTameable) { this.theEntity = par1EntityTameable; this.setMutexBits(5); } public EntityAISwimming(EntityLiving par1EntityLiving) { this.theEntity = par1EntityLiving; this.setMutexBits(4); } The bits are associated with a mutually exclusive activity of some kind, they don't uniquely identify classes or AITasks. When the vanilla tries to execute a task, in EntityAITasks.canUse, it checks whether the task is compatible with all other currently executing tasks, based on the activities that each task performs. So yes, if you don't want your task to execute at the same time as a particular activity, then set your task's mutex bit for that activity. The trick is - I'm not sure what "activity" each bit means. It would be an interesting exercise to group the different AI tasks and see what "activity" each mutex bit corresponds to. There aren't many of them. -TGG

Hi Sounds like you just want to ignore a click if it's too soon after a previous one. You need to be able to tell when the gun was last fired. If you have a global tick counter in your code somewhere, you could refer to that. For example fireMyGun() { lastTickFired = MyMod.getGlobalTickCount(); } void tryToFireGun() { int tickNow = MyMod.getGlobalTickCount(); int ticksSinceLastFired = tickNow - lastTickFired; assert ticksSinceLastFired >= 0; if (ticksSinceLastFire > MINIMUM_FIRING_DELAY) { fireMyGun() } -TGG

Hi Just to make sure - are you familiar with the concepts of bit masking? You mention an "index" several times but the number is not an index, it is several "flags" compressed into a single number. The flags are powers of two and you can combine them to make a bitMask, eg combining the flags 1, 2, 8, 32 you get 43. This 43 is not an index. https://aseba.wikidot.com/forum/t-637303/bit-masking-with-binary-operators http://www.computerscienceforeveryone.com/Course_1/Unit_12/Lesson_6/ For example Let's say I can run and jump at the same time, and I can walk and jump at the same time, but I can't walk and run at the same time. I can only crawl if I'm not walking, running, or jumping Our mutex flags might be run/walk/crawl = 1 jump/crawl = 2 So the mutexBits for each task are run = 1 walk = 1 jump = 2 crawl = 1 + 2 = 3 run and walk = 1 and 1 = 1 -> fail run and jump = 1 and 2 = 0 -> ok crawl and run = 3 and 1 = 1 -> fail crawl and jump = 3 and 2 = 2 -> fail -TGG

Hi Vanilla changes the icon depending on the graphics level. One has transparency, the other doesn't. Also shouldSideBeRendered and isOpaque cube, to stop the "inside" of the foliage being rendered unnecessarily Take a look at this code from 1.6.4 BlockLeavesBase:: /** * Returns true if the given side of this block type should be rendered, if the adjacent block is at the given * coordinates. Args: blockAccess, x, y, z, side */ public boolean shouldSideBeRendered(IBlockAccess par1IBlockAccess, int par2, int par3, int par4, int par5) { int i1 = par1IBlockAccess.getBlockId(par2, par3, par4); return !this.graphicsLevel && i1 == this.blockID ? false : super.shouldSideBeRendered(par1IBlockAccess, par2, par3, par4, par5); } BlockLeaves:: private int iconType; /** 1 for fast graphic. 0 for fancy graphics. used in iconArray. */ private Icon[][] iconArray = new Icon[2][]; public static final String[][] field_94396_b = new String[][] {{"leaves_oak", "leaves_spruce", "leaves_birch", "leaves_jungle"}, {"leaves_oak_opaque", "leaves_spruce_opaque", "leaves_birch_opaque", "leaves_jungle_opaque"}}; /** * Is this block (a) opaque and (b) a full 1m cube? This determines whether or not to render the shared face of two * adjacent blocks and also whether the player can attach torches, redstone wire, etc to this block. */ public boolean isOpaqueCube() { return !this.graphicsLevel; } /** * From the specified side and block metadata retrieves the blocks texture. Args: side, metadata */ public Icon getIcon(int par1, int par2) { return (par2 & 3) == 1 ? this.iconArray[this.iconType][1] : ((par2 & 3) == 3 ? this.iconArray[this.iconType][3] : ((par2 & 3) == 2 ? this.iconArray[this.iconType][2] : this.iconArray[this.iconType][0])); } -TGG

Hi I have had the same problem with textures which are parallel and on top of each other; it was caused by small roundoff errors determining which of the two textures is "in front" of the other one. If you have depth culling on, the render order doesn't matter unless you're doing alpha blending. You can fix it by moving one of the textures slightly in front of the other one by a very small amount (i.e. by not trying to overlap them, leaving a very small gap instead). -TGG