Jump to content


Photo

3.0 bug/problem list


75 replies to this topic

#1 LarkinVB

LarkinVB

    title available

  • Members
  • 1,488 posts

Posted 13 April 2008 - 06:22 AM

We can gather bugs/problems here which can be solved for 3.1

Please don't add best build order discussions etc, just stuff which is/might be broken.

1. function Strategy:IsQuickStart() won't work for necrons as it only tests for requisition > 9999
2. "Capture Plan - MidCapture" should be check if it is still needed/functional
3. Is function AttackScarabTactic:AlwaysAttack() = true still valid as air unit ? Do they need their extra AttackScarabTactic:Upgrade() code ?
4. Is TauHonorGuardTactic:AlwaysAttack() = true the right tactic or just wasting them ? Summon has cooldown of 2 minutes.
5. Air units without own tactic will get infantry tactic instead vehicle tactic. Is this on purpose ?
6. Disabled turrets in AI config will disable banners being built too.
7. DarkEldarInfantryTactic:CheckDance(oSquad) should not check wych but scourge against cultists.
8. Flash gitz squad should get CheckDance() = false against cultists and self.m_iTransportable = 2 instead nothing.
9. Firedragon, warp spiders, seer council, possessed, nobz, ogryn squad should get self.m_iTransportable = 2 instead of 1.
10. self.squad_ai:GetNumTroopers() == self.squad_ai:GetMaxTroopers() requirement for transports perhaps a bit harsh ?

Edited by LarkinVB, 13 April 2008 - 02:48 PM.


#2 thudo

thudo

    Wacko AI Guy!

  • Division Leaders
  • 12,166 posts
  • Location:Lemonville North, Canada
  • Projects:DoW AI Scripting Project
  • Division:DoW
  • Job:Division Leader

Posted 13 April 2008 - 07:36 PM

Also the shortcut to run the AI from START\PROGRAMS is set incorrectly to: "D:\DoWSoulstorm\Soulstorm.exe.exe -modname dowai" -- heh.. need to remove the second .exe.
Advanced Skirmish AI Team Lead for the coolest Warhammer40k PC RTS out there:

Dawn of War Advanced AI Headquarters

Latest DoW Advanced AI Download!

#3 Smokeskin

Smokeskin
  • Members
  • 127 posts
  • Location:Denmark
  • Projects:Soulstorm Advanced AI betatester

Posted 14 April 2008 - 12:16 PM

There's something seriously wrong with the code for how units behave when taking fire from longer range enemies.

Try the Tau's fire warrior BO vs just about anything, SM for example. What happens is that fire warriors set up and fire away, while the opponent mostly runs around confused under fire, back and forth, until they're decimated. I don't know exactly what happens. Perhaps the SM want to attack, run in, take losses that drop them low on army strength, so they should retreat. Or perhaps they're just trying to run to safety in random directions and never making it out, doing a random walk always in range of the fire warriors.

EDIT: Larkin's description below sound about right. Like the overall strategy is to attack, but the individual squads tries to avoid death and retreats, then the overall attack strategy kicks in again and sends them back into the torrent of fire. I can see the point in running a vehicle back to repair it, even though there's an ongoing fight, since they're cheaper to repair than rebuild. But if the AI has its army attacking, then running individual squads back to save them from death will accomplish nothing, except having lots of units suffer from FotM penalty. If you're fighting, and your infantry is taking fire, some of them will die, if you retreat units under fire your opponent just switches target and kills some other infantry.

It sounds like this could be hard to get right, since you can't completely disable units' retreat behavior. But not letting individual infantry retreat unless the attack is called off sounds right. The main problems I'm imagining would be a unit that attacks from another angle than the main army and runs into a bunch of defense while separated, they should retreat in that case. The same with melee troops, running in front of your ranged units and getting into range of lots of unpleasentness (like an ork base).

Edited by Smokeskin, 14 April 2008 - 02:23 PM.


#4 LarkinVB

LarkinVB

    title available

  • Members
  • 1,488 posts

Posted 14 April 2008 - 02:08 PM

It is possible that this is the result of a 'fix' for the AvoidDeath function. Squads in shootouts do retreat if seriously inferior/outgunned. With the 'broken' code they did retreat a great, often very great distance. Arkhan fixed this and perhaps now they stay too close, reengage, retreat, reengage etc pp.

#5 dreddnott

dreddnott
  • Members
  • 60 posts

Posted 14 April 2008 - 06:11 PM

Eldar Fleet of Foot. The stock Eldar AI actually does better in T1 than Skirmish AI's Eldar because of this.

I know it will disable after a few seconds of being stationary, but perhaps some additional restrictions on when the ability may be activated are in order? I see it activated for AttackMove constantly.

Also something strange I never saw before - Chaos on Panrea Lowlands interrupting the construction of the Armoury to build plasma generators and other things. The Armoury actually didn't get finished until over 12 minutes in because the Heretic builders kept getting interrupted by these other tasks after only a few seconds of construction.

#6 ArkhanTheBlack

ArkhanTheBlack

    title available

  • Members
  • 814 posts

Posted 14 April 2008 - 06:52 PM

There's something seriously wrong with the code for how units behave when taking fire from longer range enemies.

This is a very basic and old problem. Units are usually ordered to a certain position. This position has a certain scan or threat range. If any unit attacks out of this threat range the tactic code doesn't know what to do because it doesn't see an enemy. The usual behaviour is that the unit tries to move closer to the center of the gather point. However, if this doesn't solve the problem, they always try the same thing. It's probably a problem of the threat range. If units get a weapon range >= 35 it gets critical.


Eldar Fleet of Foot. The stock Eldar AI actually does better in T1 than Skirmish AI's Eldar because of this.

They don't deactivate it in 'moving' state. I once changed that so they deactivate it immediately as combat starts, but then I got criticised from Larkin that the old 'more moving' behaviour would be much better, and so I changed it back.

Edited by ArkhanTheBlack, 14 April 2008 - 06:53 PM.


#7 LarkinVB

LarkinVB

    title available

  • Members
  • 1,488 posts

Posted 14 April 2008 - 08:52 PM

I think current FoF is fine in 1vs1 as the AI tactic is called more often and it is switched off really fast (just tested it). It can get unresponsive in multi army battles. But perhaps there is a bigger problem now as one player at relicnews stated FoF was active for a minute and affecting the complete army in combat.

Edited by LarkinVB, 14 April 2008 - 09:02 PM.


#8 ArkhanTheBlack

ArkhanTheBlack

    title available

  • Members
  • 814 posts

Posted 14 April 2008 - 09:32 PM

But perhaps there is a bigger problem now as one player at relicnews stated FoF was active for a minute and affecting the complete army in combat.

I guess the the 'moving' flag was constantly on for some reason. It could also be that he played an 8 player map with AI highspeed. 14 sec delay time is huge and can seem like a minute in a hot battle.

#9 dreddnott

dreddnott
  • Members
  • 60 posts

Posted 14 April 2008 - 10:06 PM

What was the old code used to deactivate immediately on combat? I'd like to test this out myself.

#10 LarkinVB

LarkinVB

    title available

  • Members
  • 1,488 posts

Posted 14 April 2008 - 11:24 PM

Perhaps we should change this check

function Tactic:IsMoving()
	local bMoveState = (self.squad_ai:IsInStateMove() or self.squad_ai:IsInStateAttackMove() or self.squad_ai:IsCapturing())
	return (bMoveState and distance_sqr(self.m_vLastPosition, self.m_vCurrentPosition) > 4)
end

to sqr(4) instead 4. Guess it is what I wanted to achieve to detect real moves, not just small hardcoded position shifts, forgetting the sqr. Even better doing the distance check only for attack moves, not standard moves :

function Tactic:IsMoving()
	local bMoveState = (self.squad_ai:IsInStateMove() or self.squad_ai:IsCapturing())
	local bAttackMoveState = (self.squad_ai:IsInStateAttackMove() and distance_sqr(self.m_vLastPosition, self.m_vCurrentPosition) > sqr(4))
	return (bMoveState or bAttackMoveState)
end

Guess it will need some testing.

Edited by LarkinVB, 15 April 2008 - 12:29 AM.


#11 dreddnott

dreddnott
  • Members
  • 60 posts

Posted 14 April 2008 - 11:43 PM

That explains a lot of the trouble I've had in the past hour trying to write code in eldarinfantrytactic.ai to fix the FoF issues! The bIsMoving there returns true on attack moves as well as regular moves and moving to capture.

I'll test your revision to the IsMoving() tactic shortly.

#12 LarkinVB

LarkinVB

    title available

  • Members
  • 1,488 posts

Posted 14 April 2008 - 11:48 PM

There should be a better test how to select capping squads. Just wanted to test FoF, eldar vs orks. Eldar did use fresh 4 men dark reaper or orks 4 men shootas for capturing though both had their initial guardians/sluggas. Seems reinforced basic squads are more worth and not selected for capping.

#13 ThetaOrion

ThetaOrion

    title available

  • Members
  • 676 posts

Posted 14 April 2008 - 11:50 PM

The only 'bug' I noticed so far that got my attention was when my Eldar AI ally finished off the Chaos AI enemy and then just stood there fully capped at Tier Four for 5 to 7 minutes on the Chaos side of the map, while I as the SM had to take on the DE alone on my side of the map. But then, finishing off the DE by myself was kind of a reward and lengthened the game. But, from what I remember here two years ago, it's something that Arkhan would have liked to have been told about.

--

It looks like in this thread and RelicNews, they are starting to get into the 'weird' matchups. The Randomizer seems to set me up with unwinnable combinations to try.

I found that I couldn't win as the Sisters against SM AI ENEMY -- the SM brutalized the Sisters in every encouter. The best I was able to do in order to get the win was to simply turtle up and hold my territory, while my Tau AI ally wiped out the IG, and then we went after the SM AI enemy together. The Sisters can take on Tier 4 SM if they have the Tau backing them up. I lost a lot of games in a row trying to take on the SM in a straight fight as the Sisters. And, the AI really is more efficient at tiering up than I am. The SM ripped me apart -- hiding in cover at a chokepoint and waiting for the SM to come to me was my only option that worked for me. I also had to have the Tau AI ally luckily come over and help me finish off the Assault Marines, in order to stay in the game a couple of times as the Sisters against SM.

It's all trade-offs.

--

In my most recent games, I was finding it impossible to win as the DE against the Sisters. The Sister AI gets to Tier 4 much faster than I do, and the AI is using some Sister power that I personally don't know how to use, and it simply fries us all, my whole army, gone in seconds. It's really cool to watch the Sisters in the hands of this AI! Awesome! DE against Tau AI isn't good either. The DE are really hurting in Tier 1 and Tier 2, even in the hands of the AI. But, if you can get the DE into Tier 3 or to Tier 4 alive, then the DE AI suddenly become very brutal and can take on anything.

The Randomizer made me DE with SM AI ally against Tau and Sisters. Holy hosanna! That was a tough combo. I can just barely hold against Sisters as DE, basically just trying to hold and regain territory, and the Tau AI enemy walks all over the SM AI ally, and soon the SM are eliminated and gone, so it doesn't matter if I hold or not. I haven't figured out how to win that combo yet. It's one I have on the back burner. I assume the Tau must be decimating the SM from range as is being reported here, because the SM are gone in record time; and then it's just me alone.

--

I always win as the Necrons. I can't ever remember losing as the Necrons in SS, although I got lazy and was slow to Tier up one time and suddenly found myself fighting to come back from behind. I just don't personally Tier up as fast as the AI, which is often my greatest problem against the AI. And, the Randomizer keeps giving me DE AI ally and/or making me DE, and I feel very vulnerable and weak in T1 and T2 as the DE. Lots of times I don't make it to T3 as DE; but if I can get the DE AI to T3, then I can stop worrying about whether they are going to survive or not, as long as it's the AI playing the DE. The AI plays the DE better than I do!

The only faction that I sincerely believe that I play better than the AI is as the Necrons. If the Necron AI's first march of death is beaten down, then they are done in the hands of the AI, or so it seems, 3/4ths of the time. There are a couple of factions, though, that are weak against Necrons, and the Necron AI does well there, even if its initial march of death fails.

--

Anyway, I don't know how much of this is really any sort of bug, although apparently Smokeskin and others see some bugs. I personally have tended to see it more as 'unfortunate matchups' or another new 'unwinnable scenario' that I now want to try to beat. I can testify from experience that my SM AI Ally is getting torn apart and decimated by the Tau AI enemy, in every such matchup so far. I haven't seen the IG do well against Tau, either.

Oh, there's more combinations and matchups than I can possibly imagine, here. And, setting everything to Random seems to work like magic giving me unwinnable combinations that I can then try repeating and try squeaking out a win.

--

I just wanted to thank Thud, Arkhan, and Larkin for some great gameplay here! I feel like a kid in a candy store, that's for sure.

Edited by ThetaOrion, 15 April 2008 - 12:08 AM.


#14 LarkinVB

LarkinVB

    title available

  • Members
  • 1,488 posts

Posted 14 April 2008 - 11:52 PM

I'll test your revision to the IsMoving() tactic shortly.


Note that I made a small change (forgot to remove IsInStateAttackMove for bMoveState) and edited after your post.
Please test as it is now.

EDIT: I think new FoF code is fine now in 1vs1.

Edited by LarkinVB, 15 April 2008 - 12:30 AM.


#15 ArkhanTheBlack

ArkhanTheBlack

    title available

  • Members
  • 814 posts

Posted 15 April 2008 - 01:28 AM

There should be a better test how to select capping squads. Just wanted to test FoF, eldar vs orks. Eldar did use fresh 4 men dark reaper or orks 4 men shootas for capturing though both had their initial guardians/sluggas. Seems reinforced basic squads are more worth and not selected for capping.

There's also a distance check involved. This gets very important on maps like battle marshes where the capturing squads start to move through the enemy base if you just take the cheapest squad.

#16 dreddnott

dreddnott
  • Members
  • 60 posts

Posted 15 April 2008 - 05:47 AM

Thanks for that Larkin.

I've worked up some FoF code, it might be messy-looking but it seems to work 100% of the time, no random toggling, slow-downs, or anything else weird. Eldar > Necrons, Space Marines, and other strong races in 2v2 games that I tested. It works *really* well.

It replaces the function of the same name at the end of eldarinfantrytactic.ai (if anyone else wants to use it).

function EldarInfantryTactic:DoAbilityFoF()

	-- Check if we should toggle FoF
	local iFoFID = cpu_manager.stats:GetAbilityID("eldar_fleetoffoot")
	local bToggleFoF = false

	-- Check if unit is using the ability
	local bIsUsing = self.squad_ai:IsUsingAbility(iFoFID)

	-- Check if unit is in battle
	local bIsInCombat = (self.squad_ai:IsInStateAttackMove())

	-- Check if unit is broken
	local bIsBroken = self.squad_ai:IsBroken()

	-- Check if running away
	local bRunAWay = ((self.stateID == Tactic.StateID.DoDance) or (self.stateID == Tactic.StateID.AvoidDeath))

	-- Check if moving
	local bMoving = (self.squad_ai:IsInStateMove() or self.squad_ai:IsCapturing())

	-- Check if FoF should be toggled
	if ((bIsUsing == true and (bIsInCombat == true or bMoving == false)) or

		(bIsUsing == false and (bRunAway == true or bIsBroken == true or bMoving == true))) then

		bToggleFoF = true
	end

	-- Toggle FoF
	if (bToggleFoF and self.squad_ai:CanDoAbility(iFoFID)) then
		self.squad_ai:DoSpecialAbility(iFoFID)
	end
end

Basically as long as the Eldar squad is doing an attack move, not doing a normal move or moving to capture a point, Fleet of Foot will be off.

Conversely, as long as the squad is dancing away, retreating, has its morale broken, or is doing a normal move or moving to capture a point, Fleet of Foot will be on.

I've considered turning it off for dancing but since units sometimes dance for a while or end up retreating, it's almost always beneficial to turn FoF on after dancing starts.

Edited by dreddnott, 15 April 2008 - 05:49 AM.


#17 LarkinVB

LarkinVB

    title available

  • Members
  • 1,488 posts

Posted 15 April 2008 - 06:41 AM

Justed tested your code in a 2vs2 eldar vs SM. It is not working smooth. Since lots of moves are attack moves eldar now use FoF only on retreat most of the time. No more fast attacking-gathering. I even watched them fighting with active FoF without toggling off at all on two occasions. I think it is no good solution. Just watch all AI eldar battles and you will soon notice. I did on first try.

#18 dreddnott

dreddnott
  • Members
  • 60 posts

Posted 15 April 2008 - 07:10 AM

All-Eldar AI battles was the way I hammered this code out in the first place. Haven't seen it fail to toggle off FoF while standing and shooting.

Attack moves are the very reason that old FoF code was causing Eldar units to go into battle with FoF on. You lose a few seconds of firepower from your Guardian squad against enemy T1 and you lose the squad, the encounter, the map. Eldar doesn't need to gather at high speed, just cap and retreat, to build economy and preserve squads.

I'll keep testing, switch up the maps a bit.

Edited by dreddnott, 15 April 2008 - 07:15 AM.


#19 LarkinVB

LarkinVB

    title available

  • Members
  • 1,488 posts

Posted 15 April 2008 - 07:28 AM

Do whatever you like. I made my point. I'm tired discussing code after 3 years AI mod.

#20 ThetaOrion

ThetaOrion

    title available

  • Members
  • 676 posts

Posted 15 April 2008 - 07:30 AM

Oh, one other thing I remembered. Sometimes when I win as the IG and win as DE and win as other things in Skirmish Mode with this AI Skirmish 3.0 Mod, it gives me a picture of the Sisters Commander (in the non-standard Red Armor) as last victorious commander in the Skirmish victory screen and in the subsequent load-up -- even when there wasn't any Sisters on the Map during the last skirmish game that I won.

It derails for a bit.

Now, I suppose that Thud will tell me it's a Relic Bug, as Thud can be that way. But, I played lots of the SS Campaign for a month, and the campaign never failed once to give me the right victorious commander when I won. This Skirmish Mode under the AI Skirmish Mod can kind of get lost concerning the last victorious commander, and then it just simply posts up a picture of the Sister Commander, even if you have won as IG or DE or some other faction during the previous couple of games. And, then sometimes it will get back on track again and display up the right victorious commander from the last time when you won.

Again, it's not a game-breaking bug, and there might not be anything you can do about it or even want to do about it, but I have noticed it every now and then, ever since I started playing the 3.0 AI Mod. If Thud is aware of it, he might could mention it to his buds at Relic, at least.

Edited by ThetaOrion, 15 April 2008 - 07:32 AM.




Reply to this topic



  


1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users