World render such as plants growing is not a RAM issue nearly as much as a graphics issue. And from day 1 I have stated this pack is incredibly heavy on graphic rendering. ...
After weeks of playtime MF2 comes out as using less RAM for me than DW20 or the other packs. THe thing about MF2 is if your computer can handle the intial start up and still has RAM left over than you can probably play it just fine for a very long time. ...
There is a world leak from vanilla if you pop back and forth between various dimensions. And Harvestcraft will increase the RAM useage. But rgk007 is saying he is having a permanent constant memory leak from standing still AFK without having done anything other than load his game. I have tested, Pantong has tested. We cannot get this to occur on demand. Which means it is more than likely a hardware issue and this pack is too graphically heavy for rgk007 to play. I am sorry but I cannot fix something that is only occuring on a few computers. And there are too many people very publicly playing this pack for 4+ hours without a memory leak for it to be concluded that every computer has the issue.
Jaded, I think you are closing this issue too quickly.
I don't know what is happening with rgk007. It's very possible that we're seeing a graphics driver bug being triggered by the graphical demands of this modpack. And, that's not what I'm looking at.
I could, in 1.1.8 (need to retest in 2.1.2), look at an AE storage system, go AFK, and see a steady increase in allocated memory until Java had allocated all it could.
Last night, and I went over my footage and GC logs multiple times, I had a steady leak in allocated memory just from having harvest craft plants in view. Now, I can see the claim that this was about getting the models prepped and ready and into the video rendering system. Fine. But if that were the only issue, it would stop once I had been through the entire farm -- and that's something I can easily test today (I'm pretty sure it was false, and kept growing, but silly me, I turned off the recorder for the "boring" part.)
I am aware that people have streamed for many, many hours. If the claim is that there are only a few things that will affect this, it is very possible that you will never run into that situation. Equally, if you have allocated many, many gigs to java, it might never actually reach the limit.
Finally, the "current system ram being used" / RSIZE (resident size) values are ... well, not completely meaningless, but very low value. It is affected too much by other things happening on the system and the behavior of the operating system. The issue that really matters here (and that you/modders have control over) is the ram allocated/used by Java; this is why I stress the garbage collection logs as much as everyone else stresses the forge logs. And this is why it takes me so long to produce my performance testing videos, because I am going over the logs with an attention to details.
Incidentally, I'm really ... "annoyed" about that vanilla dim change bug, and really had hoped Mojang had squashed it. I cannot get it to repeat on demand consistently if I'm just doing overworld - nether, but it does happen consistently with every mod-added dimension I've played with. And Mojang doesn't seem to want to hear about vanilla bugs that are triggered by mods.
===
The stuff added by Special Mobs, Deadly World and Infernal Mobs are not considered "Vanilla" mobs and are frequently unaffected by the Magnum Torch. This is now mentioned under Intended in the first post since people keep incorrectly labeling it a bug.
Have I mentioned how much I thought the MT was OP, or that I love your ability to turn an OP item into a source of large amounts of nasty monsters because all the others are gone?
