I'm not sure how to reproduce this or what specifically is causing it.

I have a world that worked, was shutdown correctly, but now causes Minecraft to hang during world loading. It does produce a crash report so there's that.

crash-2017-09-01_08.34.09-server.txt

Ok, I discovered the problem: default values for empty lists created by delayers.

It's a consequence of the current implementation of the 'get' operator, which has been an issue for a long time. It's about time I do something about it.
I'll implement a change that will make the 'get' operator throw an error (in-game) if the index is out of bounds, which will stop any further execution of the variable until you reset it manually.
Next to that, I will add a 'getOrDefault' operator to still catch those errors manually with a custom default value.

@ouroborus FYI, I noticed you are using 1.10.2. I don't maintain the 1.10.2 branch anymore (it takes up too much of my time to maintain old versions as well), so you probably won't be able to enjoy this fix in your current world.

@rubensworks It sounds like you're saying that Delayers briefly have a empty or default list during load and that 'get' has an issue with this. Your proposed solution seems to be to make is so that a system involving this scenario will "break" in-game until the player intervenes. But, since that situation occurs during world load (or rather, presumably, during chunk load), it seems that this would happen any time the chunk had become unloaded and so the player would be required to "reset" their machinery every time the chunk reloads.

I realize that 'getOrDefault' is meant as a replacement for 'get' and that 'get' is essentially being deprecated. I wonder if the way to go is just permanently breaking 'get' (i.e.: arrangements that use 'get' just stop when they get to processing the 'get'), disallowing further creation of 'get' variables, and adding "Deprecated. Use getOrDefault instead." to its description. I can't see that 'get' has a use over 'getOrDefault' given this issue.

Also, 'head' could potentially have this issue. (I haven't looked into this.)

RE: 1.10.2
Fair enough. You should know that Integrated Dynamics and Integrated Tunnels have been added to the ATM1 modpack (changelog) a few days ago.

I extended the tooltip description to make that clear in the latest commit.
But I guess I can explicitly tell the user that getOrDefault should be used instead.
The regular get is still perfectly usable if the list length always remains static.

Thanks for reminding me of the existence of 'head', that one should indeed be handled in the same way.

Hmmm, it looks like ATM1 is (unfortunately) still played a lot. I'll see if I can find some time to backport the most important fixes to 1.10.2.

@ouroborus Can you give me the full forge log? There should be more information in there.

@rubensworks Err, which one is that?

@ouroborus fml-server-latest.log

@rubensworks Running in single player, so:
fml-client-latest.zip

@ouroborus Hmm, that log doesn't contain the additional logs I would expect, that's unfortunate...

Any chance you remember what has changed in your ID network during your last playthrough?

@rubensworks I had built an item rate indicator after having to delete a failed attempt at it via MCEdit due to another issue.

Ok, that already helps, thanks.

Note to self: this might have something to do with list operations returning incorrect variable types.