Jump to content


Replying to How to use a mod with the vanilla/WA campaigns?


Post Options

    • Can't make it out? Click here to generate a new image

  or Cancel


Topic Summary

FraktalTMG

Posted 15 March 2020 - 07:27 PM

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.


Gambit

Posted 20 May 2019 - 12:57 PM

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 :p

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.


FraktalTMG

Posted 20 May 2019 - 11:54 AM

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.


Kasrkin84

Posted 19 March 2019 - 12:48 PM

 

 

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

Posted 18 March 2019 - 10:29 PM

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

Posted 28 February 2019 - 04:53 PM

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).


fuggles

Posted 28 February 2019 - 03:08 PM

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

FraktalTMG

Posted 28 February 2019 - 11:39 AM

-- 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.


Kasrkin84

Posted 26 February 2019 - 05:10 PM

What does the log say?


FraktalTMG

Posted 25 February 2019 - 01:51 PM

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.


Review the complete topic (launches new window)