In some cases, script packages are used only to create base classes for objects (assets) that then will be configured in the editor. Loading them at startup (and keeping in memory all the time) is wasteful, since they are only ever needed while the derived assets is loaded.
The most common use case are voicepacks using robojumper's script - there is no need to keep the class xyz extends XComCharacterVoice loaded all the time in memory.
Additionally, when cooking the asset package (e.g. the voicepack archetype), the script classes will be pulled into the seekfree package - there is no point in even shipping the .u file in this case.
For the game, switching the script package from "always loaded" to "content" is very simple - it just needs to be removed from [Engine.ScriptPackages] NonNativePackages in XComEngine.ini. However, this does impose some limitations:
No DLCInfo (this is a good thing for voicepacks and similar, since they are usually empty and just slow down the iterate-call scenarios)
No UISLs
No X2DataSet-derived classes (no template creation)
Cannot participate in MCOs
Additionally, they should ideally be compiled after the "always loaded" script packages, since if they are referenced by such package, the whole point is defeated (it will be loaded at startup together with the "always loaded" package).
Besides the useless loading/memory, there is another advantage: it's possible to use hard references in script (e.g. StaticMesh'SomePackage.SomeMesh') without causing the asset to become always loaded
In some cases, script packages are used only to create base classes for objects (assets) that then will be configured in the editor. Loading them at startup (and keeping in memory all the time) is wasteful, since they are only ever needed while the derived assets is loaded.
The most common use case are voicepacks using robojumper's script - there is no need to keep the
class xyz extends XComCharacterVoiceloaded all the time in memory.Additionally, when cooking the asset package (e.g. the voicepack archetype), the script classes will be pulled into the seekfree package - there is no point in even shipping the
.ufile in this case.For the game, switching the script package from "always loaded" to "content" is very simple - it just needs to be removed from
[Engine.ScriptPackages] NonNativePackagesinXComEngine.ini. However, this does impose some limitations:Additionally, they should ideally be compiled after the "always loaded" script packages, since if they are referenced by such package, the whole point is defeated (it will be loaded at startup together with the "always loaded" package).
Besides the useless loading/memory, there is another advantage: it's possible to use hard references in script (e.g.
StaticMesh'SomePackage.SomeMesh') without causing the asset to become always loaded