Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

CowedOffACliff

Members
  • Posts

    46
  • Joined

  • Last visited

Converted

  • Gender
    Male
  • Personal Text
    Linux user.

CowedOffACliff's Achievements

Tree Puncher

Tree Puncher (2/8)

4

Reputation

  1. this.provider.worldChunkMgr.cleanUpCache() calls this.biomeCache.cleanupCache() which is your BiomeCache subclass. Make sure the this.biomeCache is actually being initialized correctly, and then go look at the cleanupCache() method in the BiomeCache base class since I don't see an implementation of it in your file. Assuming the crash is actually being caused in this chain somewhere continue to trace from BiomeCache.cleanupCache().
  2. If you bothered to skim through the method names in ServerConfigurationManager I wouldn't need to be more specific.
  3. usePortal was removed from the Minecraft file. Dimension transfer is now handled in MinecraftServer.getServerConfigurationManager();
  4. Just re-copy the code for the default teleporter. A lot of stuff changed and it added a call to a new function (name may still be obfuscated) that is what actually handles making a new portal now.
  5. You're going to want to look at the WorldChunkManager for the overworld (WorldChunkManagerGenerate or something like that) and ChunkProviderGenerate to see how the normal game does this. The GenLayer files will be important for this. You may end up having to do a full re-implementation of GenLayer and its subclasses like I did at first to get things working. GenLayer is important because its subclasses do things like setting biomeIDs for coordinates and changing biomeIDs are locations into other biomes (i.e. desert to desertHills). GenLayer also does some terrain manipulation that creates things like rivers and mushroom islands. I'll warn you now that custom biomes can be a PITA. Make sure your reference to the WorldChunkManager and ChunkProvider for your dimension are always the correct ones during world generation, otherwise you could end up with frustrating NullPointerExceptions. Also, make sure that whatever array of Biomes/biomeIDs you end up using (you'll understand where this applies later) is never given a null value or an invalid biomeID (say, for a biome that doesn't exist). I've gone through a lot of pain getting my dimension project to work, but currently it generates properly with caves, ravines, biomes, etc. It's all possible, just not for the faint of heart.
  6. Forge has funtions to register tools and tool effecvtiveness on initialization. Also, when block metadata changes you should replace the old block with a new one with the new valuem which will cause it tup update.
  7. Okay, assuming you're trying to use an actual item inside the inventory to render the held item, and not something odd (it was a little ambiguous), then you have access to the ItemStack in the inventory, and if you have access to an ItemStack then you can get the metadata value of whatever the ItemStack is and evaluate that.
  8. Wait you're using a custom ItemRenderer or something aren't you? Because that looked 3D
  9. As far as I know it should do that automatically if you map the block metadata properly to an item that stores it. My block has no problem having different textures in the inventory based on the ItemStack's damage value.
  10. Use the Block.getTextureFromSideAndMetadata(int side, int metadata){} method to set what texture from a spritesheet the block should be using, and then use a custom BlockRenderer to cause a texture update based on metadata. When I needed a metadata sensitive renderer for my block that acts like sand, I passed in the metadata value, stored it in a field, and applied it to all of the places that render the sides of the block. Here's a copy of that file: It's basically a clone of RenderFallingSand but I moved BlockRenderer.renderFallingSand into a local method and renamed it to be relevant. Oh and HINT: Use a spritesheet for blocks, not seperate files. It makes things convenient.
  11. You should have been looking in ItemTool the entire time...or possibly the superclass of ItemTool if it extends something besides Item. ItemSword wouldn't have had a lot of the code you actually needed to see because all of that is invisibly inherited from its superclass, just like all of the other tools, which is kind of the point of the ItemTool class in the first place.
  12. Sorry, I just got in high school. You'll be a couple steps ahead then I would argue that you can't really make assumptions based on age/education. In my high school you learn basic trig in geometry, and then real trig is entirely optional.
  13. Pretty sure something besides Forge causes this bug.
  14. In the portion of code that will open the GUI run a check against the player's currently equipped inventory item. EntityPlayer.inventory (which is an instance of InventoryPlayer) will have methods for getting the currently equipped item.
  15. I haven't messed with keybinds, but to store permanent information for the item there are two things you can try: 1. Using metadata in the item and having it act based on the metadata values 2. Using NBTTagCompounds; enchantments are an example of how items do this (all enchantments are stored in tag compounds).
×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.