DerBK

Flush is supposed to make a target run away for one turn? Not sure on the details, but somewhere in class XComGameState_AIGroup.uc is a retreat function that triggers once you reduce a pod to 1 member. Maybe try finding out how that works exactly and try to see if you can either manually trigger it or if you can make your own ability from it?

on 1: Ini files are basically stupid texts, they don't carry functionality itself. For an ini file to work, there needs to be a function, a class, somewhere in the .uc files that read out the ini and actually do stuff. All the branches of the AI trees eventually lead to an action or a condition that will need to be handled by a class. If you want to know more, open up the Default project and make a projectwide search for "IsAbilityAvailable". That will lead you to where in the uc's the ability is defined. on 2: Yes, this is something that modders should very much worry about. I actually started a big overhaul of my AI file yesterday and i plan on doing exactly what you propose, adding the prefix "ABA_" to many of my behaviours. (My biggest regret with Better ADVENT is not doing that to all of my character and weapon templates as well.) So what happens if you have two entries in the behaviours with the same name, one from mod A and one from mod B? The debugger will show a redscreen output stating that it is going to ignore one of them. Which one, does indeed depend on whatever passes as a load order for XCOM. In the case of TryFaceoff, ignoring one of them shouldn't cause much of a problem. Mod A and B are probably doing something very similar there so whichever one wins, stuff will most likely still work when a unit from mod A calls the TryFaceoff line defined from mod B. You are of course right that it's better to avoid it from the start by using a mod specific prefix.

Oh my, you just went right for the good stuff, didn't you :) The AI trees that i build for my custom enemies are (a lot^^) less complicated than the ones needed for a human enemy with 5 or more active skills. I actually didn't dive really deep into more exotic things. At the moment, i usually avoid spending a lot of time on troubleshooting abilities that give me grief - my mod is better off if i take the time to make a different ability instead. I am still at the phase where volume is the name of the game, in a month i will probably be looking at the things that i had to abandon. Like enemies with grenade launchers or Gremlins... But maybe i can throw some helpful things your way nonetheless! 1 - I don't know about any better way of monitoring the decision trees and how the AI goes through its branches. My units behaviour can usually be observed fairly well by just spawning three of them and see what they do when i hit 'End turn'. When i do need to debug something more closely, i use "SkipMove" in a similar way to how swinka suggested using the redscreen output. 2 - Had the same experience when i tried to give a launcher to one of the Advent Captains. I didn't look into it very far so i don't know what's the problem there. 3 - There is no such thing as a sniper AI in vanilla XCOM. Here's the one i did for my Sniper Captain: +Behaviors=(BehaviorName=TryShootOrReloadOrOverwatch_Sniper, NodeType=Selector, Child[0]=ConsiderTakingOverwatch, Child[1]=ShootIfAvailable_Sniper, Child[2]=NeedsReload) +Behaviors=(BehaviorName=ShootIfAvailable_Sniper, NodeType=Sequence, Child[0]=IsAbilityAvailable-SniperStandardFire, Child[1]=SelectTargetForSniperStandardFire, Child[2]=SelectAbility-SniperStandardFire) +Behaviors=(BehaviorName=IsAbilityAvailable-SniperStandardFire, NodeType=Condition) +Behaviors=(BehaviorName=SelectTargetForSniperStandardFire, NodeType=Sequence, Child[0]=SetTargetStack-SniperStandardFire, Child[1]=GenericSelectBestTarget, Child[2]=HasValidTarget-SniperStandardFire) +Behaviors=(BehaviorName=SelectAbility-SniperStandardFire, NodeType=Action) +Behaviors=(BehaviorName=SetTargetStack-SniperStandardFire, NodeType=Action) +Behaviors=(BehaviorName=HasValidTarget-SniperStandardFire, NodeType=Condition) Nothing too complicated (actually the first new behaviour lines i made for my mod \o/ ), just the setup for the SniperStandardFire ability which should not be folded into the regular StandardShot AI because it uses two actions instead of one. If you want to know if the targeting handles Squadsight, you'd probably need to look into the class behind the SetTargetStack action. Or, more pragmatically, try setting the detection and sight radius of your sniper to just one or two and see if he can still shoot at something. 4 - There's a mod called Advent Priest that adds a healer unit. It uses a psi ability as the carrier for the heal. Looking at that mods files should be helpful. Didn't do so myself yet. I actually experimented with the Gremlin as well. I wasn't able to line up the animations correctly, but the targeting worked. Here's a part of the AI of my (so far unreleased) Tech Commando, a Shieldbearer with a Gremlin that uses Aid Protocol and Heal Protocol: +Behaviors=(BehaviorName=SelectAbility-AidProtocol, NodeType=Action) +Behaviors=(BehaviorName=SelectAbility-GremlinHeal, NodeType=Action) +Behaviors=(BehaviorName=SetTargetStack-AidProtocol, NodeType=Action) +Behaviors=(BehaviorName=SetTargetStack-GremlinHeal, NodeType=Action) +Behaviors=(BehaviorName=IsAbilityReady-AidProtocol, NodeType=Condition) +Behaviors=(BehaviorName=IsAbilityReady-GremlinHeal, NodeType=Condition) +Behaviors=(BehaviorName=HasValidTarget-AidProtocol, NodeType=Condition) +Behaviors=(BehaviorName=HasValidTarget-GremlinHeal, NodeType=Condition) +Behaviors=(BehaviorName=SelectTargetForAidProtocol, NodeType=Sequence, Child[0]=SetTargetStack-AidProtocol, Child[1]=SelectTargetForAid, Child[2]=HasValidTarget-AidProtocol) +Behaviors=(BehaviorName=SelectTargetForAid, NodeType=Sequence, Child[0]=SetNextTarget, Child[1]=ScoreBestTargetForAid, Child[2]=UpdateBestTarget) +Behaviors=(BehaviorName=ScoreBestTargetForAid, NodeType=Sequence, Child[0]=TargetIsAlly, Child[1]=TargetWounded, Child[2]=EvaluateForAid) +Behaviors=(BehaviorName=EvaluateForAid, NodeType=Sequence, Child[0]=ScoreByHP) +Behaviors=(BehaviorName=SelectTargetForGremlinHeal, NodeType=Sequence, Child[0]=SetTargetStack-GremlinHeal, Child[1]=SelectTargetForHeal, Child[2]=HasValidTarget-GremlinHeal) +Behaviors=(BehaviorName=SelectTargetForHeal, NodeType=Sequence, Child[0]=SetNextTarget, Child[1]=ScoreBestTargetForHeal, Child[2]=UpdateBestTarget) +Behaviors=(BehaviorName=ScoreBestTargetForHeal, NodeType=Sequence, Child[0]=TargetIsAlly, Child[1]=TargetWounded, Child[2]=EvaluateForHeal) +Behaviors=(BehaviorName=EvaluateForHeal, NodeType=Sequence, Child[0]=ScoreByHP) +Behaviors=(BehaviorName=TryAidProtocol, NodeType=Sequence, Child[0]=IsAbilityReady-AidProtocol, Child[1]=SelectTargetForAidProtocol, Child[2]=SelectAbility-AidProtocol) +Behaviors=(BehaviorName=TryGremlinHeal, NodeType=Sequence, Child[0]=IsAbilityReady-GremlinHeal, Child[1]=SelectTargetForGremlinHeal, Child[2]=SelectAbility-GremlinHeal) "TargetWounded" and "TargetIsAlly" are already existing conditions that i tied together with the also already existiing "ScoreByHP" evaluation into a new "ScoreTargetForHeal" command. Disclaimer: The above is more of a demonstration and tech test that i did for myself to see how this works. Heal and Aid still use the same conditions etc etc. But the general gist of it should be clear. 5 - No idea. I struggled with that as well and dropped it fairly quickly. Doesn't the Sectopod use three actions in one turn? Not sure. 6 - I did a cone targeting ability for my firebreathing Berserker that works just fine: +Behaviors=(BehaviorName=TryFirebreath, NodeType=Sequence, Child[0]=IsAbilityAvailable-Firebreath, Child[1]=FindPotentialAoETargets-FirebreathProfile, Child[2]=SelectAoETarget-FirebreathProfile, Child[3]=SelectAbility-Firebreath) +Behaviors=(BehaviorName=SelectAbility-Firebreath, NodeType=Action) +Behaviors=(BehaviorName=SetTargetStack-Firebreath, NodeType=Action) +Behaviors=(BehaviorName=IsAbilityAvailable-Firebreath, NodeType=Condition) +Behaviors=(BehaviorName=HasValidTarget-Firebreath, NodeType=Condition) +Behaviors=(BehaviorName=FindPotentialAoETargets-FirebreathProfile, NodeType=Action) +Behaviors=(BehaviorName=SelectAoETarget-FirebreathProfile, NodeType=Action) In addition to that, the actual targeting profile needs to be added to the AI.ini. Important: it gets added under a different header than the behaviour lines! [XComGame.XGAIBehavior] +AoEProfiles=( Profile=FirebreathProfile, Ability=Firebreath, bIgnoreSelfDamage=True, MinTargets=2) More isn't needed... i assume because the cone targeting is keyed into the ability itself and it's referenced in the profile. I guess the most similar ability is Null Lance? Anyways, i tested this by making the firebreather react to different placements of soldiers and it works. 7 - Hm, didn't think about this before. I don't think there's anything about elevation in the AI so far. No immediate idea how to do it either. My gut says it can't be done just with ini editing.

a: Try turning your units into Advents like LeaderEnemyBoss suggested above. I saw similar behaviour as you are, but only with Aliens (f*#@ing Boas!) and not with Advents. Might be a related bug. b: No idea, that's something i didn't look at yet.

Maybe they just don't find an appropriate behaviour tree? Try giving them the one of Advent Troopers for a test, that way they at least know how to shoot, throw grenades and move. To do that, add CharTemplate.strBehaviorTree = "AdventTrooper::CharacterRoot";to their character template. Also i am not sure if you can just leave out so many of the eStats in the CharacterStats.ini as you did. Maybe you do need to set all those lines for ArmorChance, ReserveActionPoints, UtilityItems etc and set them to 0. Again, i suggest looking at the trooper and using his setup as a guide.

It works, but only for units that are definied as Advent in their respective template (bIsAdvent = true, bIsAlien=false). I already reported this bug. Had to redefine Sectopods and Gatekeepers to advent units for my "more Gatekeepers and sectopods" mod. Thanks for this info, that explains SOOO much. Like why my Troopers behave like i want them, but i wasn't able to keep my Boas (a Viper variant) in check. I may have to use that workaround as well until the bug gets fixed. Exactly. And since the majority of encounters are open, this isn't that big of an issue imo. Yep, sounds about right. How about making an InclusionList "HumanEnemies" and linking that in the encounters? That way you don't need to change all the enemy GameData_CharStats and have your logic for pod composition contained to the missions.ini.

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.

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:

"make 100% sure that the SupportedFollowers list in their Character Template does not contain any mistakes or else the game will crash to desktop as soon as the mission is loaded and a Leader is chosen with an unfindable SupportedFollower." That's true. And a huge pain in the ass both for modders that make additional enemies. Besides being a source for CTDs that needs to be double-,triple- and quadruplechecked, this behaviour makes it really difficult to make different mods that add enemies work together more seamless. I wish i could add all the followers from other mods to the SupportedFollowers list of my leader units, for example :/

Targeting works by giving all options a TargetScore. The one with the highest score will be shot at. If you want to get to your goal just with ini editing (and without plowing through all that Mimic Beacon behaviour), you will need to hook into the different target evaluations like for example Behaviors=(BehaviorName=GenericTargetEvaluations, NodeType=Sequence, Child[0]=TargetScoreHitChance, Child[1]=TargetScoreHealth, Child[2]=TargetScoreFlanking, Child[3]=TargetScoreMarked, Child[4]=ApplyDifficultyModifiers, Child[5]=TargetScoreCivilian, Child[6]=AvoidBoundAndPanickedTargets) and add another Child that checks for any of your MECs in sight, if they are in Draw Fire mode, and if both are true, adds a good amount of points to the TargetScore (Ctrl+F the AI.ini for "AddToTargetScore" for how that works.) Now, there are quite a lot of different of these target evals, i don't know if you want to touch all of them. An alternative would be altering the class that decides wether a unit is a Priority target or not. The relevant lines for context in the AI.ini would be Behaviors=(BehaviorName=TargetScorePriority, NodeType=Selector, Child[0]=ScoreTargetIfPriority, Child[1]=AddToTargetScore_0) ; If I'm looking for a priority target, then if the target isn't priority, it should be very negative. Behaviors=(BehaviorName=ScoreTargetIfPriority, NodeType=Sequence, Child[0]=TargetIsPriorityUnit, Child[1]=AddToTargetScore_60) ; set a priority target for very high Behaviors=(BehaviorName=TargetIsPriorityUnit, NodeType=Condition) Maybe you could edit the class behind that TargetIsPriorityUnit condition for a more elegant solution than all the ini edits.

I got two nominations that i love: - Quick Start Such a simple mod, but oh so convenient. Sadly, it hasn't made its way from the Workshop to the Nexus yet, which is a real bummer. - All Pods Activate Another fairly simple change, but this one completely changes how the game is played. Without having to worry about pod activations, gameplay improves a lot in my experience.

FWIW, i figured it out. I needed to add the skills to the weapon template instead of directly to the character template.

Hi there. For my mod i am adding various skills to enemy variants and there is one problem that i frequently run into that i wasn't able to solve yet. Example: I gave a Pistol and the Skill Faceoff to an Advent Trooper. But when the Trooper tries to use Faceoff, the debugger shows me a redscreen with the line UXcomAnimTreeController::PlayFullBodyDynamicAnim - Can't play animation FF_Fire and the animation bugs out. I get the same error when i try to give the trooper Lightning Hands. At first i thought that Troopers just aren't rigged to use pistols, but that's not it - Pistol Overwatch and Return Fire work flawlessly (and look amazing, btw). So what exactly is the problem here?

Haven't tried that, but there's a couple of mods that double pod sizes or the number of pods per map. I think those work exactly like that.

Okay, i just answered my own question. The problem is not as big as i though - but there is one in a specific case (in mine, ofc -.-) Here's the thing: The Lists "Open", "NoBosses", "NoTerror" and "NoTerrorOrBosses" are exclusion lists, meaning that any item NOT in that list can be spawned by the game. This of course means that not editing those lines will automatically include your new characters. This is why the LW Muton can get away without touching any of the lists, remaining completely free from conflicts with other mods that add enemies. Why i stumbled on problems: I changed the "AdventGlobal" list, which is an inclusion list. My mod already has 70+ entries in that line. When it is used together with the popular "Advent Sniper" and "Advent Psi Op", only one of those mods will be able to change the AdventGlobal list - while the others can only spawn from the exclusion lists. That will still mean those guys will show up somewhere, just not in the context of Advent specific spawns... These cases might require some coordination between the mod authors.

Here's what i was talking about in more detail: The XComMissions.ini is responsible for how groups of enemies are generated. The first part are a couple "InclusionExlusionLists", looking like this: InclusionExclusionLists=(ListID="Open", bIncludeNames=false, TemplateName[0]="AdvPsiWitchM3", TemplateName[1]="Faceless") InclusionExclusionLists=(ListID="NoBosses", bIncludeNames=false, TemplateName[0]="Sectopod", TemplateName[1]="Gatekeeper", TemplateName[2]="AdvPsiWitchM3", TemplateName[3]="Faceless") InclusionExclusionLists=(ListID="NoTerror", bIncludeNames=false, TemplateName[0]="AdvPsiWitchM3", TemplateName[1]="Faceless", TemplateName[2]="Chryssalid", TemplateName[3]="Berserker") And so on. Other notable lists are "BossLeader" and "AdventGlobal", for example. Next up are a bunch of "Configurable Encouters", defining groups of enemies that are pulled from the Inclusion Lists above. They decide how a pod is built. They look like this: ConfigurableEncounters=(EncounterID="OPNx2_Weak", MaxSpawnCount=2, OffsetForceLevel=-2, LeaderInclusionExclusionCharacterTypes="NoTerrorOrBosses", FollowerInclusionExclusionCharacterTypes="NoTerrorOrBosses") ConfigurableEncounters=(EncounterID="BOSSx2_Strong", MaxSpawnCount=2, OffsetForceLevel=2, MinRequiredForceLevel=16, MaxRequiredForceLevel=20, LeaderInclusionExclusionCharacterTypes="BossLeader", FollowerInclusionExclusionCharacterTypes="NoTerror") ConfigurableEncounters=(EncounterID="ADVx2_Strong", MaxSpawnCount=2, OffsetForceLevel=2, LeaderInclusionExclusionCharacterTypes="AdventGlobal", FollowerInclusionExclusionCharacterTypes="AdventGlobal") There's a whole bunch of them. Finally, there are "MissionSchedules" which define the number of pods in a mission and the type of the pod (among other things) They look like this: MissionSchedules=(ScheduleID="Guerilla_D2_FlightDevice", MinRequiredAlertLevel=2, MaxRequiredAlertLevel=2, IdealXComSpawnDistance=44, MinXComSpawnDistance=40, EncounterZonePatrolDepth=4.0, PrePlacedEncounters[0]=(EncounterID="ADVx2_FlightDevice", EncounterZoneOffsetAlongLOP=10.0), PrePlacedEncounters[1]=(EncounterID="ADVx2_FlightDevice", EncounterZoneOffsetAlongLOP=-4.0, EncounterZoneWidth=6.0), PrePlacedEncounters[2]=(EncounterID="ADVx3_FlightDeviceBoss", EncounterZoneOffsetAlongLOP=-18.0), ) MissionSchedules=(ScheduleID="Council_D2_Extract", MinRequiredAlertLevel=2, MaxRequiredAlertLevel=2, XComSquadStartsConcealed=false, IdealXComSpawnDistance=48, MinXComSpawnDistance=40, EncounterZonePatrolDepth=4.0, PrePlacedEncounters[0]=(EncounterID="OPNx2_Standard", EncounterZoneOffsetAlongLOP=24.0), PrePlacedEncounters[1]=(EncounterID="BOSSx2_Standard", EncounterZoneOffsetAlongLOP=10.0), PrePlacedEncounters[2]=(EncounterID="BOSSx2_FillStandard", EncounterZoneOffsetAlongLOP=10.0), PrePlacedEncounters[3]=(EncounterID="OPNx2_Standard", EncounterZoneOffsetAlongLOP=-4.0, EncounterZoneWidth=6.0), PrePlacedEncounters[4]=(EncounterID="DKVx2_FacelessAndCivilians", EncounterZoneOffsetAlongLOP=17.0, IncludeTacticalTag="DarkEvent_Infiltrator"), PrePlacedEncounters[5]=(EncounterID="DKVx2_FacelessAndCivilians", EncounterZoneOffsetAlongLOP=6.0, IncludeTacticalTag="DarkEvent_Infiltrator"), ) MissionSchedules=(ScheduleID="Retaliation_D5_Faceless", MinRequiredAlertLevel=5, MaxRequiredAlertLevel=5, MinRequiredForceLevel=1, MaxRequiredForceLevel=6, XComSquadStartsConcealed=false, IdealXComSpawnDistance=48, MinXComSpawnDistance=44, EncounterZonePatrolDepth=4.0, PrePlacedEncounters[0]=(EncounterID="OPNx3_Standard", EncounterZoneOffsetAlongLOP=24.0, EncounterZoneWidth=36.0), PrePlacedEncounters[1]=(EncounterID="OPNx3_Standard", EncounterZoneOffsetAlongLOP=7.0, EncounterZoneWidth=28.0), PrePlacedEncounters[2]=(EncounterID="OPNx3_Standard", EncounterZoneOffsetAlongLOP=-10.0, EncounterZoneWidth=18.0), PrePlacedEncounters[3]=(EncounterID="TERx1_Faceless", EncounterZoneOffsetAlongLOP=15.0, EncounterZoneWidth=36.0), PrePlacedEncounters[4]=(EncounterID="TERx1_Faceless", EncounterZoneOffsetAlongLOP=-1.0, EncounterZoneWidth=36.0), PrePlacedEncounters[5]=(EncounterID="OPNx2_Weak", EncounterZoneOffsetAlongLOP=-14.0, EncounterZoneWidth=4.0, EncounterZoneOffsetFromLOP=-10.0, EncounterZoneDepthOverride=48.0), PrePlacedEncounters[6]=(EncounterID="TERx1_CivilianGroup", EncounterZoneOffsetAlongLOP=33.0, EncounterZoneWidth=14.0), PrePlacedEncounters[7]=(EncounterID="TERx1_CivilianGroup", EncounterZoneOffsetAlongLOP=28.0, EncounterZoneWidth=12.0), PrePlacedEncounters[8]=(EncounterID="TERx1_CivilianGroup", EncounterZoneOffsetAlongLOP=23.0, EncounterZoneWidth=30.0), PrePlacedEncounters[9]=(EncounterID="TERx1_CivilianGroup", EncounterZoneOffsetAlongLOP=18.0, EncounterZoneWidth=44.0), PrePlacedEncounters[10]=(EncounterID="TERx1_CivilianGroup", EncounterZoneOffsetAlongLOP=14.0, EncounterZoneWidth=44.0), PrePlacedEncounters[11]=(EncounterID="TERx1_CivilianGroup", EncounterZoneOffsetAlongLOP=11.0, EncounterZoneWidth=44.0), PrePlacedEncounters[12]=(EncounterID="TERx1_CivilianGroup", EncounterZoneOffsetAlongLOP=8.0, EncounterZoneWidth=44.0), PrePlacedEncounters[13]=(EncounterID="TERx1_CivilianGroup", EncounterZoneOffsetAlongLOP=5.0, EncounterZoneWidth=44.0), PrePlacedEncounters[14]=(EncounterID="TERx1_CivilianGroup", EncounterZoneOffsetAlongLOP=3.0, EncounterZoneWidth=44.0), PrePlacedEncounters[15]=(EncounterID="TERx1_CivilianGroup", EncounterZoneOffsetAlongLOP=1.0, EncounterZoneWidth=44.0), PrePlacedEncounters[16]=(EncounterID="TERx1_CivilianGroup", EncounterZoneOffsetAlongLOP=0.0, EncounterZoneWidth=44.0), PrePlacedEncounters[17]=(EncounterID="TERx1_CivilianGroup", EncounterZoneOffsetAlongLOP=-3.0, EncounterZoneWidth=36.0), PrePlacedEncounters[18]=(EncounterID="TERx1_CivilianGroup", EncounterZoneOffsetAlongLOP=-6.0, EncounterZoneWidth=28.0), ) So basically the whole makeup of the enemies is defined in this one ini. If you were to make a new enemy, lets say a new Sectopod, you'd add it to the InclusionExclusionlists "Boss Leader" and "No Terror" with the next free index. You can leave the rest untouched. The conflict between different mods that make new enemies comes with these InclusionExlusion lists. Every mod will try to remove the standard list and replace it with its own. And my question would be... do we have a way to avoid that? We could make new IncExLists for our own creations, but then we'd run into conflicts because we'd need to touch the ConfigurableEncounters. Not only would that not help, it would also make the enemy mod uncompatible with stuff like "Bigger Enemy Groups" that edit those Encounters.

I'll look into it later today when i have the files in front of me. I'll also have a closer look at the LW Muton again for reference. Maybe i missed something there.

That would mean we can only have one mod that adds new enemies installed at a time because they all need to edit those same lines in the mission.ini. That's a huge limitation.

Not quite. I am not at home, so i don't have a file in front of me, but the missions.ini has at the top a number of arrays where the enemies are grouped together. If i understand things correctly, you need to add new enemies to these groups for them to show up. To do that, i " - " the default line and " + " my own. But if i use another enemy mod, they would do the same.

How does XCOM2 handle multiple mods that edit the same files? Usually, as a mod creator i can avoid changing most things and just extend the files instead without overwriting anything to minimize overlap with other mods. The one glaring exception seems to be the Mission.ini for mods that add new characters. There you have to put the new enemies into the different spawn groups. If you have two mods of this kind loaded, i would expect that only one "wins", locking the other one out. That doesn't seem to be the case, however. For example, people have been using Mods like "Advent Commander", "Advent Sniper" and the Long War Muton with each other and apparently it works somehow. I am not sure why and that worries me, because i need to understand it to ensure that my own mod works with them as well. So my question is: How can i make sure that my mod (the "Better ADVENT" mod) remains compatible with other mods that spawn new enemies?