Major Squirrel

That's the trick : when the player quits the item interface, it stops the consumption. The items which were in the slots are dropped on the floor.

Good evening, Using Forge 1.8.9 build 11.15.1.1722, I'm currently trying to create an item that acts like the furnace when rightclicking on it. (gui texture here) The use case of this item is the following : when rightclicking with this item, a gui is displayed with the player inventory and his hotbar. There are two slots that are unique to the item : an entry slot and an "exit" slot (concretely this is the same as the furnace except that it has two entry slots, the fuel and the things to burn/cook). When putting blocks in the entry slot, it starts the consumption : the consumption may end at any moment like quitting the gui or something else. At first try, I took a look at TheGreyGhost tutorial, BedrockMiner tutorial and coolAlias tutorial : I brained myself when I had to add a TileEntity to an Item which seems to be already set with an ItemStack. Since I don't need to save any data in the Item itself (the consumption is set when the player is using the item, there are no resources to store into slots...), are a Container and an Inventory sufficient to do it ? I ask this question because I'm not sure about storing/updating or not the consumption time, I don't know where to do it. What would be, according to you, the best way to achieve this ? Thank you for your time and your tips !

For my part, I didn't have to implement the ITileEntityProvider interface : I simply overrode hasTileEntity and createTileEntity (and not createNewTileEntity) methods, and it seems to work very well ! I suppose it would be different according to different user cases.

Did you also change the file name to the specified unlocalized name ?

Hi blahblahbal, Using sublimetext, it gives me this : I'm not sure it was encoded well, try to write it by yourself and make a test again !

Good evening TheDogePwner, Are you sure the unlocalized name of your item is RubyGem ? If it isn't, it will not work. You could still put a debug message into your code, when your item is loading for example, to check it ! Furthermore, I've never seen any properties into languages files like language.xxx, try to run it without these three lines to check if it works without them ! EDIT : it seems that it works for me, my bad, never seen that ! Also, take a look at this useful topic about localization, by Jabelar !

Hi elix, thanks for your reply. I will modify my code, considering what you said above. About return (false), I like to get a clear view of what I am returning inside my code. It's an habit I got since college. What about the player experience management I did ? Is it ok ? I took a look earlier on the EntityPlayer class and it seems that these variables are initialized with negative values, so I don't really know if it's ok to do the way I did.

Good evening, I'm currently trying to make a block, an "experience container" that drains the player experience when rightclicking on it. I think I'm managing well for now but I have few questions about player exp management : Do I have to check the isRemote variable inside the drainExperienceFromPlayer ? In the method bolded above, do I have to cast the EntityPlayer to a multiplayer one ? I feel it is "safer" to perform operations on variables, such as experience, on multiplayer entities (it is for a private server) As you can see in the same method, I'm managing player experience super simply : I just make an exp transfer in the block and I reset the player exp variables just putting them at 0 : public boolean drainExperienceFromPlayer(EntityPlayer playerIn) { if (!this.worldObj.isRemote && playerIn instanceof EntityPlayerMP) { EntityPlayerMP playerMP; playerMP = (EntityPlayerMP) playerIn; if (playerMP.experienceTotal > 0) { this.experienceTotal += playerMP.experienceTotal; playerMP.experienceTotal = 0; playerMP.experienceLevel = 0; playerMP.experience = 0.0f; } else return (false); } return (true); } I made some googling such as this gamepedia link, this topic and the EntityPlayer class to see that leveling up is specially treated, and I'd like not to f*ck up player experience performing this kind of operation. The following files : BlockExpContainer.java TileEntityBlockExpContainer.java Thank you in advance for your help !

Hey there, did you finally solve your problem ? Was it a read/write incompatibility or something else ?

Yeah I must admit this is awkward, I join you on this point ! Could you please post here your packet class and the method where you register your packets, both in pastebin, so we can take a closer look ?

Hello mate, I'm a Forge newb too. I suppose you read data the same order you wrote them right ? Did you pay attention using the correct (meaning unique) discriminators when registering them ?

Sorry, I'm updating my code anytime, I'm just discovering the Property concept. I'll lock this topic as it is solved now and, my bad, it derived to new questions. The purpose of all of this is to change dynamically a block texture according to a fermentation cycle in the TileEntity : on block placed, the barrel starts its fermentation at cycle 0, then every X ticks the fermentation "levels up" and the cycle increments. At first, I was using an EnumType called "type", associating a string (cycle0, cycle1, etc) to a value (0, 1, 2...). The purpose of using an enum was to correctly set the blockstates according to the enum properties : (old code) { "variants": { "type=cycle0": { "model": "questsystem:block_barrel_cycle_zero" }, "type=cycle1": { "model": "questsystem:block_barrel_cycle_one" }, "type=cycle2": { "model": "questsystem:block_barrel_cycle_two" }, "type=cycle3": { "model": "questsystem:block_barrel_cycle_three" } } } According to the current type of the TileEntity, it set the correct texture associated to the correct model. I was passing the cycle value through blockstates changes, that is why I was talking about metadata. Lately, I wanted to set the block according to the direction the player is facing (like the furnace). It is a that moment that I understood I had to handle the EnumDirection "facing" for each "type" cycle : (current code) { "variants": { "fermented=false,facing=north": { "model": "questsystem:block_barrel" }, "fermented=false,facing=south": { "model": "questsystem:block_barrel", "y": 180 }, "fermented=false,facing=west": { "model": "questsystem:block_barrel", "y": 270 }, "fermented=false,facing=east": { "model": "questsystem:block_barrel", "y": 90 }, "fermented=true,facing=north": { "model": "questsystem:block_barrel_fermented" }, "fermented=true,facing=south": { "model": "questsystem:block_barrel_fermented", "y": 180 }, "fermented=true,facing=west": { "model": "questsystem:block_barrel_fermented", "y": 270 }, "fermented=true,facing=east": { "model": "questsystem:block_barrel_fermented", "y": 90 } } } There, I switched my EnumType to an PropertyBoolean for only two cycles (0 and 1) because the number of cycles is now limited to 10 (because directions use 6 bits on metadata). I suppose that I can go on a PropertyInteger to reach these 10 cycles, but I won't do it for now. Currently, I'm looking for another way to change texture dynamically but it seems that I have to use blockstates to do this ... This will go on another topic I suppose. Anyway, thank you guys to enrich my knowledge.

That is because I wanted to associate an integer to a string so that the texture could be set according to the variants, for example : { "variants": { "mode=normal": { "model": "questsystem:block_barrel" }, "mode=fermented": { "model": "questsystem:block_barrel_fermented"} } } The mode is the enum, normal and fermented are strings of the enum associated with the int (the currentCycle/metadata)

I use it, to get the correct texture block according to the currentCycle : the currentCycle corresponds to the metadata. It is then converted to the specific enum which gets the correct texture of the block. BlockBarrel.java TileEntityBlockbarrel.java (server) If I don't have to deal with metadata, could you explain me how can I change my texture block according to an incrementing variable (dynamically) ?

The byMetadata method inside the enum handles the meta by returning the correct enum : public static EnumType byMetadata(int meta) { if (meta < 0 || meta >= META_LOOKUP.length) meta = 0; return (META_LOOKUP[meta]); } The purpose to use metadata here is to get the correct enum according to the currentCycle/metadata, incremented in the TileEntity.

I don't see the point not to use my getStateFromMeta method if it is already doing it : @Override public IBlockState getStateFromMeta(int meta) { return (this.getDefaultState().withProperty(TYPE, EnumType.byMetadata(meta))); }

Just saw that I still need to get a BlockState to set it doing this.worldObj.setBlockstate(...), how could I do if I can't touch to getStateFromMeta ? I've overriden it, this should be ok no ? (take a look at the attempt above)

Okay I will try that tomorrow. Thank you And what about updating clients properly ? Should I just set markBlockForUpdate ?

Okay, so it seems that I'm doing something wrong here. I just want to tell players that the block has changed : the this.currentCycle has been incremented and the texture is properly set according to the currentCycle. (that is probably why I should save to disk, isn't it ?) I do not really see how can I change the block state if I don't have to access to getStateFromMeta myself.

Yup, I just made the changes you indicate me and it works very well, thank you guys. However, I still have some questions about server updating clients. What is the difference between this : private void sendUpdateBarrelTexture() { IBlockState blockState; blockState = this.worldObj.getBlockState(this.pos).getBlock().getStateFromMeta(this.currentCycle); this.worldObj.setBlockState(this.pos, blockState, 2); } and this private void sendUpdateBarrelTexture() { IBlockState blockState; blockState = this.worldObj.getBlockState(this.pos).getBlock().getStateFromMeta(this.currentCycle); this.worldObj.setBlockState(this.pos, blockState); this.worldObj.markBlockForUpdate(this.pos); this.markDirty(); } For the first code, especially the setBlockState method, the javadoc says : "sets the block state at a given location. Flag 1 will cause a block update. Flag 2 will send the change to clients (you almost always want this). Flag 4 prevents the block from being re-rendered, if this is a client world. Flags can be added together." In my case, I just want to tell clients that the state of the block has changed (other texture). Currently I'm using the first code, am I wrong doing this ?

Here is my attempt I suppose that in client mod I override hasTileEntity to return false and in server mod I override to return true and createTileEntity to return a new TE ? Also, why should I not extend BlockContainer ? I followed GreyGhost and BedrockMiner tutorials but according to you it seems not ok for me.

Hey boyz (and girls), I'm playing with TileEntity for now, and something is happening when creating a new TileEntity. I'm creating a barrel block that extends BlockContainer : I have to implement createNewTileEntity(World worldIn, int meta). I want to keep the TE logic for the server mod, so I implement all the TE code in the server mod, and in the client mod I'm returning null. When I return null for this method, when the block is placed, the chunk updates increase from 0 to 40 chunk updates constantly ! FPS decrease too (when I destroy the block it will return normal). But when I return an empty TileEntity (just the class + an empty constructor) it works without any problem, why is that ?

Okay, good to know, thanks ! diesieben07 should update his tutorial

Re-synchronise... That's where I click the circular arrow icon in the gradle tab isn't it? If so I've pressed that every time I've done a task in the tutorial. I've also run genIntellijRuns task every time the tutorial has stated too. Well, I'm sorry, I don't know what to say. Here is a screen of my config if this can help you : However, do you have the same processResources as me in the build.gradle file ? processResources { // this will ensure that this task is redone when the versions change. inputs.property "version", project.version inputs.property "mcversion", project.minecraft.version // replace stuff in mcmod.info, nothing else from(sourceSets.main.resources.srcDirs) { include 'mcmod.info' // replace version and mcversion expand 'version':project.version, 'mcversion':project.minecraft.version } // copy everything else, thats not the mcmod.info from(sourceSets.main.resources.srcDirs) { exclude 'mcmod.info' } } Finally, when you build a jar, I suppose your mcmod.info is not there ... ? EDIT : using Intellij IDEA 15.0.3, build #IU-143.1821 for educational use only ! EDIT2 : the way I proceeded to make an Intellij Forge project is the following : Get the forge files and put them in a folder Run ./gradlew setupDecompWorkspace from console Import project from Intellij using their gradle version and the build.gradle file Add idea { module { inheritOutputDirs = true; } } to the build.gradle file without syncing Run genIntellijRuns task from Intellij, it will normally ask you to reopen project, do it May it helps you

Hey guys, Good news, it works ! I decided to create two projects separately using the same "mod" infos : version, modid, etc... For now, I have a client project and a server one. I have the same packet class in both projects, but each project has its own implementation of the packet. Registering the same packet to the same discriminator, it works like a charm ! However, I still have some questions about client/server side exercices : how can I check if my packets are leaking ? Furthermore, I decided to give a try sending player nickname through packets, here is the code : @Override public void handleServerSide(MessageQuest message, EntityPlayer player) { ChatComponentText text; text = new ChatComponentText("Currently, your singleplayer nickname is : " + message.playerName); player.addChatMessage(text); text = new ChatComponentText("However, here is your multiplayer nickname : " + player.getName()); player.addChatMessage(text); } Here, I am sending the player nickname through the packet. The message.playername is obtained by Minecraft.getMinecraft().thePlayer which is an EntityPlayerSP. The player.getName() is obtained through context.getServerHandler().playerEntity which is an EntityPlayerMP. Informations such as player nickname are "obtainable" by both client and server mechanics. Actually, I'm wondering how could I know when to get informations from server side or client side : I assume that the right method is to always get infos from server side, but I'd like your point of view about that