the Sim Settlements forums!

Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!

64MB Script Limit - Tricks to Bypass

kinggath

Well-Known Member
Staff member
Administrator
Moderator
Verified Builder
Messages
4,068
With the recently discovered 64MB Script data storage limit, we have to start thinking of new ways to get more data into the game in more creative ways.

I've discovered a few useful tips about this, and thought we should have a place to compile them all - so this thread will serve that purpose.


First up, I want to make it clear that this limit is across your entire load order. We do not get 64 MB per mod. Which means we all have to be cognizant of the limit and do our part to keep usage down in our mods.

The data limit also only applies to Auto and Const properties that are configured via the editor or XEdit. It does not apply to script variables or hidden properties.


Now onto some tips:

1. Default values don't count.

If you set a default value for a property, and then don't fill in that property (ie. you want the default value). It's data does not count towards this limit. This is especially relevant for things like data structures, where you might have some number of unused fields.

For example, in Sim Settlements addon packs - if you need to set a position or rotation field to 0 for a stage item spawn, leave it blank, and that field won't add to the data count.

2. Game.GetFormFromFile can bypass the limit.

One trick I started using extensively in Workshop Framework (just out of convenience as this was before the limit was known), is to setup hidden properties and then fill them during the OnInit event. To do this, simply setup a holder variable for what your property would be, then store the Form ID and plugin name as Const variables in your script.

For example, let's say you want the WorkshopItemKeyword as a property. Your code would look something like this:

Code:
Keyword Property WorkshopItemKeyword Auto Hidden
Int iFormID_WorkshopItemKeyword = 0x00054BA6
String sPlugin_Fallout4 = "Fallout4.esm"

Event OnInit()
WorkshopItemKeyword = Game.GetFormFromFile(iFormID_WorkshopItemKeyword, sPlugin_Fallout4) as Keyword
EndEvent

You can then use that Keyword like normal, without having to impact the script data cap at all.

If you've never used Game.GetFormFromFile, the trick to the FormIDs, is they are of type Int, and should always begin with 0x00 then the last 6 digits of the HEX ID you see in the Creation Kit/XEdit.
 

1000101

Lurking in the bushes
Verified Builder
Messages
108
Thanks for the info, I have some thoughts though...

The data limit also only applies to Auto and Const properties that are configured via the editor or XEdit. It does not apply to script variables or hidden properties.
This implies that script variables and hidden properties are stored somewhere other than the VM heap, this is problematic for me because it means there is a heretofore unknown second heap used to store meta data about the scripts (a "meta heap" if you will). The caveat to all this, however, is function parameters and function local variables which are stored in the running threads call stack.

1. Default values don't count.
...leave it blank, and that field won't add to the data count.
Default values aren't stored in the plugin file (ESM/ESP/ESL), but is this true for the VM as well? That is, when you allocate a struct, does it only create part of the struct in the VM heap and then reference the "meta heap" for the default value? If so, then this leads credence to that unknown "meta heap". Another troubling thought is that this implies there would be an access penalty for default values as the VM has to "look around" (as it were) for the value.

2. Game.GetFormFromFile can bypass the limit.
This isn't so much a tip by itself as an example of the tricks mentioned at the beginning about hidden properties and script variables.

All that being said, this is some food for thought and certain parts need more research to verify what is going on. Thanks again for the info nonetheless. :)
 
Top