cannot use multiple mods, each adding new enemies?

[davidlallen]

There are quite a few mods that add new enemies, such as Muton Centurion, Better Advent, Advent Breaker, etc. Maybe 15-20 such mods by now. Unfortunately it seems to be impossible to use any two of them together.

 

To add an enemy, you have to add a bunch of things, but in particular you have to change the inclusion and exclusion list in XComMissions.ini. Because of the way the + and - entries work, it is usually impossible to have any two of these mods at the same time. That is unfortunate, because for N such mods, we need N-squared number of different merge mods if somebody wants to use this alien plus that alien.

 

Is there any way to have two such mods work together in general?

 

I was thinking that the uc classes which read these files might be moddable. Each modder could write a uc file which *programmatically* edits the related lists, instead of relying on the ini -/+ syntax. Since you have to add at least some uc files for new units anyhow, this does not add *too* much of a barrier for modding. The benefit of seamlessly integrating with other mods would be worth a little extra scripting.

[Dragon32]

Not that I can help much here but I think I've run into this problem. In my first, just about vanilla, play through I added Long War Studio's Muton Centurion. Which was nice. For my next play through (sadly abandoned after the new DLC and its associated patch) I added some other mods. The Advent Sniper mod worked fine but when I added the Muton Demolisher and Elite Viper I would get CTDs on mission start, I assume when those critters were active. Removing the mods allowed me to continue. I can't be definitive that those other critter adding mods were the problem but based on what you're saying here I guess that the Advent Sniper edits different lists to the Muton Centurion, but both the Elite Viper and Muton Demolisher are editing the same lists as the Centurion.

 

There's this thread: Constantly Crashing to Desktop with new Enemy Soldiers by Yzaxtol too, where the CTDs seem to be caused by errors in the SupportedFollower list. I guess that's related.

 

A fix for this would be great. In Bethesda games there are programs which create levelled list merging plugins, these merge changes made to levelled lists by multiple plugins and load after those plugins, the data in the merged levelled list plugin overwriting that of its source plugins.

 

Whether something similar would be possible with XCOM 2 I have no idea, having no clue as to what goes on under the bonnet.

[zingfharn]

What exactly is the problem? The fact that each mod redefines what an alien group looks like?

[cojaca2]

While these mods do have some inherent compatibility issues it would be nice to have a way of addressing, I think 'impossible to use any two of them together' is pretty drastically overstating the issue - I use several enemy adding mods, including A Better ADVENT and several of the stand-alone ones like the ADVENT Psi Operative, and they mostly work fine with each other, to the degree of it being possible to have enemies from multiple mods in a single pod as long as they share a valid leader.

 

The 'valid leader' is something of a sticking point, of course, but one that (short of changing the way pods as a whole are constructed) I don't think can be solved without compatibility patches.

 

The problem is that in each new enemy's CharacterStats.ini entry, it specifically lists all enemies that are allowed to serve as followers to that enemy. Mods can append new followers to these lists (and multiple mods can add to the same ones, which is why the mods sort of work with each other already), but for a mod-added leader enemy to accept a mod-added follower from a different mod, that follower would needed to be added to the leader's whitelist, and I don't know how, if at all, that would be done automatically, at least not in a way that was intelligent, so as to not, say, give one of A Better ADVENT's new Captain variants the Muton Demolisher as a follower, when vanilla Captains can only lead ADVENT units.

Edited March 21, 2016 by cojaca2

[davidlallen]

I am surprised to learn that any two such mods can work together when using the -/+ syntax to modify the include/exclude lists. For example, suppose the GlobalAdvent list contains enemies a,b,c,d. Mod #1 wants to add enemy e. Mod #2 wants to add enemy f.

 

Mod1 has the following in XComMissions.ini (abstracting most of the syntax details):

 

-GlobalAdvent a,b,c,d

+GlobalAdvent a,b,c,d,e

 

Mod2 has the following in XComMissions.ini:

 

-GlobalAdvent a,b,c,d

+GlobalAdvent a,b,c,d,f

 

How can these both possibly *work*? There will be no error on the screen, but I don't see how the list can possibly wind up as "a,b,c,d,e,f". That is what I am proposing to address by providing uc functions like "add enemy e to list GlobalAdvent".

[DerBK]

While there's a problem there, i don't think it's as big as it's made out to be.

 

The AdventGlobal and other inclusion lists aren't THAT important actually, because most pods are pulling their enemies from the EXclusion lists at the top, specifically "Open" and "NoTerrorOrBosses". And those only need to be added to if the modder wants to EXCLUDE any units that should't spawn (like a Berserker variant that shouldn't spawn outside of Terror missions). So every unit that is added by a mod can automatically appear in most pods.

 

However... Enemies from different mods can't appear in one pod together unless a compatibility patch adds the followers from one mod to the leaders of the other one (and vice versa).

Making such a patch isn't that difficult, but making an error in them will cause CTDs - so such a patch would have to be painstakingly updated whenever one of the mods updates his templates. Obviously that's a huge source for errors and not really worth it imo.

 

 

What i decided to do with Better Advent is letting a good amount of leader units stay vanilla. These vanilla leaders can field any follower units from other mods.

This way you can use Better Advent and a good amount of single unit mods (like ADVENT Priest or Muton Demolisher) as well.

 

Note that if you add to many you may run into issues with the spawnweights getting unbalanced. For example, if i add a Muton to my mod, i can set up the spawn weights in a way that only makes other Mutons appear less in favor of the new Muton. If another Mod adds a Muton, his spawnweight will be calculated against the total of all units. That's not a problem for one, two or even seven mods. But add too many and it possible could become one.

There's not really a way around that without throwing all of them into one mod. But you'd have to use a lot of them before noticing any adverse effects, so it's mostly fine.

 

 

EDIT:

That being said, i am of course open to a clean solution that adds enemies to the InEx lists via an .uc.

But i have no idea how to do that, so someone would have to give me the code for that... :tongue:

Edited March 21, 2016 by DerBK

[davidlallen]

It would be very helpful if you could write a short guide, based on what you have learned, to modifying XComMissions.ini. You have mentioned relationships between the leader and follower, which I have not figured out. My ultimate goal for this part is given here:

 

http://forums.nexusmods.com/index.php?/topic/3922140-human-opponents-are-invisible/

 

I would like to have missions against all human teams. I have built the units, and now I am struggling a little to put them into missions.

[DerBK]

I thought about wrinting up a complete guide on making new enemies, but doing a proper one would take a lot of time out of what i currently need to spend on bringing my own mod forwards.

 

I'll... think about it once i have a little bit less on my plate. No promises.

 

 

 

On the XComMissions.ini:

 

Only few encounters depend on the AdventGlobal list, as i mentioned most pull from "Open", "NoBosses", "NoTerror" and "NoTerrorOrBosses". These aren't INclusionlists, they are EXclusionlists. That means without editing anything, they will already contain any new units you create.

 

Short overview of the pod creation process as i understand it:

 

When the pod is created, a leader for that pod is chosen from the available units. Which unit is chosen, depends on the spawnweights and the Min/Max forcelevels for the units belonging to the InEx list.

 

Spawnweights and Forcelevels are found in the GameData_Charstats.ini. The spawnweights are assigned seperately for followers and for leaders. By assigning these values you also decide which units are actually followers, leaders... or both.

 

Once a leader is decided, he is then assigned followers from that leaders SupportedFollowers, again ignoring those that might not be in the InEx lists from Missions.ini or outside of the Min/Max forcelevel borders.

 

 

Oh, and there's a line that's supposed to limit the number of enemies of that type that can spawn in a pod, but it doesn't seem to work. *shrug*

 

 

So, in conclusion, the GameData_CharStats is A LOT more important to pod makeup than the Missions.ini. To be honest, i could probably delete Missions.ini from my mod and it would hardly even matter. The meat of the enemy spawning is done with the individual unit parameters in the CharStats.ini.

 

 

Now to your special case:

 

What i described above is the way that random pods are generated. To get your humanlike units into pods together could be tricky because you probably want them to be equal in importance and all have the same chance of showing up. However, you need to designate a leader or two and assign the others as followers if you'd want to go that way.

 

 

So instead you may want to set up custom encounters and add them to the Missionschedules. This would be done in Missions.ini.

 

A missionschedule looks like this:

MissionSchedules=(ScheduleID="SabotageCC_D3_Standard",           IdealXComSpawnDistance=28,           MinXComSpawnDistance=24,           EncounterZonePatrolDepth=8.0,           PrePlacedEncounters[0]=(EncounterID="SabotageCC_Patrolx3", EncounterZoneOffsetAlongLOP=3.0, EncounterZoneWidth=26.0),           PrePlacedEncounters[1]=(EncounterID="SabotageCC_Guardx3", EncounterZoneOffsetAlongLOP=-11.0, EncounterZoneWidth=20.0),           PrePlacedEncounters[2]=(EncounterID="OPNx2_Weak", EncounterZoneOffsetAlongLOP=-24.0, EncounterZoneWidth=4.0, EncounterZoneOffsetFromLOP=-10.0, EncounterZoneDepthOverride=36.0),           MinRequiredAlertLevel=3,           MaxRequiredAlertLevel=1000)

That's Gatecrasher on Legendary. You see 3 pods (or "Encounters"): "SabotageCC_Patrolx3", "SabotageCC_Guardx3" and "OPNx2_Weak"

 

You can Ctrl+F for these in the mission.ini to see how they are put together. OPN_Weak builds the pod the random way (as described above), the other two are fixed.

Maybe creating fixed encounters for your groups and tying them into either existing encounters or new ones is what you want to do.

 

Be careful that those edits do not conflct with popular mods like IESS+, however.

Edited March 21, 2016 by DerBK

[Azworai]

I can attest that I haven't had issue running Der8K's A Better Advent alongside Long War's Muton Centurion and an older version of Indigoblades Advent Ascended mods. It just throws more into the mix, as he said.

[davidlallen]

@ DerBK, thanks, that was really helpful. There are a number of different aspects to missions. I have gone through the ini file and started finding the related uc code.

 

Here is what I got out of the structure of DefaultMissions.ini.

 

1. The "top level" is at the end of the file, where arrMissions entries are added. These are the real missions, such as "hack device" and so forth. Each arrMission refers to a number of MissionSchedules.

 

2. One MissionSchedule corresponds to the set of pods that will be dropped in a mission. Depending on difficulty, one of the MissionSchedules for each arrMission is selected. The MissionSchedule, for example Guerilla_D1_Standard, contains a list of PrePlacedEncounters, each of which corresponds to one pod that is required to appear during the mission. The key field of the PrePlacedEncounter is the EncounterID, such as OPNx2_Standard. These are defined in a ConfigurableEncounter. The vast majority of the ConfigurableEncounters are either Advent encounters, or Open encounters, which are handled differently.

 

3a. Advent encounters are limited to enemies on the AdventGlobal include list. So if you want your new enemy to appear in advent missions, you have to add this to the AdventGlobal list.

 

=> I still don't see how two different mods could both add members to this list. Maybe that never actually happens and the mod enemies only appear in open encounters?

 

3b. Open encounters mostly use the NoTerrorOrBosses exclude list, which means any enemy defined in any uc file can be picked up.

 

4. Once an encounter is selected, then based on the force level, one leader is selected. For advent missions, only leaders on the AdventGlobal list are allowed; for open missions, usually, the NoTerrorOrBosses leaders are eliminated. For each enemy defined in the uc files, there is a min/max leader force level range, and a weight; so one leader is selected using these weights.

 

5. The selected leader has a list of legal followers. A list of potential followers is created by excluding ones outside the force level range, and then selecting from this list gives the actual followers.

 

=> Is that all correct?

 

So, for a first attempt at a human only open mission, I could change all the enemy leader force level ranges to 98/99, which removes them from contention. Then add my own human leaders and followers. I find it awfully hard, and anyway inflexible, to make this kind of change by using -/+ lines in the ini file. So I will study if all these changes can be done in a uc file.

 

Well, it should keep me busy for a couple of days.

Edited March 22, 2016 by davidlallen