Rohzek

That... is a LONG time... heh... long.. Okay I'm shutting up now. Right thank all of you so much. It's really cool. Here it is in action(Youtube)

Okay, using a PlayerTickEvent items now degrade correctly when in chests. I can either lower the amount of change or just not check at all I guess, if they are in a "fridge". Cool. Now what I have left is the entity item. I see you can just get the itemstack from the entity item so that shouldn't be too hard to just call on onEntityItemUpdate. I'm just not quite sure about one thing.. the method I'm using to get the time (world.getWorldTime()) always seems to return a big number. Does it reset to 0.. like when the next day starts? If not how long before it's too big to be cast as int/long/double or whatever I store it in? If so how does that work with the check.. or am I using the wrong type of time?

Okay so right now... I have it so that 100 ticks after creation the item goes stale.. and 100 ticks after that it goes moldy.. It does this by storing time and data to the ItemStack's TagCompound. I'm not sure where to go from here though, how do I transfer/read that from the entityitem and or detect when items are placed into a container?

So I can get the world time into the NBT on creation with getWorldTime()... Then later get the world time again and say if the new world time is x amount larger than the original... then decay.. That would work for overall decay but what if I wanted to expand/delay the amount of time it takes to decay if it's in a particular container.. or is that just beyond what I can do with Minecraft?

I don't know if this is easily possible, but... Is there anyway to check an item's lifespan while it's in a container, and or get the container it's in assuming the container is in a loaded chunk? The idea would be to make food items that go stale and moldy over a period of time.. and not "age" while in a safe container (like a custom chest... fridge) or in a container with another item (such as ice). Basically: I know I can get the age based on amount of time it spends in a player's inventory and save it to the item's NBT, but is there something similar for general time or time spent in container?

To be honest I probably don't want to remove the Firework recipes.. Too many combos to play with just trying to make it harder.. But it's interesting to know how, thanks. As for the dyes, I made a stupid mistake I wasn't actually USING that method, I was iterating through an itemstack of the dyes and checking each metadata value directly against the itemstack. And similar with the blocks with a for loop and checking each for a recipe which was just fizzling. Just passing the item itself totally works as intended. [03:03:17] [Client thread/INFO] [ANCTECH]: Removed 28 recipes for dyePowder [03:03:17] [Client thread/INFO] [ANCTECH]: Removed 16 recipes for tile.clayHardenedStained.name Thanks again for that too. No telling how long I would have wasted not figuring out that.

Ironically just a few weeks ago now I answered a similar question with the extent of my knowledge on it... However I seem to have a few holes in my method. In a quest to toughen up vanilla recipes I'm using the following method to find and remove crafting recipes so that I can replace them: which works fine for 99.99% of recipes... However it doesn't seem to remove Fireworks, Dyes, or Stained Clay blocks. These seem to just.. not be there. Checking the specific Recipes classes don't seem to help much. Dyes seem to be added to A crafting manager normally... but not the list in CraftingManager I guess... Fireworks don't.. I don't even know where the recipe for stained clay is? Not sure how to find and remove these.

I see. I was wondering how wood handled it's rotation... that makes sense. Thanks

Okay, I'm.. stumped.. I'm making a set of logs to go a long with the vanilla logs which are basically the vanilla logs without bark.. So I've tried extending BlockLog and BlockNewLog.. both of which work the same way.. and overridden the methods and passed in my custom textures and such.. and am being held back by a problem. Oak, Spruce, Birch, and Jungle logs work perfectly but Acacia and Dark Oak aren't working correctly. They're named correctly but the textures are loading from my Oak and Spruce textures, not my acacia and dark oak ones. Going through and printing whats loading in my ItemBlockWithMetadata class and in the registerBlockIcons method both print out the correct things... it's just not working. Do I really have to split logs into two classes like the vanilla code has done? Or am I missing something basic?

You'll want to pull the next ItemStack the remover is looking at out of the recipe list to check, and then check to see if it matches the item you want to remove. ItemStack itemstack = remover.next().getRecipeOutput(); if(itemstack != null && itemstack.getItem() == Items.whatever this item is) { remover.remove(); } You could then expand with more else ifs in the list checking for more items or alternatively you could check for blocks with Item.getItemFromBlock(Blocks.the block to remove). Personally I have it more modularized with: public static void removeCraftingRecipe(Item item) { List<IRecipe> recipes = CraftingManager.getInstance().getRecipeList(); Iterator<IRecipe> remover = recipes.iterator(); while(remover.hasNext()) { ItemStack itemstack = remover.next().getRecipeOutput(); if(itemstack != null && itemstack.getItem() == item) { remover.remove(); } } } So I can just call it per item I want to remove instead of expanding the if statements to include new items

Fair enough mate. I can't actually help you on the config part of things because I haven't played with it, hopefully someone else will come along for that. However if you want to straight up remove recipes you could get an instance of the recipe list from the CraftingManager class and iterate through removing the items you don't want from the list.. Something like this: public static void removeRecipe() { List<IRecipe> recipes = CraftingManager.getInstance().getRecipeList(); Iterator<IRecipe> remover = recipes.iterator(); while(remover.hasNext()) { ItemStack itemStack = remover.next().getRecipeOutput(); // check for items and remove them } }

I don't recommend you disable items completely since another mod may require an item for it's recipe and you would in effect, ruin that mod. But you could do something similar to what IguanaTweaks (or is it base Tinkers Construct?) and make the vanilla tools useless by removing their ability to mine blocks. I'm not entirely sure how it's implemented but you could perhaps subscribe to the ItemCraftedEvent which fires right before an item is created and remove it's damage if it's a vanilla tool.

That is absolutely right. With the loss of item IDs (and the fact that the Item.class docs mention placing blocks with the item) it went invisible and it slipped my mind but.. Thing's like wool and dye are the same item with different textures based on metadata aren't they? That would work beautifully for not only my current issue but any further items with a similar idea. Thank you so much

Apologies for a double post, but I'm not sure anyone would have checked if I just edited the last one, but I wonder.. assuming I found a way to keep the mode change out of the class and only passed it between functions in the ItemStack NBT... Is there any way I could use the number from the ItemStack NBT to change the texture drawn on a specific ItemStack? While damage states would solve my problem this time... I'm thinking if I had something like a pick that I wanted to change texture on right click and didn't have the damage states available.. How would that be done?

This.... is true. And infact the way the class is currently set up it... it just changes all guns in the world at the same time... I... think I have to base the mode off damage states to make it work anyway... Yeah.. Thanks for pointing me in the right direction.

That's what I thought. Shame there isn't anywhere else. So I've gotten something working by doing exactly what I mentioned in my first post: passing the NBT Compound to the ItemStack and checking for it in onUpdate which seems to start running well before visuals load in so it effectively does exactly what I need (setting textures on load). I can't help but feel though tying this into the onUpdate function seems a little much checking the boolean for loading every frame for the rest of time you hold the item... But I don't guess it would slow anything down. Is there a major downside to this? If this isn't a horrible atrocity I'll toss in a null check to make sure it doesn't try to load before there's data there and call it done? If this is seriously bad I guess I'll have to try to set it to damage states which I imagine get saved with the item.

Hello. I am trying to come up with a way to have an item that supports mode changing. While the mode changing itself is fine, I want a way to save what mode it was in the last time the player used it. I tried sticking it in an NBTTagCompound which.. there doesn't seem to be a way to save in the standard Item based class so it only saves until Minecraft is restarted. I see some kind of saving method by passing that compound into itemStack.TagCompound(); but am unsure how to use that exactly. Outside of specific functions I don't seem to have access to the ItemStack... Would storing it there and pulling it out on load with the onUpdate function work? I assume all overridden functions get the same ItemStack passed into it? Or is there a better way of doing this or somewhere else to store my NBT Compound? (I original thought of trying to store this value in damage values?) My class as it is now: http://pastebin.com/jdbjFiwF

I will try to pretend that didn't come off as quite rude... Yes I know what static does/is, it was the first thing we learned in the first class in uni. Something slightly more useful would be helpful.. Like "There is only one instance of that class in the game, not one per person" That might actually explain something.

Everytime a change happens to the mana amount it runs the sync() function, which has the packet send if it's on a server. https://github.com/Rohzek/SpiralPowerMod/blob/master/main/java/com/Rohzek/player/SPExtendedPlayerStats.java

I... Feel so stupid right now. I thought about it for a minute after posting and realized "Shouldn't that be somewhere else too?" I checked in the client proxy and found this: somehow commented out. Uncommenting it makes it work... sorta... EDIT: Not working as intended exactly... NOW the packet gets sent but only one random player on the server gets their mana drawn from... It's not working individually...

That it does.. but I don't understand why? Packets seem to be quite a bit above me. The two lines it refers to of mine in the error is 111 and 119.. 119 is a definition of AbstractClientPacket which seems to be sending to client from server as I understand the comments on the tutorial I got it from... 111 is a call to process() which needs a side specified... which it gets from MessageContext... I'm not sure how it gets that... The message itself is sent with sendTo which is sent from server to client right? I'm not sure where things got flipped.

! I completely forgot about the FML log! It definitely has the problem in it.. but I don't quite understand it... it seems I've messed up the packet somehow, it seems to be of type PlayClient and is trying to cast to PlayServer. Error in log:

Ah, I see what you meant after checking the link you posted. Is there any real difference for doing in the main file versus in it's own class? I've been trying to keep the main file as clean as possible. There is an internal server but isn't the difference between EntityPlayer and EntityPlayerMP still there? Or am I perhaps checking the fall itself incorrectly? As of right now if I don't check to see if it's an instance of EntityPlayer I get errors with bats... I may be going about checking the fall damage wrong?

No crash report is being generated as neither the server, or the client actually crash. It's only booting me from the server back to the server selection screen.. to which I can click connect again and do it all over again. Packet Pipeline is a bad name. It actually houses a simple network wrapper instance, I'm not using Netty. Perhaps PacketDispatcher or something would have been a more appropriate name. By server side only, should I only be checking for isRemote / just handling singleplayer and multiplayer separately then? Yes, it's being called in the PreInitializationEvent in the Main class file.