uhm. If there are no OC blocks in the world, what exactly makes you think the problem is with OC and not with your machines?

Don't bother trying to get reika to take the blame for his mistakes, he's a terrible developer who probably can't understand half of his own code.

That is dragonapi that's crashing, what exactly are you doing in that line?

On Fri, 13 Feb 2015 3:16 pm yoshiman22 notifications@github.com wrote:

Don't bother trying to get reika to take the blame for his mistakes, he's
a terrible developer who probably can't understand half of his own code.

—
Reply to this email directly or view it on GitHub
#911 (comment)
.

The code is ultimately getting called from DragonAPI, but unless the joinOrCreateNetwork function is a "Crash the game" function - odd, considering I was specifically told to use it - the actual crash is coming from OpenComputers network code.

That is dragonapi that's crashing, what exactly are you doing in that line?

Calling the OpenComputers function.

Hmm, looking at the code, my best guess is that this is caused by duplicate addresses being resolved in a network merge by one of the nodes' addresses being changed, but that change not being applied to the map keeping track of nodes in the network. I'll try to push a build with a potential fix in a bit.

So yes, this is probably a bug in OC's network code. Would people please stop assigning blame before any investigation whatsoever? That'd be great ;-)

However, this also indicates that nodes in your tile entities frequently get the same addresses, which shouldn't happen naturally (they're randomly generated UUIDs after all). Do you call the nodes' load method at some point with NBT that might override the node's address?

Allright, build 38 should fix this issue, please give it a go and let me know, thanks!

Do you call the nodes' load method at some point with NBT that might override the node's address?

I pass on the NBT methods to them as per your recommendations, but aside from that, no.

Also, if you want to ensure no conflicts, even with random UUIDs, you can take a look at my pylon code which does that (in my case to detect and reject TileEntity movers).
https://github.com/ReikaKalseki/ChromatiCraft/blob/master/Magic/Network/CrystalNetworker.java#L272

Allright, build 38 should fix this issue, please give it a go and let me know, thanks!

I will do that.

Also, if you want to ensure no conflicts, even with random UUIDs, you can take a look at my pylon code which does that (in my case to detect and reject TileEntity movers).

Hmm, I think with this fix things should be fine, but if it turns out duplicates are still an issue in other unexpected ways I could add a global registry to avoid them altogether, yeah. For now, I want to avoid the bookkeeping involved in that.

Well, the new update seems to have improved stability, but we still see this crash sporadically.

Hmm, is it the exact same stacktrace?

Yes.

Please try build 39, added some more checks, in particular for when loading nodes, which is one of the few contexts I could imagine leading to duplicate addresses at such a frequency. The chances for it happening from randomly generated ones are just so astronomically small.

Installing now. Even with 38, we only saw one crash in 3 days, so it will be hard to get confirmation on this.

No hurry, I'll leave this open for a week or two, if it doesn't occur in that time frame I'm hopeful it's actually fixed. If it does pop up again I'm honestly considering just throwing a try-catch at it, because I don't see any execution paths that could lead to the state causing this anymore >_>

It seems to be fixed; no crashes since adding b39.

Great!