Time to bump minimum memory...

[mikeprimm]

The latest update - which, as always, added more images to both our resource pack and to the WesterosBlocks mod to support new blocks - seems to have finally pushed us to the 'tipping point' for our default launcher memory settings (that is 2GB min/max for Java on the launched VM). From my own testing, on Mac, I cannot even get a successful start of the production client with the 2G default - and, even as a coder, there is quite literally nothing I can do (short of rewriting how Minecraft and Optifine handle image resource... which isn't gonna happen). Thing is, they load the image files - all of em - and store them uncompressed in memory (usually using 4 bytes per pixel) - and the CTM features we use result in lots of 'generated' images (based on combining and/or modifying other images), adding even more to the use.

In any case, I'll be adjusting the launcher tonight to drive the default settings (and the minimum allows settings) to 3GB. If this winds up being a problem for someone who doesn't have the system to handle it - I'm sorry: I tried delaying this as long as I can, but the fact is that MC is fat, modded MC is fatter, and our RP and custom blocks make it fatter still. We'll need to bump to at least 3GB for v1.12.2 - that was already not working with 2GB - and, as with most software, it'll be ever onward and upward from there.

For anyone that has had problems with lag or OOM crashes since the update - this should hopefully help (and adjusting your settings in the launcher may also help, if you need a fix before I deploy the Launcher patch).

Update: Launcher patch deployed - will now make sure Java memory is 3G (or higher, if you opt to set it so). Also, production is now running latest OptiFine (C7), which we've been running on the test client for a couple of months.

 

[Emoticone11]

Do you think we could potentially trim down our memory useage by coding CTM functionality into the WesterosBlocks mod and using a more efficient technique to load in resources? It would also help protect us from getting screwed over by Optifine every time they decide to change their support on a whim.

 

[mikeprimm]

Do you think we could potentially trim down our memory useage by coding CTM functionality into the WesterosBlocks mod and using a more efficient technique to load in resources? It would also help protect us from getting screwed over by Optifine every time they decide to change their support on a whim.

Dunno - I'll try to study the problem a bit: haven't tried running the MC client under a memory profiler in a while, but it could be illuminating . If I find anything particularly 'damning' about how we're doing any of these - or, more accurately, how OptiFine opts to implement any of the CTM or related features we've got - we can take a serious look at whether we can do it 'better'. Even now, a number fo the things we do COULD be done via customized JSON models in vanilla blocks (e.g. random alternate models and/or texture usage - see the current vanilla grass blocks for examples here) - shifting to vanilla-based mechanisms for some items may be better (although I AM always cautious about assuming anything in Vanilla is better implemented than things from the modder community - it so often isn't the case...).

The main thing is just the inevitable march of growth in capability - adding blocks, adding textures, and adding creative uses of them just means adding resource use. It's not bad - but it does create points where we need to say 'sorry - time for us to say we need a bit more resources than we needed two years ago'. I wish MC were as resource efficient as modern game engines like Unity or Unreal Engine can be, all things being equal, but that project is a whole order of magnitude beyond what we've done to date.

 

[Dan_Prime]

I haven't looked much into the technicalities, but Minecraft 1.13 is promising to be a full backend update. It's likely similar to the scale of the changes between versions 1.7 and 1.8. When more details come out about that perhaps we can evaluate if a bump to that version in the next year or so would be benfitial.