NuclearCraft-2.5a--1.12.2.jar
Mincraft 1.12.2
Forge 14.23.1.2556

NuclearCraft in 1.12 is very very broken, any time a tile entity, excluding reactors, goes idle it will not start up again unless updated by redstone being placed next to the machine. This makes the mod very unplayable or ridiculous to keep running.

Here is my solution to the problem at the moment which is silly:

Mechanical user placing redstone on top of a machine. Block breaker breaking it and cycling it back into the mechanical user.

Well that doesn't really solve the problems because it also happens with items and liquids as well. All of the inputs and outputs become inaccessible, not just power.

Water will not be pumped in and gases cannot be pumped out using Thermal Expansion pipes.

• Edit: Even if you can manage to use some other mod to force items / liquids into or out of the machine they will not turn back on, they are dead tile entities.

I play with this mod in 1.12 and i also automated the electrolyser.
For the Fluids use also Immersive Engineering pipes (simply put one at the end of your TE Liquid pipe).
For export I use Fluid Import Bus but mekanism pipes or immersive engineering again, also work.
Nuclear Craft doesn't work with Thermal Expansion in 1.12.

For Items use Hoppers for export (I did not test import).
And Applied Energistics export or interfaces for import into the machine.

In 1.12 Nuclearcraft has Problems with RF, for now use Immersive Engineering cables.

Would just like some clarification - is the issue that NC machines aren't updating correctly in general, or that they aren't playing nice with TD ducts?

In my opinion it's just a problem with TD Item, Fluid and Flux Ducts.
But till now I could not isolate the Problem. You may should look into the TD Code and compare it with what others do.

Turns out this is also a 1.10/11.2 bug - again, it's only certain conduit types such as thermal dynamics that don't work. Will do some searching!

I have had issues with NC machines not running while taking power from Immersive Engineering connectors, they just stall at some point. I found a solution of placing an uranium RTG touching the machine seems to fix it.

Could it be something to do with the way the NC machines pull power?

The way RF and Forge Energy used to work (it may not now) was that energy sources pushed energy and energy sinks accepted energy. The sources were not be pulled from and the sinks did no pulling.

The bug also affected Integrated tunnels energy tunnels, here is what I ended up having to do:
Electrolysers:

supercoolers:

Could it be an error in the code NC uses for saying how much power it requires? when sources push energy, they often do a check to see how much power is needed, all of the machines I had that were affected had speed upgrades in them, infact, I didn't notice the bug at all until I added speed upgrades

This one never stalled for example:

The hoppers are for avoiding that crash from when it checks blocktype for opening gui :D

Ok, after a lot of testing, for now, I am forced to conclude that this isn't an NC bug, or at least is not solely an issue with NC - I just tried setting up a simple furnace automated using ducts and the item movement was totally broken.

The only solution for now is to not have the block texture change when it starts/stops running, so for now, that will have to be disabled until I find a better solution.

Sure thing - I'm about to release 2.6, and I will then update the repo :)

Ok, once that is updated I will look into the rotation issue, that at least is something on NC's side, if the ducts don't like vanilla furnaces either, I will assume that is their problem instead, and wait for that to be fixed before looking into any fixes for NC.

I suspect this and #188 are the same root cause, and if so, it should be fixed by simply adding this to your root TE class:

https://github.com/Thutmose/Pokecube/blob/1.10/Pokecube%20Core/src/main/java/pokecube/core/blocks/TileEntityOwnable.java#L46-L66

where instead of oldState.getBlock() != newSate.getBlock() you compare whether the two blocks actually correspond to the same machine.

Then you can remove the stuff in here for re-validating TEs:

https://github.com/turbodiesel4598/NuclearCraft/blob/master/src/main/java/nc/block/tile/processor/BlockChemicalReactor.java#L33-L47

I already tried this after a conversation on the Forge forums to no avail. The issue seems to be rooted in the fact that NC machines are comprised of two individual block types - one for each texture (idle and active). When the block type changes, some pipes such as TD's or Integrated Tunnels' forget that the machine is there.

For whatever reason some pipes/wires such as EnderIO's or Galacticraft's have been made to cope with something like that happening.

Ahh, then you should probably swap to using a different blockstate instead of the seperate block entirely, here is an example of one of my tiles that is rotatable and has a boolean based block state if it will help:

https://github.com/Thutmose/Pokecube/blob/1.10/Pokecube%20Core/src/main/java/pokecube/core/blocks/tradingTable/BlockTradingTable.java

Not sure what the scope of the changes for that would encompass though...

Do the Integrated Tunnels/TDs work with vanilla furnaces? those work like yours currently do...

Exactly - I think it would be a reasonably simple change code-wise, but it would probably be a major game-breaker, so I will have to make sure it is very clear that updating to a new version where that change had been made would potentially break a lot of machines, especially if active.

Thermal Dynamics ducts don't play nicely with the vanilla furnace at all, no.

If you push the current changes you have to github, I can see about looking at it on my end, if you have a simple way to replicate the issue in development environment, I can at least look into the rotation issue.

Well technically it's NC's fault because its machines act like Furnaves, which we already established don't work well with most mods' piping.

That is the fault of most mod's piping. Mods should always work with vanilla blocks.