Issue description:

Upon breaking and placing a controller, the server goes on a crash loop.

What you expected to happen:

The server not going on a crash loop, ideally not crashing at all.

Steps to reproduce:

1. Place a controller
2. Break a controller
3. Place the controller again
   (As far as I can tell that's it, I don't know the specific setup)
   ...

Version (make sure you are on the latest version before reporting):

• Minecraft: 1.12.2
• Forge: 2836
• Refined Storage: 1.6.14

Does this issue occur on a server? [yes/no]
Yes

If a (crash)log is relevant for this issue, link it here:

https://pastebin.com/jRtwN5PQ

same as #2219

@Darkere Were you able to reproduce this?

I've broken and placed the controller multiple times. Those aren't the steps to reproduce, just the way it happened. I can't identify how it happens. I turned on delete tile entities on forge, and it doesn't crash when I do that, but it also doesn't delete the controller. When turning that feature off again, the server goes back into a crash loop. The only way it doesn't, is if I remove the controller from the player's setup. A setup that uses item conduits, rs conduits, and an interface. My operating theory is that it's an issue with the interface.

No not able to reproduce. Only thing I can think of is that at least part of the old TE is still there.

It's weird. The bug is quite serious and seems like it would happen a lot, yet there are only 2 reports about it.

Lots of pack authors turn on the delete erroring tile entities. And since the problematic block is easily identified server admins will just delete and replace the block.

RS issues are much worse than any other problem. They are a higher priority and can't be fixed by just deleting the issue. Server owners prioritize getting systems back up and hoping it doesn't break again. The crash report also indicates it's an issue in the mod's code, so it's well above people's heads (myself included) but it does seem like it's a misuse of a method.

It's obvious that this is an RS problem. The question is whether this bug is only reproduceable in certain conditions.

McJty on the issue:

This can happen if that tile entity implements an interface that has getWorld()
While TileEntity has a getWorld() too
Which gets obfuscated
However your getWorld() doesn't get obfuscated
And that causes problems outside of dev environment

in Forge Discord.

This just happened on my server, I was adding a new crafting grid which didn't connect. By the time the server crashed the error was throughout the log.

I've narrowed down the pack until its refined storage and ender io, the error still happens even when its client only. It happens the moment the world starts to load. If I'm able to trim down the size of the world save I can send it over.

Running 1.12.2, forge 14.23.5.2847, refined storage 1.6.15 and ender io 5.1.52.

Crash log: https://gist.github.com/Txuritan/a89ee98d1444e7de64ba3e28fcb79933

I took a look myself, first trying out the issue of conflicting getWorld implementations.

In INetworkNode I renamed the getWorld method to getNodeWorld (changing any references to it), which got past the first error but this lead to another error with getPos. I assumed it was the same problem as with getWorld, I renamed it to getNodePos (again changing any references to it).

Doing so allowed me to load my world that caused a consistent crash. I also tested it on my server and it fixed the issue there to. Not sure if this will fix the issue entirely or if its just buried it more.

The problem is that I can't rename it because it breaks compatibility with add-ons

I fiddled around with it some more, at first I thought it was due to the interface's abstract method overriding the abstract class's method, which is not the case. Turns out, getWorld and getPos is being obfuscated due to extending TileBase but in doing so removing the implementations required for INetworkNode. Foresty also had this issue.

The only ways I can think of solving this would be to rename the methods in INetworkNode (breaking compatibility) or make the obfuscator rename the method to the correct name (also breaking compatibility due to the obfuscated names).

Create new methods with non-breaking signatures, move method bodies from old methods into new methods, call new methods in old methods, deprecate old methods with published date for removal. Not an instant fix but you can start calling new methods immediately and fix bug for you. Add-ons have path and time.

I don't know if you need more logs, but I can confirm it still happens on our server

https://pastebin.com/xPkZujkB

• RefinedStorage 1.6.15
• Forge 14.23.5.2847

java.lang.AbstractMethodError: Method com/raoulvdberge/refinedstorage/tile/TileController.getWorld()Lnet/minecraft/world/World; is abstract
    at com.raoulvdberge.refinedstorage.tile.TileController.getWorld(TileController.java)
    at com.raoulvdberge.refinedstorage.apiimpl.API.isNetworkNodeEqual(API.java:366)
    at com.raoulvdberge.refinedstorage.apiimpl.network.node.NetworkNode.equals(NetworkNode.java:293)
    at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1035)
    at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006)
    at java.util.Collections$SetFromMap.add(Collections.java:5461)
    at com.raoulvdberge.refinedstorage.apiimpl.network.NetworkNodeGraph$Operator.apply(NetworkNodeGraph.java:171)
    at com.raoulvdberge.refinedstorage.apiimpl.network.node.NetworkNode.visit(NetworkNode.java:233)
    at com.raoulvdberge.refinedstorage.apiimpl.network.NetworkNodeGraph$Visitor.visit(NetworkNodeGraph.java:210)
    at com.raoulvdberge.refinedstorage.apiimpl.network.NetworkNodeGraph.invalidate(NetworkNodeGraph.java:62)
    at com.raoulvdberge.refinedstorage.tile.TileController.func_73660_a(TileController.java:242)
    at net.minecraft.world.World.func_72939_s(World.java:1838)
    at net.minecraft.world.WorldServer.func_72939_s(WorldServer.java:613)
    at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:767)
    at net.minecraft.server.dedicated.DedicatedServer.func_71190_q(DedicatedServer.java:397)
    at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:668)
    at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:526)
    at java.lang.Thread.run(Thread.java:748)

I've just come across the same error as @Yarillo4, and at the moment, it's leaning towards disabling the mod.

For context, I'm running on MC 1.12.2 with the latest forge for 1.12.2

@Darkere I tested this in a devenv but couldn't reproduce. Could you test this on an actual obfuscated server for me please?

Not crashing. Any idea on what to specifically test?

Played around with conduits and replacing the controller a lot. Also tried orexcavation on a bunch of destructors.

Looking through the reports doesn't seem like it's specific to servers either. #2219

Basically just starting up a regular, obfuscated, Forge server.

Then breaking/placing the controller.

@CritFlaw Can you still repro this?

I wasn’t doing anything related to a Controller when I got in this state. It’s not specific to Controllers. I had just placed a bunch of Crafters (as reported in #2219).

Should be fixed by #2490