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.

You need to update to 1.12.2 (or 1.12.1 at the very least), the old 1.12.0 Forge versions for it don't work with IC2 anymore

Report it to Extra Planets I guess, if it's passing the wrong blocks about it will likely cause other crashes if left unfixed.

That looks like a bug in Extra Planets, it is trying to get the material of an IC2 machine whilst giving it the state of a liquid nitrogen fluid block.

That'll be down to how you've implemented TileEntityTest. The energy net only expects one energy load/unload to be sent for an instance before the corresponding unloading/loading happens (or not as the case might be for an unload from leaving an area/the world). Feel free to post what you've got here if that's not obvious enough to fix it.

If you're trying to run a jar rather than launch from a class you need to specify explicitly: java -jar Ic2ExpReactorPlanner.jar

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

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

Is missing off the bottom of processChamber

The normal jar is obfuscated to work with a normal jar, you'll need to either obfuscate your mod to test it (which is kind of annoying, especially for debugging) or deobfuscate IC2's jar to test using it. You'll want something like BON for doing that.

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

    @Override
    public double getDurabilityForDisplay(ItemStack stack) {
        return (double) getDamage(stack) / getMaxDamage(stack);
    }

    @Override
    public boolean isDamageable() {
        return true;
    }

    @Override
    public boolean isDamaged(ItemStack stack) {
        return getDamage(stack) > 0;
    }

    @Override
    public int getDamage(ItemStack stack) {
        if (!stack.hasTagCompound()) return 0;
        return stack.getTagCompound().getInteger("fuelRodDamage");
    }

    @Override
    public int getMaxDamage(ItemStack stack) {
        return 40000; //Or how ever much damage you want
    }

    @Override
    public void setDamage(ItemStack stack, int damage) {
        NBTTagCompound nbt = stack.getTagCompound();

        if (nbt == null) {
            stack.setTagCompound(nbt = new NBTTagCompound());
        }

        nbt.setInteger("fuelRodDamage", damage);
    }

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.

The rifle doesn't seem to be finished yet, it's just an item which doesn't stack at the moment.

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

addCanningRecipe(input.forExactStack(makeMagazine(0)),
                 input.forStack(new ItemStack(cartridge, 20)),
                 makeMagazine(ItemMagazine.MAX_AMMO);
...
private static ItemStack makeMagazine(int ammo) {
    ItemStack magazine = new ItemStack(magazine);
    magazine.setTagCompound(ItemMagazine.getNBTForAmmo(ammo));
    return magazine;
}

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 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:

; Refined Iron Ingot
OreDict:ingotSteel*9 = ic2:resource#steel_block

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

Quote from BookerTheGeek

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.

Quote from SM84CE

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.

Quote from SM84CE

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.

Quote from SM84CE

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.

Quote from SM84CE

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:

public ItemCoaxiumRod(String name, int cells)
    {
        super();
        setRegistryName("mymodid", name);
        numberOfCells = cells;
    }

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

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.

In the [balance / uu-values / predefined] section of the IC2.ini config file you'll want something like

AdvancedSolarPanel:asp_crafting_items@9 = 500

Where 500 can be substituted by how many mb of UU it takes to replicate. I think at least, if it doesn't work I can double check for you.

Quote from Romzes

@Chocohead, Advanced Chainsaw doesn't want to work with mod TreeChopper. Can you add compatibility?

You can add it yourself using the TreeChopper config, you'll want to add gravisuite.advancedChainsaw to the "Whitelisted items" list