Jump to content

Bioxx

Forge Modder
  • Posts

    21
  • Joined

  • Last visited

Converted

  • Gender
    Male
  • Location
    Boston
  • Personal Text
    Creator of TerraFirmaCraft

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Bioxx's Achievements

Tree Puncher

Tree Puncher (2/8)

3

Reputation

  1. The 3rd parameter when creating an itemstack is always the metadata. See Below: ModLoader.addShapelessRecipe(new ItemStack(TFCItems.SinglePlank, 3, 0), new Object[] {new ItemStack(TFCItems.Logs, 1, -1)}); In the Above example notice the logs itemstack has a -1. This means that the recipe can use a log of any metadata at all. Then look at the SinglePlank itemstack, the 0 says that the result will be SinglePlank:0. I probably overexplained, but there you go. I hope that helps.
  2. I suggest you look into ICraftingHandler. Feel free to adapt my Crafting Handler for TFC to your needs
  3. The server should be handling everything. All the client is there for, is to display information. If your items are existing clientside and you're trying to tell the server about them then you're probably doing something wrong. Never ever trust the client.
  4. The easiest thing to do would be to just set the item damage on the item back to max every time it gets used. ItemStack.setItemDamage() is what you want if I am remembering the method correctly.
  5. You need to send a packet to the server telling it that the player has pressed the key and then call your parachute code from there. Feel free to check out my packet handler code for TFC Here
  6. I have another gui, specifically GuiKnapping for rock knapping, it does not use a tileentity, and it works perfectly bud. You can check it out Here and the associated container Here. It doesn't really do much except act as a 5x5 crafting area but maybe it'll help. TFC is coming along nicely. I dare say that most of my code isn't as crappy as it used to be
  7. jimmy is your Gui by chance extending a custom GuiContainer class? Mine was. As soon as I had it extend the base GuiContainer class it works perfectly. The old 1.2.5 code was mucking it up
  8. Yeah my code is based off of the ironchest code. As far as the clicking thing. I stepped through it and its definitely doing more than its supposed to. In my working logpile container I see the slotClick method fire off twice. Once on the server and once on the client. But in the workbench where I'm getting the same issue as you, the method is firing 4 times. twice for picking the item up(client and server) and twice again(which can only mean that its placing the item back). The fact that the containers work with one container type but not with another is the other oddity
  9. This can't be completely right. I have been running into this issue as well but it appears to be intermittent. I'm actually seeing a whole host of network related issues. My log pile containers work about 50% of the time. When I'm actually able to open the gui, the slot click actions work perfectly. I don't need to do the custom workaround. However when I try to use my custom workbench, I get the error every time. I've gone over the code countless times and the two containers are very similar yet one lets my pick up items and the other doesn't. Also upon stepping through the code what I think is happening is that its sending two packets. One for picking up the item and another for placing it back down. So you're canceling out your own action. That's what I think is occurring at least.
  10. no it looks like that should work to me.
  11. You'll need to fix the method by doing //This method should be run on each block around the stone that increases the growth public void updateAdjacentCrop(World world, int x, int y, int z) { if(Block.blockList[world.getBlockID(x,y,z)] instanceof BlockCrop) { //schedule the update here. } }
  12. try doing Block.blockList[world.getBlockID()) instanceof BlockCrop that should point you the right way
  13. Since growth in MC is handled via a random tick, what you could do is in your tileentity's update loop use world.scheduleBlockUpdate on each crop block within range. OR you could manually increase the metadata for each crop block in range which should have the same effect. for wheat at least. The first solution is better as you are letting the crop do the update itself.
  14. It doesn't work like that anymore. I have several GenLayers that handle rock layer formation and rainfall among other things. Temperature is now based in large part off the distance from 0 on the Z axis. Every single block has a lot of things that it takes into account to determine temperature. I call to my Climate class to get the temperature which in turn gets the information provided by my custom worldchunkmanager class. Biomes store elevation and that's it. They really shouldn't even be called biomes anymore. In World.canSnowAt it gets the biome and does a check for the temperature of that biome which is consistent across the entire biome. I need to be able to get the temperature from the xyz coordinate, not the generic biome temp that never changes. In short, I need to completely circumvent the contents of World.canSnowAt and replace it with my own code. Edit: Looking at the RenderGlobal.renderSky method shows how I would see going about doing this. If your provider has a WeatherProvider then it would call that code instead of the World.canSnowAt code.
  15. That's the issue. Biomes have nothing to do with the temperature anymore for me. And rainfall in biomes isn't related to actual rain. Its only used for world gen. I need to be able to be able to completely circumvent the Biome class all together. I probably do more biome editing than anyone with TFC . Lex tells me that a world api is being worked on but I've gotta figure out something in the mean time because this means that it can no longer snow in my mod.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.