Posts by Chocohead

    I checked that with the chamber, it returned true for has reactor, but nil for all the get methods, which was what prompted me to post that.

    Most strange, if it has an attached reactor to get the values from it shouldn't have trouble doing it. I presume wrapping the reactor itself is getting valid values rather than nil too?

    And how would I do the Lua table thing? I'm not really experienced with Lua

    That was an idea for the addon to give you a table as a return value for a getReactorStatsesque function. Just a concept to allow much greater monitoring (if you were so inclined) without having to add dozens of individual functions. Although of course individual functions are friendlier to performance when being polled frequently.

    You should really consider making a place where we can get all your tiny addons and such (like FullDrop and this one), they are REALLY useful!

    I don't think I've made that many in the grand scheme of things. Normally it's just a need comes up for something small and I've got time to make it.

    hen I wrap a reactor chamber, I can't get any outputs, when I call getEUOutput() on a chamber, I get nil, even though there is a reactor attached. Is it a bug, or 8s this my fault?

    What's the result of hasReactor on the chamber? If it's managed to attach properly it should be true (otherwise that would explain why it wasn't getting anything else).

    could you also make a method to get the tick remaining on the fuel rods? This would possibly be an average...

    Given it's Lua you could get a table of stats like minimum remaining time, time remaining per slot, etc. Maybe that's encouraging micromanaging a little too much though? ;)

    It's worth noting that if you're not already comfortable with Java making an addon is made harder, as you've got to understand what Minecraft, Forge and IC2 are doing (to varying degrees) to get everything working as it is. Equally if everyone is suddenly into making reactor addons I can make an example mod just to give an idea of how things works; would be more about demonstrating what you need to do to work with IC2 rather than teaching Java but if there's interest I can get around to it.

    The video was posted a little over a week before the pack was, and there were additional recipes changes between when it was recorded and when the pack was publicly released. Relying on the IC2 wiki using the default recipes therefore is not necessarily the best of ideas when the recipes have been changed (repeatedly) by the modpack; hence blindly aiming for iron plates for example might not actually be what you want to do. I'd strongly recommend looking at the recipes of what you are aiming to make to see how they have changed, rather than the individual components you expect to need (given that said components might well be different).

    It's not IC2 adding these recipes as far as I'm aware, it is almost certainly Railcraft itself (especially if you're only using IC2 and RC). I would suggest making an issue on the Railcraft Github if this is actually the balance it is currently using given that it is certainly worth double checking to say the least.

    I tentatively agree with the first part of this - in 1.7.10 a simple design with 1 uranium rod and 1 heat vent shows 8 HU/s output (in the reactor gui), but in 1.12.2 is shows 160 HU/s. I was hoping for confirmation from Chocohead, but he has yet to respond in the GitHub issue. Confirmation from someone else who has knowledge of IC2's inner workings for multiple MC versions would be nice - in-game testing doesn't entirely rule out the possibility that the output was buffed while things like HU to EU conversions were nerfed to match.

    The fluid reactor output units have been an issue for a long time now. There is disagreement within the code too about whether the value is meant to be in HU/s or HU/t, fairly certain in one 1.12.2 build it was switched from ticks to seconds to account for the fact the output value was 20x too high despite the EU value being correct for being per tick. I'm not aware of any balance changes modifying fluid reactors that much, only the slight rationalisation of the steam boiler which could theoretically have changed the heat consumption rate of designs slightly to be more predicable. I'd presume if 1.7.10 was showing conveniently 20x less than 1.12.2, the 1.7.10 value is in ticks and 1.12.2 in seconds (which I think it is in game, would have to check though).

    It seems that Chocohead only goes on the forum every day - He has not replied to anything in IC2 bug tracker for about a week.

    I still check the bug tracker daily but often won't flag things unless I've actually looked into them in case someone else beats me to it. There's a collection of things that need fixing that FTB Ultimate Reloaded found too which will probably all get fixed together. Although some of the bugs on the tracker are easier to deal with than others.

    Since I've seen a couple of requests for this might as well make it a little more official. Tiny ComputerCraft addon that means wrapping a nuclear reactor as a peripheral will now have the following methods:

    • getHeat - The current reactor heat

    • getMaxHeat - The heat amount the reactor will explode if reached
    • getRawEnergyOutput - The amount of energy the reactor is producing before converted to EU
    • getEUOutput - The amount of EU the reactor is producing
    • isActive - Whether the reactor is current running
    • isFluidCooled - Whether the reactor is fluid cooled

    Wrapping a reactor chamber offers all these methods, and hasReactor - whether the chamber can find the reactor it is attached to

    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 ;)

    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.