Jump to content

sequituri

Forge Modder
  • Posts

    669
  • Joined

  • Last visited

Posts posted by sequituri

  1. What are your opinions on setting out a separate class file for the detection of when my mod items damage entities they store NBT data.

    That way each of my tools doesn't need 20+ lines of code.

    It just refers to the separate class file?

     

    Any ideas or tips?

     

    :P

     

    I was saying earlier that a separate class is not the way to go. However, as CoolAlias was so kind as to point out, if you can refactor most of the guts and hard stuff into a common base class, then your weapons and such could just be declared as subclasses and gain all of the functionality that you don't override. This is good old everyday java programming, so I hesitated to mention it. Check out how ItemTool works for Axes, pickaxes, Shovels, etc.

  2. Objects are passed by value (of object reference) in java (unless the argument an expression). It looks like the single reference is getting modified each time through the loop. But, that explanation doesn't make sense. So, ignore me.

     

    I probably would have tried something like this first.

    LanguageRegistry.addName(new ItemStack(redstoneClock, 1, ix), subNames[ix]+"stone Cloth");
    

    If that didn't work, then I have to dig deeper. Sorry, I cannot be more helpful, not much to go by.

     

    [editted for benefit of future readers with similar problem]

  3. EntityLiving and EntityPlayer are both subclasses of EntityLivingBase, but you cannot cast one to the other unless it is an X instanceof Y (you can cast both to EntityLivingBase, if that's what you need, though.) SO, put an 'if' in there to catch that and use logic.

    That has nothing to do with the topic, he is trying to use a method in EntityLiving, not EntityLivingBase, so he needs to check if the entity in question is an instanceof EntityLiving before casting. Stop confusing people with random comments.

     

    I don't find your attitude helpful. Perhaps you could keep your snide comments out of the fora.

  4. Ok, I've decided that the easiest way to support all axes and those from other mods would probably be to register them with the oreDict under "toolAxe".

     

    Not at all. Why would any other mod register one of their axes in an "ore" dictionary? Answer: they won't. Use the instanceof ItemAxe or at least instanceof ItemTool (Here you would check the name for having 'axe' or 'hatchet' in it but not pickaxe) Any coder with any brains is likely not going to make an axe in some other class.

     

    The OreDictionary should be reserved for crafting.

     

    You should register crafting recipes in Init eventhandler not preinit.

     

  5. You don't know how to prevent class cast exceptions? It crashed because whatever code you ran is indiscriminately casting every single entity it comes across as an EntityLiving, when the entity may very well not be one, such as the EntityPlayerMP in your crash log.

     

    Solution: instanceof

     

    EntityLiving and EntityPlayer are both subclasses of EntityLivingBase, but you cannot cast one to the other unless it is an X instanceof Y (you can cast both to EntityLivingBase, if that's what you need, though.) SO, put an 'if' in there to catch that and use logic.

     

  6. [Okay, while I was typing this, deiseiben07 posted.]

     

    FurnaceRecipes.smelting().getSmeltingList().remove(new ItemStack(Blocks.iron_ore)) will not work.

     

    The reason is simple if you understand hashmaps. The key is looked up in an array of hash buckets indexed by the hashCode() return value. Then, if the key is not equals(Object o) to the one to remove/add/get the object looks down to list or hash bucket and checks equals() again (some do a rehash, but not this implementation).

     

    Now to the actual reason it fails. No two new ItemStacks will generate the same hash (under normal circumstances.) So, every ItemStack will not match an existing key, and since ItemStack does not implement either hashCode() or equals(o), the Object (superclass) methods are used (they amount to the address of the instance as hashCode). If you put an ItemStack in the map, it stays but will never match anything but that exact reference, ever.

     

    You therefore must iterate through the recipes, check with ItemStack.areItemStacksEqual(s1, s2) -- yes, really slow... but the only way right now.

     

  7. Sequituri – Thanks but it wasn't there. I only have reference libraries (not dependent libraries) and under no package was there a class which listed a method to obtain the fuels

     

    Then I cannot help you. When I followed the instructions LexManos provided, it just worked and all the code was there. I'd suggest scrapping it, redownloading Forge, and following the instructions for setting up the project. Beyond that, I got nada.

  8. Yeah well, the SimpleChannelHandlerWrapper(Class handler, Side side) is bugged, as it never calls super(Class inboundMessageType... ) to get the matcher to cache the class and message type. The default constructor for the superclass relies on the parameter matcher to find it in the cache (which it won't because it was never used before) and fails when it is not there.

     

    This should be addressed in bugs & software support.

  9. True that.

     

    But, my understanding was that the OP was talking about making a mod that didn't necessarily depend on Forge. I guess that was a misunderstanding. Yes, I would have suggested the helper if I had understood correctly. Sorry for piping in.

  10. Then it looks like you are using some old 1.6.x code and expecting it to work. It won't work on 1.7.x if you don't get rid of Block and Item IDs that have no further purpose. Blocks and Items are registered as their instances now. The ID is auto-assigned and calling a constructor like Block(ID,...) should not even compile.

     

    And you'll need to go through all of that 1.6.x code looking for any reference to a Block or Item id (and things like Block.stone etc.) and change them to the 1.7.x way.

×
×
  • Create New...

Important Information

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