Posts by Chocohead

    Every reactor in the world randomly picks which tick in a given second it will update in, so placement within the world will have no impact on whether reactors tick together or not. The idea is that if it's completely random they should evenly balance out across the 20 options.

    Ultimate Reloaded uses a completely different recipe set, I'd recommend double checking recipes using JEI to see how they've changed. In short though you won't need a hammer at all (hence it has no recipe) and likely won't need cutters either unless you're (de)insulating cables in world.

    Making an IC2 addon isn't substantially more different than making a normal Forge mod, you've just got either IC2's API or all of IC2 as a library to compile with (alongside Forge and Minecraft) too. All reactor components are marked using a single interface IReactorComponent on an Item subclass. How the implementation of that is done is what determines how the component reactors, as you might have seen from the threads on adding custom fuel rods.

    Given that you copied the uranium code, there'd be a big hint to compare what you've got vs what that has ;)


    Java
    1. if (!heatRun && getCustomDamage(stack) >= this.getMaxCustomDamage(stack) - 1) {
    2.     reactor.setItemAt(x, y, ItemStack.EMPTY); //Or whatever your fuel rod produces when it runs out
    3. } else if (!heatRun) {
    4.     stack.attemptDamageItem(1, itemRand, null); //Hit the stack, the reactor's world random could be use instead if you wanted
    5. }

    Is missing off the bottom of processChamber

    I did mention what you'd need, but you've had long enough to work it out so you'll get the answer anyway :P

    Block cutting blades are just items which implement IBlockCuttingBlade which is fairly clear on how to implement given all you have to do is return the hardness in the one method it specifies ;)

    There isn't a set way that a fuel rods generates heat, it's all down to how the fuel rod itself implements it. Hence you can have MOX for example that will scale with heat in a fluid reactor (as annoying as it might be) whilst uranium doesn't care. If you don't want the rods to scale their heat generation with what's around them you don't need to do that either, you could literally just IReactor#addHeat(IReactor#getMaxHeat() * 0.0004F) in processChamber. If you copy the uranium fuel rod in comparison, it will work the same as uranium fuel rods do.

    An addon style we've not seen in a long time, looking forward to see how it turns out.


    As for your NBT issue, the ItemStack constructor is a little misleading in that whilst it takes in an NBTTagCompound, that's only for Forge's capabilities and not the ItemStack's own NBT. You'll want to do something like

    Java
    1. addCanningRecipe(input.forExactStack(makeMagazine(0)),
    2. input.forStack(new ItemStack(cartridge, 20)),
    3. makeMagazine(ItemMagazine.MAX_AMMO);
    4. ...
    5. private static ItemStack makeMagazine(int ammo) {
    6.     ItemStack magazine = new ItemStack(magazine);
    7.     magazine.setTagCompound(ItemMagazine.getNBTForAmmo(ammo));
    8.     return magazine;
    9. }

    That way the NBT is properly set for the ItemStack (using setTagCompound).

    Greg's completely misread the crash, clearly the conflicting recipe is the one you're adding, as that's what's in the crash report :P There will be a warning in the log immediately before which recipe it is conflicting with that was already present.


    The file is loaded in top to bottom, so any recipe that is above your additions will be loaded before it and any below will be after. Thus all you've got to do is look above your additions to see if anything else takes steel as an input. Hint, there is:

    Code: compressor.ini
    1. ; Refined Iron Ingot
    2. OreDict:ingotSteel*9 = ic2:resource#steel_block

    You'll want to comment out/remove line 59 then your recipe should work.

    Just posting so you know, JEI is throwing an error with Advanced Solar Panels.

    I have the error it throws posted over HERE.


    Versions

    • Advanced Solar Panels-4.2.0
    • jei_1.12.2-4.14.3.238

    There is more protection against that in the latest update of Advanced Solar Panels, still not entirely sure of the cause though. Most likely config related so I'd keep an eye out in the logs for anything unexpected.

    Where would I copy all of the methods from? When I used the eclipse add unimplemented methods feature, it put some methods that I found in ItemReactorUranium, there were also some in ItemReactorUranium's superclass, do I just copy and paste them and change "protected ..." to "public ..." in the method headers?

    The fact you got some from both is what you'd expect, ItemReactorUranium will override some of them but doesn't need to override all of them as the superclass will handle them sufficiently. All you've got to do is make sure the ones that ItemReactorUranium implements you implement likewise and the ones that it doesn't you handle the way the superclass does. Providing you're wanting it to act like uranium fuel rods at least.

    Should my constructor look like this?

    If you're wanting to support dual and quad rods rather than just single ones (like uranium does), then yes. Otherwise it's doing more than it necessarily needs to do.

    Also, with the import ic2.core.item.reactor.ItemReactorUranium.ItemStackCoord, eclipse says that ItemStackCoord isn't visible, do I need to copy and paste that method into my class, change it to public, and @Override it?

    You'll want to copy that, it's only designed to be used from ItemReactorUranium thus is also private.

    With my previous post in mind, here is my ItemCoaxiumRod.java file, there is one problem: The item itself isn't available in the Creative inventory. When I add the ModItems.ITEMS.add(this), I get a NullPointerException (crash log below).

    You've not set the registry name of your items, thus when you try and register them it will crash. Given that you're already passing the name into your constructor, you might as well use it:

    Java
    1. public ItemCoaxiumRod(String name, int cells)
    2. {
    3. super();
    4.         setRegistryName("mymodid", name);
    5. numberOfCells = cells;
    6. }

    Of course there are other places you could do it instead (such as on the field as setRegistryName returns the item back to you), that's down to code style.

    You don't extend them both as IReactorComponent is an interface. You'll end up with something along the lines of

    Java
    1. public class ItemCoaxiumRod extends Item implements IReactorComponent {

    ItemUranium as a class doesn't exist, it was just to save me having to type out ItemReactorUranium each time. It has the logic that determines how uranium rods act, whilst its superclass AbstractDamageableReactorComponent has the default implementations of IReactorComponent (some of which are overriden in ItemReactorUranium) and it is AbstractDamageableReactorComponent's superclass ItemGradualInt which has the NBT damage storing/loading in.


    It's worth noting that ItemGradualInt especially is used in multiple places so some of it won't be especially necessary for your usage I shouldn't think (such as implementing ICustomDamageItem), overriding getDamage, setDamage, isDamaged and isDamageable is probably all you technically need. Although overriding getDurabilityForDisplay and getMaxDamage is very much advisable too.