When a SF package is made, the cooker will dutifully inline everything that doesn't match the following criteria:
Always loaded objects - those are left as references, since they are expected to be already in-memory at the point when the SF package is loaded
Editor-only objects - those references are nulled out
This includes script classes (including their bytecode). Normally this isn't a concern - objects from (and referenced by) native script packages are considered to be always loaded. However, that isn't the case for non-native script packages (including the DLC ones, but they are unable to cause the issue discussed here). As such, if a package has an object that's based on a class that comes from a non-native script package, the SF package will include the classes, and their bytecode, all the way up the class hierarchy to the first class from a native script package.
Side note: the original cooking approach had this issue even with the native script packages, since I cleared their array - the cooked kismet map pulled in the bytecode for all used Seq[...] classes. I noticed/realized that only after the approach was implemented
The solution is simple - we just add the script package(s) to the native packages array as part of our DefaultEngine.ini modifications. This causes the cooker to load them and mark as always loaded, but not cook them since it assumes that they are part of the base game. However, I do not think we should do so automatically:
Not only the classes will be marked as always loaded, but anything referenced by them. This includes classes from other script packages (e.g. the DLC ones) as well as content objects referenced in the script (e.g. SomeClass'SomePackage.SomeObject'). I do not feel like I understand full implications of this.
There might be cases where the classes-in-SF-content is a desired behaviour. The first example that comes to mind are voice packs - there is no need to load the backing script package in memory when it's only needed while the content package with the audio is loaded. In such cases, we might wish to forgo shipping the script package entirely and just rely on the inlined class/bytecode in the content package (#81).
When a SF package is made, the cooker will dutifully inline everything that doesn't match the following criteria:
This includes script classes (including their bytecode). Normally this isn't a concern - objects from (and referenced by) native script packages are considered to be always loaded. However, that isn't the case for non-native script packages (including the DLC ones, but they are unable to cause the issue discussed here). As such, if a package has an object that's based on a class that comes from a non-native script package, the SF package will include the classes, and their bytecode, all the way up the class hierarchy to the first class from a native script package.
The solution is simple - we just add the script package(s) to the native packages array as part of our
DefaultEngine.inimodifications. This causes the cooker to load them and mark as always loaded, but not cook them since it assumes that they are part of the base game. However, I do not think we should do so automatically:SomeClass'SomePackage.SomeObject'). I do not feel like I understand full implications of this.