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.

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

Files

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.

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.

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.

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.