LeaderEnemyBoss

So I have observed some strange behaviours since the patch hit, maybe someone can help me: 1. When i try to launch xcom via the "start debugging" feature of modbuddy, i get the following error as soon as i press the "play" button of the launcher: Steam Error Application load error V:0000065432 I can still start xcom 2 normally (through steam or file explorer), however it is a bit annoying 2. Logging doesnt seem to work anymore. The console still displays script errors en masse (the annoying messages that were introduced with the AH-patch), but normal log messages like those that cheat commandos produce or stuff that I put in my code dont appear anymore. I already did the usual stuff (delete config folder, verify gamecache of SDK and XCom 2) Would be gla dif anybody could help me, especially the second issue is a dealbreaker atm :/

What you had at first basically would achieve this. It implements a stat check, the higher the soldiers will stat, the higher the chance to resist the the effect. So basically the following should do the work: UnconsciousEffect = class'X2StatusEffects'.static.CreateUnconsciousStatusEffect(true); UnconsciousEffect.MinStatContestResult = 5; UnconsciousEffect.MaxStatContestResult = 0; UnconsciousEffect.bRemoveWhenSourceDies = false; Template.AddMultiTargetEffect(UnconsciousEffect); I dont really know how the numbers work, but you can mess around with them to alter the chances.

try to change Template.AddTargetEffect to Template.AddMultiTargetEffect or something similar (dont know the exact syntax atm). I dont have the modbuddy available atm, but AddTargetEffect references your (single-)targetstyle, which is this:Template.AbilityTargetStyle = default.SelfTarget;

1.to create an enemy unit an control it yourself: dropunit valkyrie 1 (the 1 at the end is the team, 1 is enemy, 0 is xcom if i remember correctly) 2.to control enemy units: X2allowselectall 1 (the interface is a bit buggy in this mode, you have to end the xcom turn to use the alien)

in the as-editor (the same where you can preview the animations). You can add notifies to animation sequences, these notifies can be a range of things, for example particle effects.

easiest way to do this this is: 1. Copy the animationsequence you want to use in a new animset (rename it!) 2. add the animset to the enemies archetype 3. you can now add particle effects to the animationsequence similar to how some other sequences do it (codex-malfunction e.g.)

Look up the rapidfire ability, it internally uses two abilities and should be a pretty good template for what you want to do

Can you post your code? I worked some with two staged abilities, maybe I can offer advice.

There is StartObjective and ForceCompleteObjective, i dont really know how to use them. Probably something like "StartObjective T1_M2_HackACaptain true" and "ForceCompleteObjective T1_M2_HackACaptain". PrintActiveObjectives may also be useful. EDIT: Maybe its also T1_M2_S3_SKULLJACKCaptain

Well if my theory is correct, this would be how to prove it: get a shadowchamber (givefacility shadowchamber 3) to see whether game recognizes that you have seen the enemy (officer in this case). spawn a mission (e.g. spawnmission missionsource_guerillaop reward_supplies on strategy map), enter the mission. Use "powerup" to comb the mission map and see al the enemies. Use "endbattle" to end the mission. Spawn a new mission, advent officers should no be less "pushy" with their spawning, especially if you set their leaderweight to something like 1.

How do you test the spawning behavior? I noticed some interesting quirks of the spawning system that can skew your testing. For example: if a new enemy is eligible to spawn, the game raises the spawn weight of this enemy astronomically. I noticed this when i developed my riftkeeper and Venator mods, two enemies that are balanced around showing up "sometimes" but not in every mission. I tested spawn behavior in an ongoing test campaign (spawned many missions via cheat command and have a screenlistener in place that reads the missions pod composition) and it would almost always appear, even with a spawnweight of 1. After I saw it once, spawn behavior was as expected (that is almost no showups with spawnweights now on 1 ^^). For this reason I would advice against using TQL for testing spawnrates, since it doesnt necessarily represent ingame spawning behavior. EDIT: Also if the main story objective "skulljack a captain" is active, this may influence spawnrates

I did it! ...well mostly. The order in which mission caching and the updating of shadowchamber strings has to be done in order to achieve the desired result for Guerilla ops is quite ...strange. There is a "primary" Mission (the one that gets selected when one chooses to use the mission button on the bottom of the strategy screen) and two secondary Missions by default. I had to make sure the primary Mission got cached before the UIMission screen initialized, else strange things would happen. All in all my code is probably messy, but it does the job. I can replace enemies if too much of them are detected, and the shadowchamber reflects this correctly. The only thing i probably cant account for: if UpdateShadowChamberMissionInfo returns true, my careful work will probably get destroyed. However I am sure the users of my mod can forgive slightly unaccurate shadowchamber info if that means the mission will be easier. For this reason i call my replacement function again with OnPreMission just to make sure that everything works. The Replacement function itself is not very well developed but it does the job for my mod. It just replaces my enemy with a preselected different enemy depending on Encountername (so Boss encounters get a Sectopod or a Gatekeeper). A spawnsystem Overhaul mod would ofcourse need to take settings like Spawnweights, Forcelevels and MaxCharactersPerGroup into account to achieve good results. For the curious (its a bit long and messy to post here): https://dl.dropboxusercontent.com/u/61206138/MissionSite_Listener_Riftkeeper.uc https://dl.dropboxusercontent.com/u/61206138/X2DownloadableContentInfo_Riftkeeper.uc

Thanks once again for your input josh :). Sadly that doesnt seem to be useful for what we are trying to do. For a start I want to limit the spawnrates of my strong lategame enemies to a configurable amount without relying on the missions.ini (because compatibility stuff). I also tried to use UpdateShadowChamberMissionInfo as a simple hook without returning anything actually, sadly the guerilla ops mission behavior is kinda funky. The "primary" GOps mission is easy to change, updating the shadow chamber string can be done "manually". However the other two missions behave strangely. When i read the encounter data via UpdateShadowChamberMissionInfo or screenlistener, the console output is something entirely different than what the shadowchamber displays. Only after a second try (leaving the missionscreen and initiating it again), the console output and the shadowchamber info matches. At the moment I have the following idea: use onlosefocus on a strategymap listener to generate encounters for all missions that dont already have them and apply my changes. I am pretty sure for a programmer my ramblings are cringeworthy but ...whatever I'm just trying get stuff done! :p

So if anyone is interested: replacing enemies in missions is indeed very easy. As soon as the Encounterlist is populated, one can just change the template names of each individual enemy to ones liking. The difficult part is getting the shadowchamber to show the updated data correctly. Until now I tried to use a missionsite screenlistener. This works well for everything except for guerilla ops. The problem here is, that clicking on the button of one of the three options doesnt change the screenstack and therefore is not hookable afaik. There is the new UpdateShadowChamberMissionInfo hook. By the name of it one would assume that it just updates the displayed enemy names, but sadly returning true in this function rerolls the whole encounterlist for the selected mission which makes this useless for replacing single enemies.

I have to agree with davidlallen. This thread is not very "attractive" for those users that actually use the search function. I do so regularly, and when one of the search result is a mega thread such as this I always groan and hope I find a better result :tongue:. Some boards encourage mega threads to avoid a flood of new threads. However this board isn't really in danger of being "flooded", so making new threads for questions is probably not a big deal. It did its job when the game was fresh and there were lots of "groundwork" questions to the more experienced modders of LWS. Luckily we are now at a point, were the basic stuff has been mostly covered by tutorials, videos and this thread.