Prevent asset cooker from including things that are part of the cooked game

[Xymanek]

The greatest benefit of asset cooker is the size reduction from compression and removal of editor-only data; unfortunately that advantage can get lost pretty quick when some reference to a base game asset causes a lot of assets to get inlined into your package/TFCs. It's a necessary evil if the referenced asset is not shipped with the cooked game, but if it is (and especially if it's directly SF) then it's just a purposeless ballooning of the package size.

Ideas for approaching:

• Add the SF packages into "startup packages" array in config (and ignore the cooked startup package)
• "Objects to never cook" config

[Xymanek]

Additionally, we should look for a way to make the cooker aware of the contents of base game TFCs (to prevent shipping the textures again in mod TFCs).

I have attempted to start the cook with the base game's GuidCache.upk, GlobalPersistentCookerData.upk and PersistentCookerShaderData.bin + TFCs but it only resulted in cooker dumping around 150MB (don't recall exactly) into the mod's TFCs

However, the approach is sound in theory so I suspect that something was done incorrect on the invocation side. In particular, I suspect the "first mod cook" + config array clearing logic has interfered with the cooker's tracking mechanisms

[Xymanek]

Since the switch to DLC cook (#46) the base game TFCs get reused properly. As for other objects: one approach we could take is to generate a dummy script package that will have a single class with an ObjectReferencer property and then tell the cooker to load that package as a native script one, marking all the referenced objects as always loaded (see #48 for more details).

[Xymanek]

TFCs reuse turned out to be unreliable and so DLC cooking was reverted (#53). I suspect that the issue arises from FXS using -tfcsuffix=_XPACK_ themselves when cooking WOTC's assets, which the DLC cooking isn't able to handle properly

Vanilla CookedPCConsole:

WOTC CookedPCConsole:

We could try using -tfcsuffix=_XPACK_ -DLC (which looks like the approach that was taken for TLE, based on the file names) cooking ourselves but at this point I do not trust that it will produce correct results all the time, especially due to the difficulty with testing

[Xymanek]

There were several tests (by @pledbrook and myself) which seem to indicate that -tfcsuffix=_XPACK_ -DLC does indeed produce usable results. However, at this point I'm very cautious of the system, especially considering the difficulty in testing the results. As such, before we proceed with any further changes to the build process, we should implement #44, including testing the cooker in various scenarios. A special consideration should be given to the TFCs and their contents - both base game and mod-added. For example - what's in the unsuffixed base game TFCs? What happens if a mod references those textures?

Additionally, we should consider adding a concept of "cooker passes" whereby a mod will be able to specify various cooking configurations/approaches simultaneously, e.g. "game cook" for custom textures (to make use of a mod-specific GPCD) and "dlc cook" for stuff that references base game textures.

[Xymanek]

#70 re-implemented DLC cooking, which means that base game TFCs are now properly reused. This is a very significant optimization already (e.g. WOTC's TFCs total to 9.8 GBs, while the UPKs total to "only" 18.7 GBs).

Closing as there is no safe and simple/straightforward way of preventing duplication of other asset types