HalestormXV

Alright that's good to know. That is what I though but just wanted to be sure.

Hello there. So I just pushed my mod into a release candidate and it works awesome on Single Player. I have quite literally 0 issues. And that is thanks to the wide variety of help I have gotten from this community especially. I have a simple question. Some of my items utilize NBT data in which I followed the documentation from various sources as well as retrieved help from the various community members here. I put my mod into a network environment (SMP) and I fear something may be wrong. I haven't had the chance to test it quite yet however it occurred to me that two items specifically utilize NBT data in their code however they do not have a writeToNBT function or readFromNBT aside from the TagCompound functions within their classes. Now although they store NBT data (for example one items stores how many times you have used it and the other stores a cooldown of the item and both store the names of the user) do those functions automatically get written to the server data and read from the server data simply by calling the stackTagCompound.setInteger or the stackTagCompound.getInteger? Or do you need to create different functions to have the data written to the server and read from the server? Here are my two classes that utilize NBT. Both of these are items however neither of them have a write toNBT or loadfromNBT function like my TileEntity class for my furnace which works fine on SMP http://pastebin.com/3wn7qECD http://pastebin.com/fA75J4Yy If anyone can take a quick browse through that and let me know if it should work fine on SMP i appreciate it. Or do I need these writeNBT and loadNBT functions. Like I said I haven't gotten to test it yet but do plan to. But I know it does work just fine on my singleplayer world as I have tested it there.

I'm not sure what you mean. I've slightly altered the code: I've gone though the DamageSource class and I do see a variety of different methods like DamageSource causeArrowDamage, DamageSource setExplosion, public Entity getSourceOfDamage(), public String getDamageType() etc. Is using the above way not correct? Essentially how I am reading it we are retrieving the Source of the damage and if it is an instance of a player we continue. Or perhaps I should just do it right from the start is what you are suggesting? public class CCMobDrops { @SubscribeEvent public void dropSpiritualEssence(LivingDropsEvent event, DamageSource damage) { if ( !(event.entity instanceof EntityPlayer) ) && (damage.getSourceOfDamage() instanceof EntityPlayer) ) //check the entity that caused the damage and making sure it is of player. { Random dChance = new Random(); int rareDrop = dChance.nextInt((100 - 1) + 1) + 1; if (rareDrop < celConfiguration.SPIRITESSENCE_DROP_PERCENT) { Random random = new Random(); ItemStack itemStackToDrop = new ItemStack(CelestialCraft_items.spiritualEssence, random.nextInt(3)); event.drops.add(new EntityItem(event.entity.worldObj, event.entity.posX, event.entity.posY, event.entity.posZ, itemStackToDrop)); } } } }

Oh yeah, it did have it in there. Not sure how I missed it. So this should prevent these specific item drops from grinders correct: public class CCMobDrops { @SubscribeEvent public void dropSpiritualEssence(LivingDropsEvent event) { if ( !(event.entity instanceof EntityPlayer)) { Random dChance = new Random(); int rareDrop = dChance.nextInt((100 - 1) + 1) + 1; if (rareDrop < celConfiguration.SPIRITESSENCE_DROP_PERCENT && event.source.getSourceOfDamage() instanceof EntityPlayer) { Random random = new Random(); ItemStack itemStackToDrop = new ItemStack(CelestialCraft_items.spiritualEssence, random.nextInt(3)); event.drops.add(new EntityItem(event.entity.worldObj, event.entity.posX, event.entity.posY, event.entity.posZ, itemStackToDrop)); } } } }

In your second option without the IEEP. What do you mean it goes beyond the vanilla drops system? As in the item is not really being "dropped" just created? So vanilla isn't actually controlling it?

Alright, so I have added Global Loot to all existing living vanilla entities and any other new entities that might be subsequently added to the game. The item is meant to be incredibly rare, which it currently is, however it can drop off of anything. Kinda like a Trophy from openBlocks. Here is my inquiry. I want to make it so that players cannot set up a mob-grinder, flip a switch and then just play the waiting game. I know I saw a tutorial on how to do this somewhere but I cannot find it again. I input the global loot via the Subscribe Event when loot is created. Basically letting this item be obtained via a mob farm breaks the whole purpose of the mod so I Want to prevent that. And I do know it is possible I just don't know how to do it. My current method is very simple for adding drops. Now I essentials just need to add a mob-farm check to that. @SubscribeEvent public void dropSpiritualEssence(LivingDropsEvent event){ if ( !(event.entity instanceof EntityPlayer) ) { Random dChance = new Random(); int rareDrop = dChance.nextInt((100 - 1) + 1) + 1; if (rareDrop < celConfiguration.SPIRITESSENCE_DROP_PERCENT) { Random random = new Random(); ItemStack itemStackToDrop = new ItemStack(CelestialCraft_items.spiritualEssence, random.nextInt(3)); event.drops.add(new EntityItem(event.entity.worldObj, event.entity.posX, event.entity.posY, event.entity.posZ, itemStackToDrop)); } }

Alright, the function was my original guess. I just wasn't sure if static would work because I was using this or not and the fact it worked right away biased my thoughts. But your right function is the better route to go. Okay, no problem then.

Thank you sir and my last final question is more one just of general inquiry. Naturally since I am changing the furnaceSpeed based on the mode you are in I want the progress bar to represent that. Not always moving at the same speed and then overflowing off the GUI because it doesn't realize the speed has actually changed. So I simply just changed the furnaceSpeed to be a static variable indicating that "Hey this can change" and other classes will look at it so be aware of it. This fixed the issue and the progress bar now correctly represents the change in speed. If we are in CelestialMode it move nice and slow, and if we are in normalMode it goes faster and does not overflow off the GUI. My inquiry is that doing that is the correct (if not only) way to go about it right and won't have any consequences?

EDIT: SNIP Holy hell, coolAlias, thank you so much! I had a massive post here before basically raging at how dumb I felt, that I couldn't figure this out lol and I know I am not an idiot and that is what was frustrating me more. But I calmed down a bit, carefully re-read your comments and explanations. Watched a bitOperator tutorial on YouTube and re-focused myself with a a cup of Cinabun coffee and FIXED THE BLASTED THING. I was setting my MetaData wrong in the TileEntity class. I was setting 1 value of the meta-data which was only corresponding to south side as opposed to setting all values of the meta data as your comment indicated 10, 11, 12, 13. So the fix, now that I see how stupidly simple was, is exactly as you stated "like a switch." I just couldn't figure out how to create "the switch." But once I tried it and it worked I had a big sign of relief and satisfaction followed quicky with a "I want to smash my head into the desk, because I didn't notice it." Here is the new TileEntity methods that I had to adjust. Here is the adjusted update method in the BlockClass: So now just to make sure I grasp your lessons, because you have helped me out tremendously and I just don't want answers. I want to learn. So I want to make sure I learned this correctly. The furnace used 3 bit values. 1 2 and 4 are all taken and store the side/rotation data. front face, side face, etc. etc. Bit value 8 is free. So we can store new data in there. So what this code did in the TielEnttiy class is first store whatever the current meta data of the block is. Then it added the bit value 8 to it which takes the meta-data range of 10, 11, 12, 13. So essentially in doing that the code now says: Okay the new metaData of this block which is retrieved in the updateMethod via "int meta = tileentity.getBlockMetadata();" of the block class is whatever the original meta-data which is defined in the TileEntity class edit I made via "int meta = this.getBlockMetadata();" was and now add fields 10, 11, 12, and 13 OR more simply bitValue 8 via the other tileEntity edit I made: "this.worldObj.setBlockMetadataWithNotify(xCoord, yCoord, zCoord, meta|=8, 2)". That is what the iconCheck is looking at correct? It is saying hey we have some new fields on this. Boolean check if they are |8 and if so take all the direction data except whatever corresponds to side front and switch up its texture. (I:E: now 10, 11, 12, 13). Then the second part of this code is what occurs if you are not doing a celestialSmelt. Essentially it does the exact same thing as above except now it uses & 7 which as you said basically strips away all of those added values from |8 and says just keep the original and then the check says okay not new meta fields in |8 strip them out and use the default data. And because this data is stored on the block itself in the block's meta and the block and TileEntity is its own instance of each other so therefore each block acts independently of one another on a ServerWorld or a SinglePlayer world. Sorry for that long winded explanation but I wanted to make sure I understand this now and also let you know that I actually learned this thanks to you so your efforts were not in vain lol.

Excellent! It is partially working. My textures are altering correctly now WITH the placement of my blocks. So the block when placed will always face me with the inActive front. Only one problem remains and once solved I will proceed to never do this again or work with bitValues until I am absolutely comfortable with them. The only problem that remains is this. Once the furnace is in "CelestialMode" which uses the alternate texture it rotates the front texture to face the south side. So it switches the texture correctly but the block doesn't stay facing its original direction. Then if you switch the recipe to a normal smelting recipe the alternate texture remains in effect and the block stays facing the south with the alternate texture. The good thing is that in doing this "way out of my league" type of code I am learning and know that this is occurring due to me doing something wrong in my: public static void updateCelestialFurnaceBlockState in this blockClass. And yeah I know I should have never ventured this far without a better base understanding of this meta manipulation and I happily admit that. But this is for sure a lesson learned. This I believe is it. Once I rectify this error I think this block is done and done.

The value 8 is good to use because bit value 4 is free correct. So in the TileEntity where I am setting the metadata marked with 2 asterisks is okay. Now I know that works because my front textures alternate as they should if I am smelting a Celestial Item, and then it reverts back to normal if I start smelting a normal item. So I know my meta data is being checked and stored correctly. What I am struggling to understand and perhaps what is making me so confused with this is why my furnace will not maintain it's direction if I use one function, yet if I use the other function it does keep its direction just doesn't switch the texture. Here is the current getIcon function This is the one that works and switches the texture correctly back and forth yet doesn't rotate my furnace and automatically makes the face point north. HOWEVER, this function which was my original, before I decided to do the CelestialMode smelting does work: That function makes the furnace's front texture face me no matter where I placed it and the furnace maintains its direction when I start smelting. Now granted I know my this.frontAlt is not referenced anywhere in that method but isn't there a way I can check the metavalue in that method and if it finds an 8 it will use the this.frontalt? I guess where I am struggling with this bit operation is why in one function it works as it should (not the bitOperation but the rotation), but in the other it doesn't. Then what is even more frustrating is I am grasping what you are explaining and it makes sense but I can't seem to understand how to actually store the location info and then add a new flag to it. Like it seems stupidly obvious: int direction world.getBlockMetadata(x, y, z); Get our current block meta-data that has already been placed down. Everything is stored in there. TileEntity tileentity = world.getTileEntity(x, y, z); gets the TileEntity int tileentity.getBlockMetadata(); gets the metadata from our TileEntity class which we set to 8 in its celestialSmelt function For some unknown reason I get blocked here. Yet in reading your posts I know this is probably where I shouldn't get blocked because after I have gathered that information it is just a matter of saying hey if 8 is part of the metaData we use a different texture. But if 8 isn't in that metaData we use the regular texture. And I know that the furnace is 3 bits. So 8 + 3 = 11 so therefore we are checking to see if 11 is the meta-data and if it is we use the alternate front texture and if it isn't we use the default front texture. But I just can't figure out how to put that into the code.

Alright I am really trying here as this is the last step for this furnace. And after reading your post and your link I am grasping it. I imagine i am doing this in the onBlockPlaced correct? Since everything else is working with the exception of when I place the block? BlockPlace: It is in here that I would have to collect and store the blockMetaData? int meta = direction; Or do I collect the meta in the method right below that which is the updateBlockState like so: int direction = world.getBlockMetadata(x, y, z); TileEntity tileentity = world.getTileEntity(x, y, z); int meta = tileentity.getBlockMetadata(); UpdateBlockStateCode And then with meta now stored in this update method I run an if check which will say if meta = 4 (Celestial Smelting) meta |= 8; else if meta = 2 (Standard Smelting) meta = meta & 7; then at the very bottom before the method closes off world.setBlockMetadataWithNotify(x, y, z, meta, 2);

Well hell, i can say i am not at all familiar with that. Could you provide an example of it in action with the code? I do see your examples also but cant figure how i would apply that. I mean i get the concept.

Alright after some tweaking and your help I got it. The alternate textures work now. However, arises 2 new issues and I am for sure that this is from an oversight on my part without a doubt. The issue is now the block doesn't auto-rotate when you place it so the front is always "facing you." And the progress bar goes all out of whack when you switch from smelting a celestial item or a regular item. When smelting a regular item it fills the progress bar fine. But when smelting a celestial item which has a speed of 200 the progress bar doesn't represent it properly. Now I know for sure this is likely because I am manipulating its meta-data on the fly and those timers and variables are stored with the original meta-data. Perhaps I just need another pair of eyes to look at this and tell me where I need to make the changes. Once again I am fairly certain it has to do with me manipulating the meta-data like that but I just can't find where that manipulation caused those errors since I have been working on this furnace for like 2 days now lol. Here is the new code: http://pastebin.com/eXpNh9i2 - TileEntity http://pastebin.com/9XxFyKGL - BlockClass

Alright I got the different times set up and working by adding this to the tileEntity code: public boolean canSmelt(){ if(this.slots[0] == null){ return false; }else{ ItemStack itemstack = FurnaceRecipes.smelting().getSmeltingResult(this.slots[0]); if(itemstack == null) return false; if(this.slots[2] == null) { this.furnaceSpeed = 45; return true;} if(!this.slots[2].isItemEqual(itemstack)) return false; int result = this.slots[2].stackSize + itemstack.stackSize; return ( result <= getInventoryStackLimit() && result <= itemstack.getMaxStackSize() ); } } public boolean canCelestialSmelt(){ if(this.slots[0] == null){ return false; }else{ ItemStack itemstack = CelestialFurnaceRecipes.smelting().getSmeltingResult(this.slots[0]); if(itemstack == null) return false; if(this.slots[2] == null){ this.furnaceSpeed = 200; return true;} if(!this.slots[2].isItemEqual(itemstack)) return false; int result = this.slots[2].stackSize + itemstack.stackSize; return ( result <= getInventoryStackLimit() && result <= itemstack.getMaxStackSize() ); } } Works fine so far. Only problem is that the cookBar that is shows to the client is not representing the change in time accurately but that is probably something I can easily fix with some minor tweaks where that shows up. But I can't seem to figure out what you mean by changing the meta while it is doing a celestialSmelt. I imagine in the block class under my getIcon function I could case/switch the second argument which is the meta-value or check it otherwise like you said above. But how would I go about changing that in the tileEntityClass once it is active. Its not as simple as calling a this.blockMetadata = 4; in the celestialSmelt function is it?

Alright I have a question. I have a custom furnace that is working great, along with a custom smelting handler where I can input my own items. The furnace works fine. It triple standard ore recipes and because I have a custom SmeltingHandler, all of my custom recipe do not triple. I want to take this a step further if at all feasible. I want to adjust the furnace's speed and active texture if one of my custom smelting recipes are in there. So say I am smelting an item that is actually in my custom smelting handler, the furnace will smelt the item slower and the texture on the front of the block will look different. If it makes it easier, I wouldn't mind if you still have burn time remaining in the furnace and by inputting one of my custom recipes the burn time resets to 0 thus needing new fuel (which makes sense since it is in another "mode") http://pastebin.com/uHYRcccc - FurnaceTile Entity http://pastebin.com/NTQSTrfh - Furnace Block I will admit I have no idea which direction to go in to accomplish this. So any help is appreciated. It doesn't "sound" overly complex, but then again there is a huge difference to explanation and making it happen.

Yes the tutorial was an older one however, no BiomeManager.addBiome isn't called anywhere. That ModBiomes class that I showed you is the only place that those biomes are defined and registered. With regards to the conflicting IDs that was the first thing I checked out. The biome IDs do not conflict with any of my Biome IDs. That was actually the first thing I checked out.

I think I understand what you are saying Choonster. So in my situation. I have this being called in my main registry: ModBiomes.registerWithBiomeDictionary(); This is my ModBiomes class: http://pastebin.com/RnE5rn5u So you will note I have commented out: //BiomeDictionary.registerBiomeType(forestLight, Type.FOREST); //BiomeDictionary.registerBiomeType(forestDark, Type.SPOOKY); and only left: BiomeDictionary.registerAllBiomes(); So in doing this I removed my two custom biomes forestLight and forestDark from the dictionary so they aren't going to be called anywhere. However since my custom dimension uses a custom decorator that specifically calls too these two individual Biome classes it will still have them generate in my custom dimension. But since they aren't registered it won't generate anywhere else in the game. Is that interpretation correct?

I don't understand what you mean. I need to try and figure out how to stop the biomes themselves from even being generated in other dimensions with the exception of my custom one.

Don't think that would work because a switch requires a constant value. I coded the DimensionID so it could be changed via config in order to resolve conflicts with other mods. That would probably work if I made the DIM-ID a hardcoded value though but I don't want to do that.

Hi there. Quick and probably simple question. I have a custom dimension, custom biomes, custom decorator all that good stuff. And it works fine. No issues. Only problem I am running into is that if you use the Biomes O Plenty World Type, or enter in to the Nether, my custom Biomes spawn. I just want to know how I can go about stopping this from happening? I imagine it will be something related to making sure that you are in the custom dimension? Kinda like how twilight Forest does it. Those biomes ONLY spawn in the Twilight Forest dimension. Would this check go in the custom chunkProvider somewhere? Or in the Biome class files themselves? Or perhaps in the custom decorator itself? I know it is probably a simple check that says don't do this if you are not in the Custom Dimension ID but I just need a shove on where it would go. Thank You.

Excellent, seeing those examples helped me out greatly. I have also been looking into those basic tutorials. I have somewhat o a programming background its just a matter of saying alright Java is object based this is different from C++ etc. etc. I find it more in line with PhP. Unfortunately Java is not something I ever practiced with. But those tutorials I am sure will help. So I have changed the method and cleaned up the code. The method is much simpler now: public void setSummoned(int Index, boolean active) { summonedState[index] = active; } SNIP Just editing this post. I managed to try out my question. My question was if I could just store the entities owner in its initialization as a variable which I did do with: this.ownerStored = (EntityPlayer) this.getOwner(); Then simply in the onUpdate event where it checks if the owner is null (person logged out or crashed) it then goes to the stored data and passes that along and sets the isSummoned flag to false. Once the player logs back in they can resummon the entity and it works fine. I also managed to play with the itemstacks NBT and set it up so it now tracks how many times you have used that particular item and the item becomes contracted to you and indicates who the owner of the item is on the actual item. So if another person steals your key they can't use it and they are forever haunted by the name of the rightful owner showing every-time they hover over the key. So that was an added little bonus that I get to thank you for. I got the idea from your original code before you introduced me to the ExtendedProperties. So, as it stands now everything is working exactly as it should along with some bonus features. It seems like it should work fine on a server as well. So thank you for all the awesome help, as frustrating as it may have been for you. I will take a lot out of this. Finally [sOLVED]

Alright, maybe you can answer me this question perhaps? I am going to take another look at it and heed your advice. Because I know in its current state my code is a mess, but I am learning and cleaning it up as I go. And the NBT data is coming from my itemclass with the player.getEntityData() which I had no idea existed until i went digging around in some of the source code. My methods seem to work now after I created the packet handler. It is working correctly now. But I don't know why. I followed your network handler tutorial and set up a packet handler and I took the examples you gave in your tutorial and altered them and changed up their fields to fit my mod as well as added some new functions to my customNBT. But in order for me to get the best out of this I want to know why it is working now. My code is as follows: Here is my ExtendedPlayer now: http://pastebin.com/qkyCqc9A My Itemclass: http://pastebin.com/DnQeUb8a Your Packet Dispatcher http://pastebin.com/JM8yh52F The Sync Packet for the ExtendedPlayer: http://pastebin.com/rJXVrm2A So combining all of these and registering my event handler makes my items now do EXACTLY what I want. You can have as many keys of the same subType as you want but once you summon one entity you cannot summon it again. Now if you select a different key with a different subtype you can summon that entity and then you cannot summon EITHER entity again. So they are not "overwriting" each other and it seems to be working perfectly. All that is left now is to change the flag back in the entity class once they despawn which I am sure I can figure out. But what I want to know is why all of a sudden now this is working? Becasue of the packets? And is it still going to work that way on an SMP. It seems like it would since it is literally only altering that player's NBT data. Or is it literally because I fixed my method and the packet isn't really doing anything.

Alright that small example actually helped alot and now I am getting somewhere, so thank you for that. It seems my code is now actually "doing something" although it is causing a crash. http://pastebin.com/CqFmmrGF (Crash Log Full) http://pastebin.com/0LVPn3VZ (Point in the log where the error occured) That crash log narrows it down. I totally did my method wrong OR it is ticking because I didn't create my packet handler yet. I am fairly certain that perhaps the crash is caused by not sending or even creating the packets though, but I am still new to all of this so I may be wrong. Although i do recall or at least I think I recall in reading over some tutorials that when you are manipulating client data that is to be saved on the server you will almost always need a packet handler. Because as well all know the information is stored in packets and you need to send those packets to the server so it can store them. Here is the fixed up code for the IEEP http://pastebin.com/3p7e5tf1 which includes the function I am calling to set the tags from my itemClass. Here is the complete itemClass file: http://pastebin.com/KfQa8aNj I am a visual learner, so by seeing that example or even a type of pseudocode it helps tremendously. Thank you again for all the help and responses. I apologize for my noobishness but I am learning and your responses are not in vain. As with my previous threads, every single one of my issues that I have brought up on this forums I have resolved with the help of everyone, so I am learning and not only learning but retaining. EDIT: Just thought of this, would it be easier to set these true and false values with a data watcher since the entites are not supposed to stay summoned?

2. You need to actually save the value of the variables - your save method currently sets every one to 'false' - that was an oversight on mypart. I changed each one to properties.getBoolean(PLAYER_HAS_CONTRACT)) This way it will get the current value, which ideally would be changed after a successful summon. 3. Getting and setting these values is about as basic of Java as it gets - just make methods to do what you want And that is why I am dumbstruck. I know it is incredibly basic. Summon Entity Success -> Set Correct Flag to True -> Update/Save the Player's NBT -> Poof they can't summon that entity -> Entity Dies or Despawnes, no problem, reset flag back to false -> update/save NBT So yeah simply reach out from the item class when the item is used and the entity is successfully summoned/created to set the flag and then in the entityClass on its onDeath function set the flag for its owner (the player) to false. I guess my problem is how to reach out from the itemClass into the ExtendedPlayer class and set the correct value for the correct spirit/entity. Using the Reflection code block automates everything for me yes and is super efficient and works great. But where I am stuck is how do you have the code say we are using the Summoning Stone with the damage value of 6 so set the flag in the ExtendedPlayer array of the 6th index to true.