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

Pass -DEFENGINEINI to mod script compiler #67

Open
Xymanek opened this issue Nov 28, 2021 · 0 comments
Open

Pass -DEFENGINEINI to mod script compiler #67

Xymanek opened this issue Nov 28, 2021 · 0 comments

Comments

@Xymanek
Copy link
Member

Xymanek commented Nov 28, 2021

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

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

No branches or pull requests

1 participant