Jump to content

R&D Tactical bug hunts (suppression and alien skipping turn)


johnnylump

Recommended Posts

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 lost

2) Fixing interceptor weapon loss when shot down

3) 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 to

1) 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 by Amineri
Link to comment
Share on other sites

  • Replies 89
  • Created
  • Last Reply

Top Posters In This Topic

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 by Yzaxtol
Link to comment
Share on other sites

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

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

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

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 circumstances

4) Priorities are used as a weighted randomizer to determine ability used.

 

Example (w/ completely made up numbers) :

Fire action has a priority of 50

Move action has a priority of 100

Mind 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 taken

Move has a 100/300 = 33.3% chance of being taken

Mind Merge has a 150/300 = 50% chance of being taken

Link to comment
Share on other sites

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

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

  • Recently Browsing   0 members

    • No registered users viewing this page.

×
×
  • Create New...