calm copper
Surprise, surprise, another EnderIO issue.
Background: server was running on 0.10.5. No issues. Leave for a couple of days, server's been stuck in a restart loop since I left. Just updated to 0.11.5 thinking it would fix things, still stuck in the restart loop due to something with EnderIO.
I am REALLY hoping it's not a world issue but it probably is. But any insight into what could be going on would be appreciated.
Should have said any insight into fixes. Clearly EnderIO save data is the issue
chilly bough
@calm copper try deleting this file:
Monifactory\minecraft\saves\[YOUR WORLD NAME HERE]\data\enderio_conduit_network.dat
calm copper
<@196759551855296512> try deleting this file:
`Monifactory\minecraft\saves\[YOUR...
Giving it a try now
calm copper
<@196759551855296512> try deleting this file:
`Monifactory\minecraft\saves\[YOUR...
No luck, same error
chilly bough
So there's probably a data file that is WAY larger then 1MB in that folder
you have a conduit data file that became too large or got corrupted
check around that folder, optionally can delete the entire folder but this would keep all blocks in the world, but they would all lose their configurations
calm copper
I'll do a profile on the world file and get the top file sizes
Nothing obvious in the data folder - largest is the GT ore cache at ~60kb
Excluding region files for dimensions and advancements, yeah, that GT ore cache is the largest file in the world folder
calm copper
I have a sneaking suspicion that somehow, I've ended up in some recursion edge case with the method. So I'm going to do the natural thing and convert the source code for that merge method into C# and see if I can break it
calm copper
@chilly bough Reported to the EnderIO team https://github.com/Team-EnderIO/EnderIO/issues/1004 and let them know in their Discord. I've got no idea on what exactly has caused the crash, but probably worth letting the other devs know to keep an eye on that issue because that completely blocks the Moni world from being loaded, backups and all
And I think the only way it can currently be fixed is with an update for EnderIO, this doesn't seem to be something fixable client side other than deleting the world and starting fresh. But we'll see what they say, just my gut feel atm 
calm copper
@wicked solar Apologies for the direct tag, probably worth knowing about. We (myself and the EnderIO devs) think we know what's causing this, and it's kinda likely to be an issue for other players depending on how they set up their base.
The TL;DR - if you use EnderIO and run a long line of conduits, the world cannot be loaded and will crash. This isn't strictly a single long line, but more the scenario I'm in which is that a line of energy conduits is being run from my power source and sort of branches out around the base, about 600 conduits in total. This is on a server with 8GB memory, somewhere around ~500 conduits is where the issue is likely to appear. It won't be an instant crash when you go above the limit, but it will fail to load when you quit out and try and reload - only hit it on MP but 95% confident singleplayer would be the exact same.
This isn't something that can be fixed client side or via config, it needs an update to the mod from the EnderIO team. But definitely more of an issue for server players because if the server is up 24/7, world backups will hit the same issue as well and you are then fully stuck waiting on the mod fix once the unaffected server backups are deleted.
(Sorry for finding more EnderIO issues, the modern rework is cursed )
wicked solar
Wake up babe new EnderIO issue dropped
Only advice I can give is uninstall enderio to delete all the conduits
Reinstall it, then switch to laserio
surreal sundial
lmao that's wild, i was having crashes on reload after reasonably long sessions and didn't think it was significant lol, around mv/hv
wicked solar
@rugged forge
calm copper
Only advice I can give is uninstall enderio to delete all the conduits
Nah it's good for now, I can wait on the fix. But if others hit it, it's a known issue on their end
Ayyyyy Rover's in here as well
Just repeating my Discord messages lmao
rugged forge
<@217581589947875329>
Yep was alerted in our discord. If I have any time to look at this then I will but holy my calendar is jammed with uni. Hopefully one of the other team members have some capacity in the coming time. I’ll forward the message I sent to our team the other day, 2 secs
tiny burrow
actually it's kinda hilariously trivial, they're already doing all the hard(ish) parts
it's literally just a loop written in the recursive style, not a tree
rugged forge
Yeah I can see how having a large conduit network could cause this to overflow 😆 this code is ooold
calm copper
it's literally just a loop written in the recursive style, not a tree
It is kinda nasty, it's a somewhat specific scenario you hit it in lmao
rugged forge
definitely should just be a normal loop like Skye and yourself were saying
I can have a quick hack at rewriting it to be flat and see if that helps your case, but if it takes longer than like 10 mins then i gotta go bed (its just past 12 for me and I got class early tomorrow 
)
what is really confusing is why it still happens after deleting the level data though 🤔
calm copper
I can have a quick hack at rewriting it to be flat and see if that helps your ca...
Nah you're good. I'm a .NET dev but it's a single method so can have a look at rewriting it tomorrow, but even then it's not urgent (looks like we're the first two who've hit it)
calm copper
what is really confusing is why it still happens after deleting the level data t...
If the file is deleted, do you not try and construct it from the world data/on load?
rugged forge
no, that's not possible
calm copper
Hmm
rugged forge
if the graph data is destroyed, we reconcile when the block entities are loaded
that code path being hit at line 99 means the level has some NBT to be loaded
tiny burrow
if you want to run code from some random on discord, I've built dev/1.20.1 with ```java
private void merge(GraphObject<Mergeable.Dummy> next_object, List<Pair<GraphObject<Mergeable.Dummy>, GraphObject<Mergeable.Dummy>>> connections) {
while (!connections.isEmpty()) {
GraphObject<Mergeable.Dummy> object = next_object;
var filteredConnections = connections.stream().filter(pair -> (pair.getFirst() == object || pair.getSecond() == object)).toList();
List<GraphObject<Mergeable.Dummy>> neighbors = filteredConnections
.stream()
.map(pair -> pair.getFirst() == object ? pair.getSecond() : pair.getFirst())
.toList();
for (GraphObject<Mergeable.Dummy> neighbor : neighbors) {
Graph.connect(object, neighbor);
}
connections = connections.stream().filter(v -> !filteredConnections.contains(v)).toList();
next_object = connections.get(0).getFirst();
}
}
Give it a PR I reckon
rugged forge
The problem with a PR is we don't have a definitive way to test that it resolves this issue 😅
only thing we can validate is that conduit loading still works
calm copper
The problem with a PR is we don't have a definitive way to test that it resolves...
The joys of modding 
tiny burrow
(well, I can confirm that that code was not the right one, for obvious reasons if I'd actually thought about it rather than just no thoughtsed it; should be fixed)
rugged forge
no worries, trying something different atm
hmm seemed to work
Skye, you up to testing a build? (Please take a backup first)
basically removed the merge method and do this instead:
can of course be tidied a little, but seems okay for a first pass
if you wanna give it a bash, here's the built jar with the above change
seemed to load my testing world fine, so shouldn't be any change in outcome
should also be less expensive, integrate is for adding nodes from the same graph (which is what this load sequence is doing) instead of connect which seeks to merge newly connected graphs together
calm copper
Skye, you up to testing a build? (Please take a backup first)
I also need to sleep (also past midnight for me lmao) but I'll give it a test in the morning
rugged forge
epic, I'll create a draft PR with the changes in the meantime :) thanks a lot
I'll also upload a jar to that PR so you can get it from a "more trusted" source
rugged forge
v6.2.8-beta released with this fix, should be on CF soonish
okay reverting this release... I think we might've missed something. I'm recreating it for 1.21.1 at the moment and it's not working as expected.
it may have fixed loading, but it seems to silently crash while doing so (cheers mojang) and marches on without having alerted us
so "fixed" is relative
calm copper
I honestly don't know how you guys do it, I messed around with MC modding back in the 1.7 days but it seems like it is just hell these days 
rugged forge
Nah this is on me for not double checking to be fair
I replaced Graph.connect with Graph.integrate, as it took a list of neighbors instead and expected them to do the same thing
they do not
Unfortunately the dev who wrote the conduits stuff here is no longer around so I've been trying to learn how they work
I guess this is another teaching point 🤣
calm copper
Brilliant lmao
calm copper
What stage is it crashing at? Pre/post-world load?
rugged forge
So there's the thing, it throws an exception and swallows it
during world load the conduit load procedure completely flunks and MC just marches on like nothing happened
yeah this feels like a potential bug in the graph library we use to be honest
calm copper
What's the consequences, what would I expect to break with it flunking? I was actually going to boot Moni up soon, I can give it a test with the original PR jar
rugged forge
the consequence is that networks will be broken until the conduit bundles are loaded again in-world so it can reconstruct them in memory (This is a failsafe, but incredibly annoying to have to invoke)
if the conduit bundle cannot find a network for itself, it'll use its last-known data to reconstitute the graph on its own
calm copper
Fuck it, guess I'm going into Java development now
Send me a stack trace, I'll have a look
I got nothing to do tonight
rugged forge
I am just gonna replace integrate with connect again and see that it fixes it
I'm almost tempted to try and write our own graph implementation away from the 3rd party library so we can fix stuff like this
calm copper
I'm almost tempted to try and write our own graph implementation away from the 3...
I was gonna suggest this. If you're using it for keeping track of connections, pathing and searching and not a whole lot more, it's not a bad idea
Depends how well maintained the 3rd party is tbh
rugged forge
It's not poorly maintained, but the dev hasn't had a lot of time recently
I've got a PR standing that's almost 3 months old and it's preventing some fairly important work in Ender IO (capacitor bank lag)
calm copper
I've got a PR standing that's almost 3 months old and it's preventing some fairl...
Yeah, that's an upvote for rewriting
