32 replies to this topic

[FraktalTMG]

While playtesting DoS on WA's fourth disorder mission, I ran into a weird bug. At the beginning of the mission, I successfully accomplished both timed objectives (rushed the Webway Assembly and killed it before it could teleport away, then took out the Land Raider before it got past the first gate), so I began taking my time clearing out the map. I finished clearing out the Chaos side and camped the critical location with my army, but didn't capture it. Then I switched to the orks and began pushing there as well. Except as I'm about to finish up the location the Webway Assembly would've teleported to at the start, I suddenly get switched back to Chaos and cannot switch back, nor do I get any "objective failed" cues.

 

Then as I push at the gate, the instant the Farseer dies, I get a SCAR crash. Log says the crash was triggered by the Rule_Objective_Kill_The_Farseer section, which force-switches back to Chaos and removes the button to switch back to the Orks. As I look back at the Ork base, I see no base and a single Vyper where the Ork base used to be. So I'm guessing what happened is that the Vyper killed the Ork HQ without me noticing (as the script that checks if the HQ is alive does not give the "objective failed" cue if it's dead, it just throws back to Chaos without warning), which caused the game to remove the faction switch button as proper. But when Taldeer is killed, the game tries removing the button again but since it's already been removed, null pointer exception. To test this, I commented out the button removal in the Rule_Objective_Kill_The_Farseer section - and indeed, the SCAR crash goes away and I can move Crull to the objective to finish the mission.

 

How in the world did this get past Relic's playtesting? I know enemy attacks on this mission are nowhere near heavy enough to overrun the player's bases, even on Insanity, but still. So then, question. If I were to include in the script a boolean variable that gets set to true if the button has already been removed and I check its value before doing any removing, is the variable's value preserved when the game (auto)saves?

Edited by FraktalTMG, 24 February 2019 - 11:08 PM.

[fuggles]

I doubt you could hack it mid mission like that, although potentially could chuck a variable in oninit. You could easily patch the scar yourself to make it work in the future if you restarted.

[Kasrkin84]

Rather than create a new variable you could just run a check using the Button_Exists(buttonID) function before removing the button.

[FraktalTMG]

Mind, I might be wrong that the button removal is causing it. It could be caused by a rule removal instead.

Util_SGroupAbilityButton_Remove(g_buttonID1)
Rule_Remove(Rule_Button_Click)
Rule_AddDelay(Rule_Remove_Button_Delayed, 4)

One of these three is causing the SCAR crash.

[Kasrkin84]

What does the log say?

[FraktalTMG]

-- Log file for all error messages related to the Scar --

 *ALERT: Error removing SGroup visibility for SCAR button '1' - button does not exist
  Lua             WXPButton.scar                 Ln  102 (Util_SGroupAbilityButton_Remove)
  Lua             DATA:Scenarios\SP\MSD4.scar    Ln 3372 (Rule_Objective_Kill_The_Farseer)
Could not execute rule: Rule_Objective_Kill_The_Farseer
FATAL Scar Error while running rules - Execution has been paused.

[fuggles]

Hard without seeing the whole code but nothing an if couldn't resolve.

[Kasrkin84]

Yeah, it's the button that's the problem. Just add a check to make sure the button exists before removing it. If you want to be safe, do the same for the Rule_Remove as well (i.e. add a Rule_Exists check).

[FraktalTMG]

Playtesting DoS in DC's campaign, results are mixed.

• The AI improvements do not appear to be in effect at all during stronghold battles. In regular battles, however, they work as expected. In particular I love the AI moving to assist an ally who's under attack by the player, mostly because it makes defensive battles on well-fortified maps go even faster. On offensive battles against Eldar, however, it's pure hell.
• If I manage to wall the AI into its base early enough, it gets out vehicles very noticeably later, if at all. Not because it doesn't have resources; it has, it's just blowing all of it on nothing but basic infantry suiciding against my barrier force.
• Related: Eres Badlands is a bit tricky because camping home means the AI builds up an overwhelming force, but camping near the AI causes the AI to go hyper-aggressive and fulfill my kill quota sooner than I want.
• The AI's behavior of running away from melee units in the exact opposite direction is fine for the most part, but it doesn't seem to care if does so results in it fleeing towards the rest of my army. Saw it in a Necron vs Tau match: Fire Warriors started picking off Necron Warriors, I teleported the Necron Lord to the opposite side of the Fire Warriors and engaged in melee, Fire Warriors ran towards the Necron Warriors and promptly got gaussed to death.
• The AI's fixation on deploying commanders above all else is even worse than in the unmodded game, particularly with the Imperial Guard. I don't even understand the reasoning; if your base is under attack and the General just got killed before he even got one kill in, what's the point of retraining the General instead of more Guardsmen?
• On the other hand, however, the Imperial Guard AI is now flat-out impossible to rush down early. Attacked with Eliphas, five honor guard units and two full squads of Chaos Marines, entire force got obliterated by the IG HQ's fixed weapons before they even got it down to yellow health and despite having half the map's SPs under my control, I've got zero resources due to the two squads having overwatched it all away.
• Related: I also had trouble as Necrons on the exact same map with the exact same opponent, only difference being the AI having a full honor guard which made any non-cheating tactics on my part useless. However, one time when I wasn't looking (I briefly left the computer after saving, unaware that the game unpauses after saving for some reason), one of the IG AIs got into my base, destroyed everything... and then did nothing. I didn't lose because the Monolith was on the move and halfway across the map, but the AI made no attempt to seek it out, or even go after my half-a-map's worth of SPs; they just stood where my base used to be, moving a few steps in a random direction every once in a while but otherwise being still, as if the AI completely failed to consider that the player might have buildings anywhere other than their starting location and was wondering why the match didn't end yet.
• Also in this same battle, I've seen the AI suddenly run up to a Critical Location my entire army was camped out next to, uncapture it, then engage. That's... a weird move in a match without the victory condition for Critical Locations.

[Kasrkin84]

 

 

The AI improvements do not appear to be in effect at all during stronghold battles.

 

That's because the AI behaviour in the stronghold levels is controlled almost entirely by the mission's SCAR file rather than the AI scripts.

[FraktalTMG]

Question. Is it by design that the DoS AI's response to its base being attacked by the player while its army is away is to go on the offensive against the player, rather than fall back to defend its base? I've seen a Tau opponent do that repeatedly on that desert map with the plateau in the middle the player starts on top of (can't remember the name): while its entire army was tied up by two invulnerable units at the base of the ramp leading up to the plateau, I maneuvered around to the south and hit their base from there; entire army ran past the invulnerable blockade, charged up onto the plateau, took the Relic there, then started engaging the proxy base I set up near the ramp (for counterattacks when defending the map later on).

 

Next match, this time against Orks: I try setting up a proxy base near them, they sent a Squiggoth after it. I kill it half a second after it kills the freshly-constructed HQ, start building a new one, cue full-hardcap gang of Flash Gitz and Looted Tanks going after it, completely ignoring the invulnerable units rampaging in its base.

 

Again: is it deliberate behavior by the AI to respond to potentially being eliminated from the match via HQ loss by refusing to defend and instead going on the offense in a "who loses first" game of chicken? Because I've seen it happen too often for it to not feel like a pattern, yet it also feels time and time again as if there is no rhyme nor reason to the AI's actions.

[Gambit]

Is it by design that the DoS AI's response to its base being attacked by the player while its army is away is to go on the offensive against the player, rather than fall back to defend its base?

No, the normal behaviour is to defend the base.

There is even support for abandoning an attack, in order to defend an allied player whose base was under attack.

I have seen the functions and they work just fine, trust me.
 

I've seen a Tau opponent do that repeatedly on that desert map with the plateau in the middle the player starts on top of (can't remember the name): while its entire army was tied up by two invulnerable units at the base of the ramp leading up to the plateau, I maneuvered around to the south and hit their base from there; entire army ran past the invulnerable blockade, charged up onto the plateau, took the Relic there, then started engaging the proxy base I set up near the ramp (for counterattacks when defending the map later on).

Hmmm....

As far as I am concerned, it has been a long time since I looked into the attack/defence AI plans. And I admit I no longer have the WHOLE AI behaviour in my head

But the above, DOES NOT sound right. And I do not recall the AI playing that way...

 

Next match, this time against Orks: I try setting up a proxy base near them, they sent a Squiggoth after it. I kill it half a second after it kills the freshly-constructed HQ, start building a new one, cue full-hardcap gang of Flash Gitz and Looted Tanks going after it, completely ignoring the invulnerable units rampaging in its base.

The battle overall behaviour is NOT race-specific.

If it happens for the Tau, it will also happen for every race, including Orks.

See, the attack/defend plans are identical for all races - they are CORE files.

(I have ONLY ONCE had to modify them, for the Tyranids, because they follow a completely different race approach)

But other than that, ALL races behave identically, when it comes to deployment methods, combat resolution or field tactics.

... Which is OK, since the logic is more of less standardised I guess...
 

Again: is it deliberate behavior by the AI to respond to potentially being eliminated from the match via HQ loss by refusing to defend and instead going on the offense in a "who loses first" game of chicken? Because I've seen it happen too often for it to not feel like a pattern, yet it also feels time and time again as if there is no rhyme nor reason to the AI's actions.

No it is not normal, and I have never witnessed it - EVERY TIME the AI abandoned the attack to defend its base in all my games.

 

 

 

But wait.

I didn't ask the MOST important thing: Is your AI question based upon VANILLA games?? On unmodded DoW???

Because I have ONLY worked with the DoWAI !!!

And frankly THIS IS THE ONLY WAY TO GO.

Edited by Gambit, 20 May 2019 - 12:58 PM.

[FraktalTMG]

There seems to be a SCAR issue in the Imperial Guard stronghold that I've seen repeatedly across several playthroughs with the Bugfix mod, on hard difficulty. Just now I've encountered it when attacking as the Orks, with this being the third stronghold battle in this campaign.

 

So then. The issue is that as soon as I reach the bottom of the ramp leading up to the IG HQ, the endgame cutscene immediately triggers as soon as my commander is done saying his/her/its first line of dialogue. Looking through the SCAR file, this is what creates the HQ:

Entity_CreateBuildingMarker(g_Player2,"eg_IG_HQ", "guard_hq","mkr_NPC_HQ", 1)
EGroup_ForceAddOn("eg_IG_HQ", "addon_guard_hq_2")
EGroup_AddGroup("eg_IG_HQ_Destroy", "eg_IG_HQ")

Interestingly, this function is called twice during the mission. First at the start of the mission, then again when the player crosses the river. There is one check to create eg_IG_HQ_Destroy if it doesn't exist but other than that, there's no condition-checking whatsoever to see if all the stuff to be created exists already.

 

This is what triggers the end cutscene:

if EGroup_GetAvgHealth("eg_IG_HQ") < 0.05 then
	
	g_Win = true
	
	Rule_AddOneShot(Rule_Closing_NIS, 4)
	
	Rule_Remove(Rule_HQ_Health_Monitor)
	
end

eg_IG_HQ definitely exists because its existence is what's causing the periodic sniper attacks on my commander. But the condition that checks its health prematurely returns true even if I'm nowhere near the thing, as soon as I approach the ramp (that's when the game starts periodically checking it). And this bug sometimes doesn't always manifest; I've seen this part of the mission play out properly from time to time, but I have no idea why.