Contains a dll file. Ensure you trust the creator and apply your own security measures.
Hoarding too many vars? Tired of seeing 'Too many heap sections'? Can't run CPU patch v13? Have over 20k vars? Can't open 3-person scenes? Have more RAM than VaM can make use of?
Well, I have solution for you - x3 patch for unity garbage collector.
What does it do? Existing VaM is built with an older version of unity with quite conservative garbage collector which is prone to reaching this cap and never compacting the heap.
In short, there's a hardcoded limit (4096 in our case) of how many sections it will allow you to have before the infamous crash. The patch increases this limit from 4096 to 12288.
Note that this particular number is not linked to RAM or heap memory size directly. Due to fragmentation, we seem to reach this limit fairly quickly when having a lot of vars (and morphs specifically), and I'm suspecting multi-threading isn't making it better.
As a simple analogy, you can think of it as a restaurant with 100 tables that can seat 8 people. Every time a group comes and asks for a table, we give them one. There are tons of people from each group that tend to leave early. We're completely fine with letting new groups sit at the occupied tables as long as group is smaller than number of free seats at that table, however we will never reseat the guests, so when a group shows up with 8 and we have 0 empty tables left (even while having 50 scattered seats!), we reject them.
Who is it for
* People with at least 32GB RAM but ideally 64GB or more (there wouldn't be much benefit with less as you're probably hitting out of memory before hitting limit for max sections
* Lots of vars / morphs
* 'heap crash' for v13 CPU patch
What it does
* Triples the heap section limit essentially kicking the can down the road hopefully enough to avoid the crash altogether and make use of your RAM. I'm running 64GB so it could realistically still happen for people with 128 or more.
* Enables you to experience other errors e.g. out of memory as that would be the next limit
* Allows you to have 130 000 morphs, 5 characters and 2 fps.
What it doesn't do
* Make the game run faster/improve performance
* Improve RAM usage/decrease heap memory
* Fix your hoarding habbits
P.S. I will try to write a patcher down the line instead of sharing dll directly.
Well, I have solution for you - x3 patch for unity garbage collector.
What does it do? Existing VaM is built with an older version of unity with quite conservative garbage collector which is prone to reaching this cap and never compacting the heap.
In short, there's a hardcoded limit (4096 in our case) of how many sections it will allow you to have before the infamous crash. The patch increases this limit from 4096 to 12288.
Note that this particular number is not linked to RAM or heap memory size directly. Due to fragmentation, we seem to reach this limit fairly quickly when having a lot of vars (and morphs specifically), and I'm suspecting multi-threading isn't making it better.
As a simple analogy, you can think of it as a restaurant with 100 tables that can seat 8 people. Every time a group comes and asks for a table, we give them one. There are tons of people from each group that tend to leave early. We're completely fine with letting new groups sit at the occupied tables as long as group is smaller than number of free seats at that table, however we will never reseat the guests, so when a group shows up with 8 and we have 0 empty tables left (even while having 50 scattered seats!), we reject them.
Who is it for
* People with at least 32GB RAM but ideally 64GB or more (there wouldn't be much benefit with less as you're probably hitting out of memory before hitting limit for max sections
* Lots of vars / morphs
* 'heap crash' for v13 CPU patch
What it does
* Triples the heap section limit essentially kicking the can down the road hopefully enough to avoid the crash altogether and make use of your RAM. I'm running 64GB so it could realistically still happen for people with 128 or more.
* Enables you to experience other errors e.g. out of memory as that would be the next limit
* Allows you to have 130 000 morphs, 5 characters and 2 fps.
What it doesn't do
* Make the game run faster/improve performance
* Improve RAM usage/decrease heap memory
* Fix your hoarding habbits
I've actually tried compiling mono.dll but it's hard to get the toolchain/params right. Even with same unity version, I seem to get different size than what we have and it would crash at runtime, so in the end I'm just patching binary of the file. I've used Ghidra for it.
Essentially, we're interested in code under os_dep.c, e.g. this snippet is the one that throws errors:
Issue is that changing the constant during comparison alone is not enough as the GC_heap_bases is a static array of this size that got created at compile time.
What I had to do was also to create new array of size [12288] at the bottom of the file header. Then change all references from GC_heap_bases to my new array
Essentially, we're interested in code under os_dep.c, e.g. this snippet is the one that throws errors:
C#:
if (GC_n_heap_bases >= MAX_HEAP_SECTS) ABORT("Too many heap sections");
GC_heap_bases[GC_n_heap_bases++] = result;Issue is that changing the constant during comparison alone is not enough as the GC_heap_bases is a static array of this size that got created at compile time.
What I had to do was also to create new array of size [12288] at the bottom of the file header. Then change all references from GC_heap_bases to my new array
Credits to JayJayWon,Ashu27, EvilBox and whoever else's vars/plugins got into screenshot.
P.S. I will try to write a patcher down the line instead of sharing dll directly.
Contains a dll file. Ensure you trust the creator and apply your own security measures.
