Purplicious_Cow

Yes... but I could put in a counter and have it check less frequently for the items that don't need constant attention. I'll test on a couple of items and see what it saves in cycles. Thx.

Sure. Here's a typical example in my PlayerTickHandler. The structure is repeated several times (for several different items) within other Handlers and within the ItemUpdate. This is the only way I've found to get it to work (verifying if the item is in the hotbar first using a loop, and then acting upon it). if (event.entity instanceof EntityPlayer) { EntityPlayer entityplayer = (EntityPlayer) event.entity; for(int i = 0; i <= 8; i++) { ItemStack itemchk = entityplayer.inventory.getStackInSlot(i); if (itemchk != null && itemchk.getItem() == InventoryPets.petSpider && itemchk.getItemDamage() == 0) { //do magic stuff break; } } First question: Is there a more efficient way to verify the existence of an item in the hotbar? It seems a waste to constantly check the hotbar using a loop. Second question: For PlayerTickHandler, would it be more efficient to put a check of the entire hotbar first for any Items up front, and then execute on a case by case basis depending on what items are found, instead of checking one by one? (Just thought of this...) For the record, the PlayerTickHandler is only used where absolutely necessary, most abilities/effects are handled in Item onUpdate.

Very few blocks. And they only spawn in the four dungeons. No tile entities and block texture is small. The mod is all about the items.

Ok, getting more specific: @delpi, I don't have many packets, but I do have lots of loops. @diesieben07, my mod appears to be causing some Block Lag for users when running on a Cauldron Server in a large modpack with high usage. Never been in this position before, so trying to identify the source. I will focus on streamlining some of the loops in the handlers as a first effort. I'm using several handlers and several events: LivingUpdateEvent LivingHurtEvent (several here) BreakSpeed HarvestDropsEvent LivingDropsEvent And a few other minor events, which are only called occasionally. If I learn anything, will post it back here.

Do any of our illustrious moderators or fellow modders have some basic suggestions on performance optimizations? Especially when it comes to particularly sensitive areas such as Structure Generation, Player Tick, and other Event Handlers, onUpdates in Items/Blocks. Basically, a list of common mistakes to avoid. Seems like something that many modders could benefit from.

Exactly. But it does not. That was the original conundrum and why I was so confused. There are no problems with vanilla. And with hundreds of thousands of gameplays at this point, and hours of testing these last 3 months, I am pretty confident in that statement. You can download version 1.1.2a and see for yourself. There were no reports of any issues of Furnace Pet until it started getting added to modpacks and users began to try it on other mods' ores. So, what makes Vanilla recipes immune to poor ItemStack implementation? Now it's your turn to do some digging . Or not. K

Question, though, why would this only be a problem with other mods recipes and not vanilla? Can you explain that one? That still mystifies me.

Yep. That was it. Tested on multiple mods & ores. I had no idea that copying the ItemStack would make a difference. No longer need to set stackSize manually. Cheers, diesieben07

Ah, thought you were talking about the other ItemStack: new ItemStack(itemstack.getItem(), 1, 0). Will try again and respond back.

Ok, I played around a bit more. There were two problems. Changing the way the ItemStack was instantiated did fix identification of the right smelting result from other mods (pulling the correct NBT). So, on that part you were right. However, custom smelting results were not bringing in a stackSize (stackSize was 0). For some reason, vanilla results are showing a stackSize, but custom results from other mods are showing stackSize of zero. If I'd made a custom furnace I would have used mergeItemStack which would have handled the addition of items to your inventory without using the stackSize from the recipe result. Smelting results from the Furnace are always a stackSize of 1. Anyway, to fix it, I set the stackSize manually. Updated code: ItemStack itemstack = FurnaceRecipes.smelting().getSmeltingResult(s2); if (itemstack != null) { itemstack.stackSize = 1; entityplayer.inventory.addItemStackToInventory(itemstack); s2.stackSize--; if (s2.stackSize == 0) { removeItem(entityplayer, s2); } cookedFlag = true; } Thanks for the help, and thanks for pushing me to look deeper.

Yes, you are right of course, but it didn't make a difference, still outputting paper. I doubt this will ever come up again, but thought might be interesting to chew on. And thanks

Ok, this is bizarre, but I'm sure there's a logical explanation (?). One of the Items in our mod acts as a Furnace, but cannot seem to smelt ores and other smeltable items from other mods. Vanilla Minecraft is fine, but all other mods items it turns into Paper (or if I install more mods, some other random Item). There is nothing fancy in the code. The only major difference I can see is that 'getSmeltingResults' is being called from an Item and not from a Container. Item Code: ItemStack itemstack = FurnaceRecipes.smelting().getSmeltingResult(s2); entityplayer.inventory.addItemStackToInventory(new ItemStack(itemstack.getItem(), 1, 0)); When I print the variables to the screen (the other mod's Smelting Results), they show just fine. But when I addItemStackToInventory or even dropItem, it makes paper. However, if I change the second line to Spawn an EntityItem, it works fine (e.g.): Entity entity = new EntityItem(worldObj, entityplayer.posX, entityplayer.posY, entityplayer.posZ, itemstack); worldObj.spawnEntityInWorld(entity); I am imagining that this is because the Item I am pretending is a Furnace is not able to access the items from other mods? Of course, it could be that I am just being stupid (there is some evidence to support this). Can one of our brave moderators explain this behavior?

Thanks, Lex. Think I'm ok. The OreDictionary lookup will only occur when the pet needs to eat, so thousands of ticks apart. But good to know and will keep it mind..... For anyone interested in the solution I went with, I took it straight from the OreDictionary methods, as diesieben07 suggested. After checking if timing and other conditions are right, loop through the player inventory, using OreDictionary.getOres and OreDictionary.itemMatches Thanks, both.

For some reason, I did not think of OreDictionary as a class with methods. I thought of it as a mysterious black box full of mystery and intrigue. Not kidding. Thanks, as always, diesieben07.

Ok, I feel the answer to this is probably no, but I thought I'd ask anyway. Is there a way to access the like items from OreDictionary (outside of recipes)? I want to be able to loop through the inventory and check items against an OreDictionary item. Any suggestions welcome.

For anyone who faced the same issue around multi-slot NEI plugins, I found some clues from heldplayer's MystNEI-Plugin on GitHub, for Mystcraft's InkMixer: https://github.com/heldplayer/MystNEI-Plugin/tree/master/src/main/java/me/heldplayer/plugins/nei/mystcraft/client Hope that proves helpful to someone. K

Zero replies, so sad. Trying again

Looking for a good tutorial or github example implementation for an NEI Plugin for a multi-slot custom machine (3 input slots / 2 output slots). I've got the standard vanilla NEI customizations covered, just a couple special cases. Any suggestions appreciated. Kirok

Thanks Romejanic & diesieben07. I was racking my brain trying to figure out why it was still calling the client side, even with multiple client-side only checks in both classes. Putting it in the proxy did the trick + checking to see if worldObj.isRemote == true.

Sweet mother of Herobrine, that did the trick. Thank you for sharing, as I was about to declare 1.7.10 unfit for custom dimensions. All client ticking lag is gone (along with console messages). I wasn't even using sky, I'm really not sure what the code was doing in the background besides sucking up valuable cycles. Agree this should be fixed, as I have designs on modding the Sky in the next dimension.

Any updates or workarounds on this one, Eternaldoom? I'm experiencing the same thing in our custom dimension. Average ticking is 200ms behind.

Share the code you are having problems with. You seem to have two issues? 1) creating the actual potion item itself (are you having problems with the Potion class?) 2) something to do with 'adds all the potions to my creative tab'. Not sure what that means....

Ok, we just launched our mod about a week ago on v1.6.4 (yeah, I know) and (yippee!). Wondering if it makes sense to skip 1.7.2 altogether and go straight for 1.7.10? It's a tech mod with new armor/mobs/dimension. Is there enough of a user/modpack community to justify a 1.7.2 release? What are people's opinions? Capn_Kirok

Ok. I was not able to get PlayBackgroundMusicEvent to work either, so I tried a completely different method. The real problem here is the inability to thread sounds in 1.6.4. This is only an issue if you have a lot of sounds happening at the same time, and hurts in particular if you have a long sound (like 120 seconds of boss music). So, to fix it, I broke the song up into multiple parts of about 2-4 seconds each (there are many repeats), and timed them to play one after another using the 20 ticks/second rule. In other words, I just threaded it myself. This was also helpful in making sure the music ended when the boss died. It helped that the song was in an easily translated meter and had natural breaks. Looking forward to seeing how the sound engine is improved in 1.7.2. Cap'n Kirok

Thanks, I'll take a look. Yes, need to update. Want to get 1.6.4 out first