This will allow us to make mod assets reference-able in script by modifying [Core.System] Paths. Currently, the script compiler can't see non-SDK packages:
local Object obj;
obj = Texture2D'CI_InventoryImages.Inv_Facility_Lead_Unlocked';
Warning, Unresolved reference to Texture2D 'CI_InventoryImages.Inv_Facility_Lead_Unlocked'
However, doing so has an interesting side effect: SDK\XComGame\Mods's XComEngine.inis become "ignored". This has 2 implications:
1) Failed to delete [...] because you built before another mod that also depends on MCM API effectively fixes itself
2) The current mod's script dependencies are not built either
A simple solution would be to just dump the current mod's XComEngine.ini into the "new" DefaultEngine.ini, but this also means that a lot of entries that were normally ignored in mods (e.g. the above-mentioned Paths) would now take effect, potentially causing unwanted behaviour.
A "smarter" approach would be to
1) Scan all script packages (folders) of the current mod and IncludeSrcs
2) Exclude base game ones (they will be compiled anyway) and X2WOTCCommunityHighlander (if the latter came from IncludeSrc)
3) Move the package that matches the mod name to the end of the compile list
4) Provide an option to override the (result of the) above process (for more complex setups)
The above makes an assumption that the "mod script package" depends on the rest of packages and the rest of the packages do not depend on each other. While limited, I believe this assumption covers a significant share of cases
This will allow us to make mod assets reference-able in script by modifying
[Core.System] Paths. Currently, the script compiler can't see non-SDK packages:However, doing so has an interesting side effect:
SDK\XComGame\Mods'sXComEngine.inis become "ignored". This has 2 implications:1)
Failed to delete [...]because you built before another mod that also depends on MCM API effectively fixes itself 2) The current mod's script dependencies are not built eitherA simple solution would be to just dump the current mod's
XComEngine.iniinto the "new"DefaultEngine.ini, but this also means that a lot of entries that were normally ignored in mods (e.g. the above-mentionedPaths) would now take effect, potentially causing unwanted behaviour.A "smarter" approach would be to
1) Scan all script packages (folders) of the current mod and
IncludeSrcs 2) Exclude base game ones (they will be compiled anyway) andX2WOTCCommunityHighlander(if the latter came fromIncludeSrc) 3) Move the package that matches the mod name to the end of the compile list 4) Provide an option to override the (result of the) above process (for more complex setups)The above makes an assumption that the "mod script package" depends on the rest of packages and the rest of the packages do not depend on each other. While limited, I believe this assumption covers a significant share of cases