Store Page
XCOM 2
All Discussions Screenshots Artwork Broadcasts Videos Workshop News Guides Reviews
XCOM 2 >  Workshop > BlackDog's Workshop
77 ratings
[WOTC] Protect the Device - AI Fix
Description Discussions0 Comments22 Change Notes
   
Award
Favorite
Favorited
Unfavorite
War of the Chosen, Map, Gameplay
File Size
Posted
Updated
141.509 KB
2 Oct @ 3:30pm
5 Oct @ 11:44am
4 Change Notes ( view )
Created by
BlackDog
Online
See all 157 collections (some may be hidden)
5,182 Unique Visitors
1,449 Current Subscribers
168 Current Favorites

Subscribe to download
[WOTC] Protect the Device - AI Fix

Description
Mod Description
This small mod fixes a couple of long-standing issue with 'Protect The Device' missions in XCOM2:

1. Many of the enemies on the map can end up charging directly towards & clustering around the objective before the XCOM squad is revealed.

2. Once revealed, multiple aliens can be allowed to take shots at the objective

In the base game, this is little more than an annoyance, but with mods adding more enemies to pods, more pods and wider enemy varieties with high output damage, it can cause these missions to become unwinnable and/or unfun to play.

The issue happens due to the mission type being set up to trigger yellow alert from the beginning (similar to terror missions) and (I believe) a misconfiguration of one of the pod jobs.

This mod changes a few different behaviours so that units which are not revealed will patrol normally (and walk around, instead of running). Once XCOM is revealed, some pods (maximum of 2) may start running towards the objective, as before, if they don't have any LOS & depending how many pods are on the map.

Additionally, guard-rails have been added to the AI target evaluation to cap the number of attacks that can be made on the objective per-turn (default 1) once aliens are in red-alert. This can be adjusted in the XComAI.ini config file if desired (look for Param[2]="1" on line 5 and change "1" to the maximum total number of attacks you want to allow on the objective per-turn).

Compatible with A Better Advent, A Better AI and A Stronger Advent.

Any mods which forcefully over-ride mission definitions may over-ride the alertness changes made here as well so be aware of that. If any significant incompatibilities arise, I can look at more forceful approaches to adjusting the mission definitions through script.

I'm also hoping to fix the dreaded 'large units stomping the objective' bug here but that looks to be a bigger challenge at the moment!

The alertness and pod job changes will have no effect on LWOTC, though the AI adjustments for revealed pods may work

Notes
This mod has not yet been extensively tested - if you decide to use it, I welcome any feedback as to whether it improved your experience on these missions & to provide any suggestions for improvements :)

The mod will have no effect on missions that have already been generated on the geoscape but is completely safe to add and remove from ongoing campaigns as needed (it's config only).
22 Comments
< >
LeyShade 26 Oct @ 5:44am 
@BigHillsBigLegs - Untrue. Reshi and her Syusa led Requiem is very well documented by Reshi and is a feature of the Aml O+E . You just need to take the time to dig through the config files and change anything you don't like to your own taste.
LeyShade 26 Oct @ 5:41am 
@BlackDog - There is only base game units added to your ChargerEngaged job, any reason why? Enemies not in the array won't pick up the changes at all, or apply them outside the AI logic, and the factions and Reshi's work all have their own versions of GenericTargetEvaluations that yours won't touch, so it doesn't effect them.

Trying to understand if this was design oversight or intention =)
BlackDog  [author] 21 Oct @ 2:25pm 
Yeah, requiem does make pretty extensive changes to the ai, and I think makes changes to the pod jobs system as well, so it may well be overriding the light-touch changes I'm making here. I'm also bit reticent of making these changes take priority since they could end up messing with other stuff which goes out of scope of the protect device missions. I'd have to look into it some more and see if I can softly adjust how requiem does it without breaking things (and/or angering reshi - she's fierce :D)
Slackboy101 15 Oct @ 11:59am 
Fucking Chaos Legion...
BigHillsBigLegs 10 Oct @ 1:46pm 
I'm not sure if the requiem legion mod is conflicting with this because enemies are still right on top of the objecttive like their on a lunch break, that mod does change ai, aurthor isn't specific about anything
Oniwabanshu 9 Oct @ 8:30pm 
LWotC seems to change yellow alerts somehow, enemies beeline towards me once i engage a pod, but i am not planning to use that mod ever again.
Thank you for fixing enemies demolishing the objective in one turn (when they can hit for 10 points each time the device lasts nothing).
Cyber Von Cyberus 9 Oct @ 7:18am 
Thank you, this mission was unplayable with extra pods.
BlackDog  [author] 8 Oct @ 11:19am 
@Pleiades - This actually seems to play well enough with yellow alert from my limited testing. The pods still patrol in green alert before XCOM is revealed correctly and the non-guard pods patrol around trying to find xcom rather than crowding the objective, even once revealed. The #shots seems to be respected too. Whilst some of my pod job changes are overridden by YA, the changes are not immediately obivious from a pure gameplay perspective.
Pleiades 7 Oct @ 10:08pm 
Thanks for the insight! I'll use it in my playthrough and I'll let you know how my next Protect the Device mission goes! :3
BlackDog  [author] 7 Oct @ 11:20am 
I haven't tested this with yellow alert, I must admit - it's likely that YA will override the alertness changes so they probably would still attempt to crowd the objective, though the guardrails for maximum shots on the objective once activated should still stand. I would expect a similar behaviour with pods alerted by ai to ai activation - once they're activated, the charger pod job which can make some pods crowd the objective becomes valid again but the number of shots changes should be ok. I could take a slightly more aggressive approach to overriding alert behaviour too but will need further investigation and testing. I am separately looking into the 'stomping the objective' bug, but that will need some accompanying highlander changes so will take a bit of time :)