Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce "content script packages" #81

Open
Xymanek opened this issue Dec 20, 2021 · 0 comments
Open

Introduce "content script packages" #81

Xymanek opened this issue Dec 20, 2021 · 0 comments
Labels
enhancement New feature or request

Comments

@Xymanek
Copy link
Member

Xymanek commented Dec 20, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant