View Issue Details

IDProjectCategoryView StatusLast Update
0002373Industrial-Craft²machinespublic2018-05-28 18:44
ReporterOneEyeMaker Assigned ToChocohead  
Status resolvedResolutionduplicate 
Fixed in VersionBuilds for MC 1.12.x 
Summary0002373: Kinetic turbines loose rotors
Firstly, I know that this issue partially duplicates 0002326 and 0002190.
I found, that Wind and Water (kinetic) Turbines loose rotors. At first glance it occurs randomly.
But after testing I found, that *it isn't*:
1) Turbines loose rotors just client-side. In other words, its GUI writes, that there's no rotor; but connected Kinetic Generator continues to produce EU.
2) It occurs on specific item damage (of rotors) - 65535 - 65536.

For testing I installed dev. env. with IC2 as dependency. And after research I found, that NetworkManager of mod writes damage of ItemStack as short value.
For items with such big maximum damage as rotors it can cause overflow problems.
I guess this is the cause of current bug (GUI glitch).
Steps To ReproduceHow to reproduce:
1) Place Wind/Water turbine in world in appropriate place (where one can work)
2) Connect Kinetic Generator to Turbine (and, optionally, some energy storage to it)
3) Cheat rotor with damage near 65535-65536. Like so:
/give @p ic2:rotor_carbon 1 65500 {advDmg: 65500}
/give @p ic2:rotor_iron 1 65500 {advDmg: 65500}
4) Place this rotor in Turbine.
5) Wait a minute.

Result: Turbine shows, that there's no rotor, but Kinetic Generator continues to produce energy.
Additional InformationTested with:
Forge and
IC2-experimental 2.8.76 and 2.8.79
TagsNo tags attached.
Minecraft Version1.12.2


duplicate of 0002190 resolvedChocohead Wind mill loses its rotor randomly 



2018-05-26 12:10

reporter   ~0005667

After more testing I found following.
After saving and reloading world with Turbine with lost (glitched) rotor, client receives rotor's data. But one does it incorrectly (due to int-short conversion).
For example, for Iron rotor (which glitches at 0000012:0000024% of it's full durability) I get rotor with 98-99% of full durability (almost the whole).


2018-05-26 17:11

developer   ~0005668

I did suspect it was due to underflowing, but the nature of the reports suggested it was happening at other times too. Time to switch the damage to be saved in NBT I'd say.


2018-05-28 10:15

reporter   ~0005669

For testing purposes I created class for rotors, which uses just NBT (all standard metadata-based methods are overriden to use NBT too). With such rotor this bug doesn't happen at all.
(I attached this class file, if you want to look at it). (6,477 bytes)


2018-05-28 18:44

developer   ~0005672

As suspected it was setting the normal damage to match the NBT's that did it, stacks are empty once the damage is larger than 65535 (or smaller than -32768). The snapping back is odd, but fundamentally irrelevant as the NBT probably wasn't.

Fixed in IC2 2.8.81

Issue History

Date Modified Username Field Change
2018-05-26 07:35 OneEyeMaker New Issue
2018-05-26 12:10 OneEyeMaker Note Added: 0005667
2018-05-26 16:17 Chocohead Relationship added duplicate of 0002190
2018-05-26 17:11 Chocohead Status new => confirmed
2018-05-26 17:11 Chocohead Note Added: 0005668
2018-05-28 10:15 OneEyeMaker File Added:
2018-05-28 10:15 OneEyeMaker Note Added: 0005669
2018-05-28 18:44 Chocohead Assigned To => Chocohead
2018-05-28 18:44 Chocohead Status confirmed => resolved
2018-05-28 18:44 Chocohead Resolution open => duplicate
2018-05-28 18:44 Chocohead Fixed in Version => Builds for MC 1.12.x
2018-05-28 18:44 Chocohead Note Added: 0005672