DW20 1.3.1 Startup issue

[Cougar281]

I set up two new DW20 1.3.1 servers and updated my client to 1.3.1, and I've found that 99% of the time, it would hang at 'Loading - Initializing Minecraft Engine 4/7' 'Rendering Setup - Render Global Instance 4/9'. When this happens, the Minecraft window goes to 'Not Responding' and this is the last thing I've found in the log:

[23:07:11] [Client thread/INFO] [FML/]: Applying holder lookups
[23:07:11] [Client thread/WARN] [FML/]: Unable to lookup chisel:cobblestoneWall for public static com.cricketcraft.chisel.block.BlockMarbleWall com.cricketcraft.chisel.init.ChiselBlocks.cobblestoneWall. Is there something wrong with the registry?
[23:07:11] [Client thread/WARN] [FML/]: Unable to lookup chisel:obsidian2 for public static com.cricketcraft.chisel.block.BlockCarvable com.cricketcraft.chisel.init.ChiselBlocks.obsidian2. Is there something wrong with the registry?
[23:07:11] [Client thread/INFO] [FML/]: Holder lookups applied
[23:07:11] [Sound Library Loader/INFO] [Mantle-STDERR/]: [paulscode.sound.SoundSystemLogger]:
[23:07:11] [Sound Library Loader/INFO] [Mantle-STDERR/]: [paulscode.sound.SoundSystemLogger]: Starting up SoundSystem...
[23:07:11] [Thread-16/INFO] [Mantle-STDERR/]: [paulscode.sound.SoundSystemLogger]: Initializing LWJGL OpenAL
[23:07:11] [Thread-16/INFO] [Mantle-STDERR/]: [paulscode.sound.SoundSystemLogger]:  (The LWJGL binding of OpenAL.  For more information, see http://www.lwjgl.org)
[23:07:11] [Thread-16/INFO] [Mantle-STDERR/]: [paulscode.sound.SoundSystemLogger]: OpenAL initialized.
[23:07:11] [Sound Library Loader/INFO] [Mantle-STDERR/]: [paulscode.sound.SoundSystemLogger]:

What I've found that seems to get it to load is to check the 'Use Optimization arguments for fast computers' option under 'options', although I'm not sure I'd call that a fix.

Has anyone else seen this happen, and is there a 'more proper' fix to the issue?

 

[ScottulusMaximus]

You've fixed it so I'm not sure what you're asking for... But if the log just stops like that it's usually a RAM or permgen issue

 

[Cougar281]

Finding something that seems to make it work doesn't necessarily mean I fixed it - it doesn't explain what was happening. The log stops at the same point every time, near as I can tell, so it would seem less likely to be memory and more likely to be something else in the game. My machine has 8GB RAM and when it hangs, Java is using about half what it's allocated in the launcher. If it was memory, I'd rather expect it to hang at random points, not always the same exact point, and to have at least a little variation in the log as to where it ends.

 

[Hambeau]

Finding something that seems to make it work doesn't necessarily mean I fixed it - it doesn't explain what was happening. The log stops at the same point every time, near as I can tell, so it would seem less likely to be memory and more likely to be something else in the game. My machine has 8GB RAM and when it hangs, Java is using about half what it's allocated in the launcher. If it was memory, I'd rather expect it to hang at random points, not always the same exact point, and to have at least a little variation in the log as to where it ends.

A few details would be handy... We already know what version of Minecraft and the pack you're using and that your system has 8GB ram.

What we don't know:

1). What version of Java?
a) If version 7 what are your command line switches? Recommended settings are Minimum ram = 2GB, Maximum ram = 4GB and PermGen = 256MB, according to the post that introduced this version of DW20
b) If version 8 then make sure the command switches are cleared... The above settings are now the default and older settings can cause issues.

2). How much Ram is allocated to the client? Anything above 4GB causes more problems than not.

Assuming you are having memory problems, if you start the game up the same way every time you most likely will see the crash in the same place every time. To test this, start up another large program first and minimize it. If it fails in the same spot it's most likely configuration... If it fails earlier then theres a problem with the amount of memory in use.

 

[Cougar281]

So as I mentioned in my OP, selecting 'Use Optimization arguments for fast computers' seemed to get the client to launch fine each time, however, despite the fact that my machine is a quad core i7 2.7Ghz, the result was incredibly poor performance - 0-3FPS poor (but not immediately - initially it was fine, then it fell through the floor). I was thinking it was the server, but the server wasn't doing anything, and no matter how many times I rebooted it, the problem was present. I then added '-XXermSize=256M -XX:MaxPermSize=512M' to the 'Additional Java options' (If that's required for it to work, wouldn't one think the launcher would populate it with what's needed for it to work??) and deselected the 'Use Optimization arguments for fast computers' (I've actually tried it with and without that checked) and it then launched, with the previously mentioned horrible FPS no longer present, however, it's hit or miss. Sometimes it'll launch fine, other times it'll hang at the same point.

I'm running Java 1.7u71 64-bit, the launcher has 2.25GB assigned as a max RAM. With FTB closed, I'm running about 5.1GB free/available. With FTB Launched, I still have ~2.5GB free, so I have my doubts about it being related to physical memory.

I might consider 'updating' to Java8, however, from what I've been reading, that's a mixed bag - Some Java8 versions are ok and others are not. Aside from not needing additional arguments, I'm not sure there's really any benefit to Java8 - The Java 'programmers' are completely insane and that's likely to result in more Java insanity.