Amineri Posted May 20, 2013 Share Posted May 20, 2013 (edited) Now that the three bug fixes have gone through pretty extensive testing in both Long War and Merciless, I've released a ToolBoks Custom Mod that applies all three bug fixes. http://xcom.nexusmods.com/mods/107 This shouldn't be necessary for those running those mods, but will be useful for those that like playing the vanilla game. Currently includes is:1) Fixing equipment loss when squad lost2) Fixing interceptor weapon loss when shot down3) Fixing alien turn-skipping when overwatched+flanked ----------------------------------------------- I'm (in the background) currently researching the bug that prevents Revived soldiers from getting one free move back: The relevant code for reviving stabilizing soldiers (with the Revive perk) is: if(kAbility.m_kUnit.GetCharacter().HasUpgrade(56)) { kTarget.Stabilize(); kTarget.SetUnitHP(int((float(kTarget.GetUnitMaxHP()) * XComGameReplicationInfo(class'Engine'.static.GetCurrentWorldInfo().GRI).m_kGameCore.0.330) + float(1))); kTarget.GiveOneMove(); } It is supposed to1) Stabilize the unit, removing it from the "critically wounded" state (WORKS)2) Give the unit MaxHP*0.33 + 1 HP (WORKS)3) Give the target 1 move action (BROKEN) Edited May 20, 2013 by Amineri Link to comment Share on other sites More sharing options...
Yzaxtol Posted May 23, 2013 Share Posted May 23, 2013 (edited) Sorry for being the bearer of bad news but.... 100% confirmed. Alien will still skip a turn if they need to reload and xcom operatives are anywhere close enough to threaten them. Edited May 23, 2013 by Yzaxtol Link to comment Share on other sites More sharing options...
Amineri Posted May 23, 2013 Share Posted May 23, 2013 So you are saying that aliens aren't able to perform the reload action if they are overwatched? Or just if there are XCOM soldiers within sight? Link to comment Share on other sites More sharing options...
Yzaxtol Posted May 24, 2013 Share Posted May 24, 2013 At first I thought it was overwatch, when I was trying to get a wounded guy for my trailer, but even when I skipped a turn the aliens would too until I pulled my men back out of sight range or atleast 90% of it. Link to comment Share on other sites More sharing options...
johnnylump Posted May 28, 2013 Author Share Posted May 28, 2013 I'm updating the OP ... added Combat Drugs perk not doing what it says it will to the list of possible bugs. Link to comment Share on other sites More sharing options...
Amineri Posted May 28, 2013 Share Posted May 28, 2013 Sorry for being the bearer of bad news but.... 100% confirmed. Alien will still skip a turn if they need to reload and xcom operatives are anywhere close enough to threaten them. I did a little bit of tracing on this and found the following AI code snippet relating to reloading in XGAIAbilityDM.AI_IntangiblesScore: case 45: kWeapon = m_kUnit.GetInventory().GetPrimaryWeapon(); if(kWeapon != none && (kWeapon.GetRemainingAmmo() == 0) && (!kWeapon.HasProperty(18))) { fScore = 1.00; } This creates a pretty high priority bump for the Reload action if the AI unit's weapon is out of ammo (effectively a +100 priority bump). I'm not sure what would be preventing any action from being taken, however. Link to comment Share on other sites More sharing options...
dubiousintent Posted May 29, 2013 Share Posted May 29, 2013 Any chance GetRemaingAmmo is returning a negative value? Or one that one won't allow firing but is non-zero? (Which is why thresholds can be preferable to hard equality tests.) What happens in the case of ties: if more than one available action has the same fScore? Is there a tie breaker? -Dubious- Link to comment Share on other sites More sharing options...
Amineri Posted May 29, 2013 Share Posted May 29, 2013 Any chance GetRemaingAmmo is returning a negative value? Or one that one won't allow firing but is non-zero? (Which is why thresholds can be preferable to hard equality tests.)It might be. There are a lot of tests for remaining ammo == 0 all through the code. ApplyAmmoCost doesn't check for negative values... function ApplyAmmoCost(int iCost) { iAmmo -= iCost; if(iAmmo == 1) { iAmmo = 0; } //return; } Why this isn't if(iAmmo <= 1) I don't know What happens in the case of ties: if more than one available action has the same fScore? Is there a tie breaker? -Dubious- Actually what happens is:1) AI retrieves full ability list from game (same code as for human player to display in Tactical HUD)2) AI filters certain actions based on circumstances (e.g. can't move if suppressed)3) Remaining abilities are priority scored based on circumstances4) Priorities are used as a weighted randomizer to determine ability used. Example (w/ completely made up numbers) :Fire action has a priority of 50Move action has a priority of 100Mind Merge action has a priority of 150 The total weight is 50 + 100 + 150 = 300 Fire has a 50/300 = 16.7% chance of being takenMove has a 100/300 = 33.3% chance of being takenMind Merge has a 150/300 = 50% chance of being taken Link to comment Share on other sites More sharing options...
dubiousintent Posted May 29, 2013 Share Posted May 29, 2013 Okay, I get the theory. But is there a chance the RNG could produce a result number that falls in between one of the calculated action priorities, or just outside of the combined range? If 'no action' is supposedly not one of the possible results, then logically it must be occurring because the result is not a specified action. If the calculation is producing fractional results, then rounding errors can become non-trivial. Though the rate of incidence makes that pretty unlikely, I admit. More likely is a logical condition that is missing or failing somewhere, which I am sure you have already looked for. Just hoping to spark an idea. -Dubious- Link to comment Share on other sites More sharing options...
Amineri Posted May 29, 2013 Share Posted May 29, 2013 Good thoughts! The randomization doesn't choose the ability in the manner you describe. Each priority is converted to an integer value, and the sum of all ability priorities is computed. The AI then picks SyncRand(SumAbilityPriorities). It then loops through the abilities available, incrementing current sum using each abilities priority until the current sum exceeds the randomly picked value. This code looks pretty solid to me. From what I've seen, the errors that cause no actions to take place are due to filtering out so many abilities that there are no valid abilities left to perform. For example, an alien that is overwatched or suppressed has the bShouldNotMove flag set. However, being flanked triggers the bShouldMove flag, which causes all non-move abilities to be filtered out, leaving no valid abilities. I think what happens to let the unit fire is that when the move action is attempted, it defaults to a fire action when it is unable to move. The glitch that I fixed was computing a NaN result for the move ability priority, which was causing it to not even be on the list at all. Suppression is different in that it actually will filter the move ability off the list, I think. To confirm this you could suppress and flank a unit, and see if it will shoot at a unit in the open. From what Yzaxtol is describing, it seems as though the alien is getting stuck in a "can't move state", but it cannot fire because it has no ammo. If it is flanked then the Reload action would be filtered because it must move. Since he is seeing it occur turn after turn, it isn't likely to be an error in the randomizer. There should be some code in the SwitchToAttack code (that the move action defaults to if it can't find a move) that if the unit cannot fire because it is out of ammo then it will reload as its default action. Or, as Yzaxtol pointed out in the Ammo R&D thread, we could make the aliens always have unlimited ammo (as a part of their superior technology). Link to comment Share on other sites More sharing options...
Recommended Posts