[1.10.2 - 1.12.2] IC2 Cables disconnecting from tile entity on block change

turbodiesel4598 · Dec 11th 2017

Hi there,

I am developing a mod that adds machines that can accept and emit IC2 energy. In most cases, the API has worked flawlessly for me, but there is one particular issue that I face. The problem is that IC2 cables will disconnect from the machines when they switch on (or off is the game/chunk is loaded while the machine is on). If the cable is broken and replaced, the cable does still not connect to the machine, so I can only guess that the tile is no longer being recognised as an energy sink/source.

I am almost certain that this happens because, when the machine turns on (or off), the block type changes between 'active' and 'idle', similar to how a regular furnace behaves. I have made sure that the tile entity isn't refreshed when this happens by overwriting the 'shouldRefresh' method, so the issue isn't there.

Thanks in advance for any help or suggestions on how to stop these disconnections occuring

Chocohead · Dec 11th 2017

It sounds like when the block type changes the E-net is losing the registration for the tile entity at the same position. Do you have your code on somewhere like Github? That would probably help in diagnosing further to see what's going wrong.

turbodiesel4598 · Dec 11th 2017

Quote from Chocohead

Do you have your code on somewhere like Github?

Sure - if you need links to any more classes, let me know, but I think these will be the relevant ones:

Processors - The static nested classes correspond to the individual machines. The only method they overwrite is the seemingly troublesome 'setBlockState'.

TileEnergyItemProcessor - One of the three very similar processor superclasses. 'setBlockState' is called at line 104 if the block starts/stops.

TileEnergy - This is the superclass for all energy-wielding tile entities. There are various methods here that move the tile in to and off of the E-net when necessary.

NCTile - The superclass for all NC tile entities. At line 46, the 'shouldRefresh' method has been overwritten to make sure that false is returned when the block type changes between 'idle' and 'active'.

BlockManufactory - This is an example of a machine's corresponding block class - at line 32 we have the 'setBlockState' method from before, which changes the block type.

Aroma1997 · Dec 11th 2017

Can you send a log file?

Player · Dec 11th 2017

A log with logGridUpdatesVerbose turned on in IC2's config and as few IC2 ENet participants in the world as possible should help debugging the grid changes, especially whether shouldrefresh does what it's supposed to.

You can also use IC2:debug_item to rightclick your tile entity before and after it changes to verify that it's still the same TileEntity instance after changing state. If the TE class doesn't override toString, the reported hash code (in <cls name>@<hash>) shouldn't have changed. Keep in mind that it reports for both server&client, the TE instances between server and client should be different.

turbodiesel4598 · Dec 11th 2017

Ok, here is latest.log for the debugging, and here is the important part of the Forge log for the E-Net info.

I enabled the config option, generated a new world, placed down a full MFSU, cable and NC machine - the cable connected to the machine properly. I used the debugger, then activated the machine by giving it something to process, and the cable disconnected. I then used the debugger again as the machine was running off of its internal energy.

It seems, looking at lines 41 and below on the Forge log, that the machine is being removed from the E-Net.

I think I have found a solution, and it seems to work in game - before the block type changes, I remove the tile from the E-net. Then the update happens and neighbours are notified. Finally, the tile is added back to the E-net. Is this the best way of going about solving the issue?

Player · Dec 13th 2017

These removals don't (shouldn't) happen by themselves, so some api call to removeTile/EnergyTileUnloadEvent must be leaking through. The log shows that the TE instance is still the same, which implies that shouldRefresh is working.

I'll add some debug logging for ENet API accesses to track the source, it currently only logs some internal processing steps that aren't even on the same thread.

Player · Dec 13th 2017

I've pushed the new log option, see debug -> logEnetApiAccessTraces, which should point you right at the issue.

Note that FML may log to fml-junk-earlystartup.log in some cases.

Share