75 replies to this topic

[dreddnott]

You made no attempt at discussing code with me. Your point? Seeing an unreproduced flaw in one match invalidates what I've done? That's not a point. Don't you think that there's always room for improvement? I find it amazing that you and Arkhan are incapable of speaking to each other about this mod without maintaining a positive attitude.

I play Eldar as I play few other races (maybe Chaos) and my simple modification of the code attempts to represent that high-level playstyle - Fleet of Foot is the Eldar get-out-of-jail-free card and should be used as such. It's too risky to use it when you're attacking, whether you're human or AI - you're going to stumble over waiting enemy squads more quickly, reducing your ability to react quickly, and hitting Tab F Tab F Tab F Tab F takes time no matter who you are.

I have seen a couple things testing this on larger maps:

1. Gather moves do still use Fleet of Foot. I wasn't seeing this on the smaller maps, but there you go.

2. Squads standing and shooting with FoF on: This can only happen if bMoving returns true. I actually did see this happen on Mountain Trail and Into the Breach when squads got separated into two parts by pathing issues. The stuck members try to get to the rest of the squad and count as moving. That's beyond our control and happened way more often with the other code.

3. Thinking about removing the check for the DoDance tactic. I saw squads dancing and stopping only 20-25 range away and the timing on FoF was just awful because of the tactic update lag. I guess the dancing behaviour is well-behaved most of the time.

4. Sloppy parentheses for the local booleans. Yeah, shame on the noob but I fixed it and it didn't cause errors in any case.

Honestly I'd like to have more input on this, from test results and possible modifications. There are some things I don't believe the AI can do, like reliably stop FoF on an attack move a second or two before it gets into range, but perhaps I'm wrong?

Edited by dreddnott, 15 April 2008 - 08:17 AM.

[Smokeskin]

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.

I'm siding with Larkin (except I'm willing to make the argument )

Moving guardian squads without FoF do about 20% of their normal DPS. Fleet of foot gets you there 33% faster, allowing you to stand still and fire at full DPS.

Ergo, even if FoF completely removes moving DPS, it is entirely worth the trade off, the lost moving DPS is more than made up by the increased time you get at full DPS because you got there faster. Sometimes the AI has a bit of a hard time making the units stand still, that could justify keeping it off, but you're not going to do any sort of real damage while moving anyway.

If your code also makes them run without FoF while attack moving without anything to fire at, then it makes it even worse. At the very least, attack moving with no enemies in range should enable FoF. But I think moving => FoF on is the best way to go (with respect to how quickly the AI can check and toggle it).

Edited by Smokeskin, 15 April 2008 - 08:50 AM.

[Smokeskin]

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.

The fact remains, the AI sometimes is still crippled because it sends away powerful squads to capture, then gets into a fight and gets hammered because it didn't have its combat units there.

If you want to capture something with a combat unit, move the entire army there, and if it gets to a fight, stop capping. If you lack capping units, build another. If the capping unit will run through the enemy base if too far away, move it to a nearer safe point first, then resume capping from there.

[dreddnott]

The AI can't toggle FoF fast enough, or should I say predictively enough?. The unit may get there faster, but what is it doing? It's outrunning the Warp Spiders and Wraithlords that are also on their way to combat. It's also dying, not dealing damage, during those 5 or so seconds it takes for the tactic update. Fleet of Foot nerfs stationary DPS by 20% as well.

They may get to the target slower now but they're guaranteed to do their full damage, and they won't constantly cycle FoF on when they move a short distance to get in range of another enemy squad. Heck, under the old code, FoF wouldn't toggle on when you were being shot at, even if you were broken and/or retreating, because that counted as being in combat.

The accuracy while moving with Fleet of Foot on is much less. The 15% FotM is a flat value, not a modifier to base accuracy, so with FoF on the weapon would probably hit about 3% of the time, whatever the weapon's base accuracy. For our purposes of course we can assume 0 damage.

I'd rather you tested the code than tried to theoryhammer it. The advantages are too great to ignore, especially with Dark Reapers.

P.S.: I also was reminded last night (before I fell asleep in my computer chair) that the Farseer can cause odd things to happen with Fleet of Foot, making it look like a bug in FoF code.

[Smokeskin]

I don't think we disagree, I did say with respect to how fast the AI can toggle it. If it can't toggle it fast enough, then go with the next best thing, keep FoF on when attack moving, except when enemies are nearby.

There was a similar problem earlier, where it wouldn't stop retreating because the updates were too slow. I think the option to have certain units add themselves to a data structure that would get certain conditions checked more often would solve many of these issues.

[LarkinVB]

Heck, under the old code, FoF wouldn't toggle on when you were being shot at, even if you were broken and/or retreating, because that counted as being in combat.

Plain and simply wrong. Any proof for this bold statement ?

You made no attempt at discussing code with me.

Of course not. I just stated I'm tired starting one.

I like your idea of better FoF but just disabling for attack move is not my favorite solution. Watching one battle showed serious problems. Why should I watch more ?

P.S.: I also was reminded last night (before I fell asleep in my computer chair) that the Farseer can cause odd things to happen with Fleet of Foot, making it look like a bug in FoF code.

FoF with FS attached is broken.

Edited by LarkinVB, 15 April 2008 - 09:27 PM.

[ThetaOrion]

In today's game I experienced my first and only CTD with SoulStorm while playing the 3.0 AI Skirmish Mod.

The randomizer gave me all Orks on Mountain Trail, 2 Orks vs 2 Orks, HARD setting. It was all nice 'n orky.

I can't remember the last time I had a CTD with DoW -- it seems like it has been years.

I had some gretchin hiding in an LP2 listening post that was on the front lines, and when I selected that listening post to get them out to build somethin', then it crashed with the sound of selecting the listening post echoing there. No message, nothing, just closed down quick and found myself staring at the desktop. I don't know if it was related to any of that listening post bunkering, or if you guys know of any Relic bugs related to Ork bunkering.

But, there might also be some sort of CTD hiding in the Ork code of the 3.0 AI Skirmish Mod?

I was losing, though, so no big deal. The AI plays the Orks better than I do.

--

P.S. I was also excited to see dreddnott trying his hand at writing code, when I first saw it there. I used to play Eldar almost exclusively for long stretches there back in the WA days, and seeing somebody try to improve them always makes me happy. Maybe Arkhan can pick up the idea, maybe even pick up some of the code as a starting place, spruce it and and make it great and include it someday in a future version. If nothing more, it will point Arkhan in the direction of the things that people are thinking about.

Edited by ThetaOrion, 15 April 2008 - 10:43 PM.

[dreddnott]

Well, I thought about it for a while and beat this out over the last couple days. It may seem awfully long but it uses FoF for all situations including AttackMove and stops using it at an appropriate distance from the enemy, no matter what squad is using the ability. Melee squads will charge right up before disabling the ability while long-ranged squads will disable FoF very early to take advantage of their extra reach. Best part is that it's easily tuned and only requires changing one tactic file.

I tried the best I could do to get the best of both worlds, and have the AI take advantage of FoF as much as possible while still trying to avoid problems with the tactic update lag. This is why I've fudged the ranges a bit on the high side. Also, watching the Farseer attached to Howling Banshees in T1 constantly screw things up for the Eldar makes me wonder if she shouldn't be allowed to attach to any infantry (even Seer Council). Since FoF nerfs melee as well as ranged damage, the Eldar AI would probably be able to play better with the Farseer independent from other close-combat units.

I changed it, this version had problems when attacking buildings

Edited by dreddnott, 16 April 2008 - 10:44 PM.

[dreddnott]

if ((bIsUsing == true and ((bIsInCombat == true and bNoEnemy == false) or bMoving == false)) or
		(bIsUsing == false and ((bIsInCombat == true and bNoEnemy == true) or bCapping == true or bRunAway == true))) then
		bToggleFoF = true
	end

This causes squads to toggle FoF when they're standing still and attacking buildings, with no enemy squads in range. I'm thinking about how to fix it right now...

Ok, I got it.

Added this boolean, separate from the bIsInCombat one (just in case, to prevent it from somehow toggling FoF off if we count as IsAttacking when we really should have FoF on):

-- Check if we're shooting
	local bShooting = self.squad_ai:IsAttacking()

and changed the conditional:

if ((bIsUsing == true and ((bIsInCombat == true and bNoEnemy == false) or bMoving == false)) or
		(bIsUsing == false and ((bIsInCombat == true and bNoEnemy == true and bShooting == false) or bCapping == true or bRunAway == true))) then
		bToggleFoF = true
	end

Also tuned melee units up to 15 range and Fire Dragons up to 30 range.
It will still toggle on no matter what if we are making non-attackmoves, running away etc. but will only toggle on for attack moves if there are no enemy squads around and we are not shooting at anything.

function EldarInfantryTactic:DoAbilityFoF()

	-- Check to see what we are
	local sFoFType = self.squad_ai:GetSquadName()

	-- set default FoF range reasonably just in case
	local iFoFRange = 35

	if (sFoFType == "eldar_guardian_squad") then
		iFoFRange = 35
	elseif (sFoFType == "eldar_squad_rangers") then
		iFoFRange = 40
	elseif (sFoFType == "eldar_squad_dark_reapers") then
		iFoFRange = 45
	elseif (sFoFType == "eldar_squad_banshees" or "eldar_squad_seer_council" or "eldar_squad_farseer") then
		iFoFRange = 15
	elseif (sFofType == "eldar_squad_fire_dragon") then
		iFoFRange = 30
	end

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

	-- Check whether we're using the ability
	local bIsUsing = self.squad_ai:IsUsingAbility(iFoFID)

	-- Check if we're attack moving
	local bIsInCombat = self.squad_ai:IsInStateAttackMove()

	-- Check if we're shooting
	local bShooting = self.squad_ai:IsAttacking()

	-- Check if we're in a state that should FoF regardless of enemy presence
	local bRunAWay = (self.squad_ai:IsBroken() or (self.stateID == Tactic.StateID.AvoidDeath) or (self.stateID == Tactic.StateID.DoDance))

	-- Check if we're doing any sort of moving
	local bMoving = self:IsMoving()

	-- Check if we're moving around or capping
	local bCapping = (self.squad_ai:IsCapturing() or self.squad_ai:IsInStateMove())

	-- Check if we should slow down for enemies nearing range
	local vSquadPos = self.squad_ai:GetPosition()
	local oEnemy = cpu_manager.cpu_player:FindFirstEnemy(vSquadPos, iFoFRange, 1)
	local bNoEnemy = (oEnemy == nil)

	-- Check if FoF should be toggled
	if ((bIsUsing == true and ((bIsInCombat == true and bNoEnemy == false) or bMoving == false)) or
		(bIsUsing == false and ((bIsInCombat == true and bNoEnemy == true and bShooting == false) or bCapping == true or bRunAway == true))) then
		bToggleFoF = true
	end

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

Edited by dreddnott, 16 April 2008 - 10:46 PM.

[ArkhanTheBlack]

It looks promising! You've definitely spent a good amount of time in it. When the first patch is out I certainly give it a try.

At the moment I'm very busy writing my diploma thesis. The 3.0 AI development distracted me quite a bit so I've to focus now on my work. I'll therefore just check the forums from time to time but only post rarly until the next patch is out and trying out things will have to wait until then for me.

Just to keep you informed...

[LarkinVB]

Yes, looks promising. Had a 6vs6 on bloodshed orks vs eldar and it looked fine. Needs some good testing in various setups.

[Smokeskin]

It sounds good.

Hey, the problem is the sometimes slow updating, right?

How about subtracting 10 from all the range values, then adding delayRange = NoOfAIPlayers * (2+isAIHighSpeed) to them, or something like that (numbers are untested). Make it dependant on the estimated delays so you get the most out of the CPU cycles available.

[LarkinVB]

Funny. I wrote the same but then removed from my post. I think if we start to optimize AI for tactic cycles/second we should do it on bigger scope then just for FoF. Various parts are handicapped by slow updates.

[Smokeskin]

I don't have any real LUA experience, so I'm just pulling this out of my hat at work, but couldn't you do something like

in cpu_manager

init
{
...
tFastUpdaters = {}
...
}

AddFastUpdater (unitPointer, function)
{
  table.insert(tFastUpdaters, unitPointer, function)
}

RemoveFastUpdater (unitPointer)
{
  table.remove(tFastUpdaters, unitPointer)
}

UpdateFastUpdaters ()
{
 for unit, function in pairs(tFastUpdaters) do 
  if (unitIsAlive(unit)) then   -- I'm hoping this is a death check, but perhaps the pointer goes nil, and what happens to it then, tables can't index nil?
   unit.function
  else
   table.remove(tFastUpdaters, unit)
  end   
 end
}

Then in DoAbilitityFoF() at the end

...
if (bToggleFoF) then
 if (bIsUsing) then
  cpu_manager:RemoveFastUpdater(self)
 else
  cpu_manager:AddFastUpdater(self, self.DoAbilityFoF)
 end
end

Then add calls to UpdateFastUpdaters in each update loop, so it gets checked very often. The functionality could easily be used for other timecritical decisions (and you should only add critical, low overhead stuff into it of course).

Edited by Smokeskin, 17 April 2008 - 09:29 AM.

[ArkhanTheBlack]

Please don't overcomplicate things! Adjusting the code for update times goes a bit too far. Balancing it to ~3 AI players (=> 1,5 sec in harassing time, => 3 sec afterwards) should be enough.

Edit: Update times were wrong. Corrected now!

Edited by ArkhanTheBlack, 17 April 2008 - 01:46 PM.

[Smokeskin]

I think it looks very simple. If I was well versed in Lua it wouldn't take long to do, I'm just not 100% of the syntax and scope issues that pop up. The above code is pretty much the full extent of it. A check to prevent it from eating too many cycles might be necessary (something like if (math.random(1,table.getn(tFastUpdaters))>5 then return end at the start would probably do the trick if needed at all), but otherwise, you would be done.

It would be great for dancing, retreating, FoF toggling, perhaps even other things.

I think I'll try to see if I can get something like that working. If some of you who are well versed in Lua have some comments on my code, please let me know

[ArkhanTheBlack]

You didn't understand the reason why the update times are so slow! In mid and late game, the performance issues gets critical and the game gets sloppy and there's a high chance of sync errors in MP games. The update times are halfed after 5 minutes for this reason. With fast updaters you make this performance control mechanism unreliable. It's just not worth it.

[Smokeskin]

Yeah, everything is updated within an update loop, and this takes time.

I'm not talking about moving everything into FastUpdaters, and not even an entire unit's Update(). It will only be time critical functions, and only when needed. So, a unit that switches on it's FoF adds its FoF function, nothing else, and removes it again when it switches off FoF. A dancing unit, it will check for stopdancing via the fast update, but not the rest of its functions, and only while it dances.

Furthermore, the check I suggested would limit it to 5 extra function calls per step in the global update looping, and it could probably easily go lower than that. If I added 5 simple function calls to the Tactic.Update() function, I don't think that would break anything, and this will have the same overhead.

I don't know if I'm not expressing what I'd like to do properly, but I think it could work. If it does, that'll be fine, if it doesn't work, then I'll have learnt some more about how your AI works

[ThetaOrion]

Okay, I have finally noticed a repeatable glitch on Mountain Trail -- fixed positions and position #2, iirc. The Tau AI ally builds its factory too close to its stronghold; and the games I have observed so far, there are always two or three Tau tanks stuck between the factory and the stronghold for the remainder of the game. And, the Tau only get to use those tanks if the Tau lose; and the Tau AI ally is one of those rare AI allies that tend to stand and hold.

Either the Tau AI need more space between their Tank Factory and their Stronghold, or the rally point for those Tau tanks needs to be outside the build radius rather than between the stronghold and the factory -- if that is possible.

Again, nothing big, but it might help explain why the Tau AI ally often doesn't do as well as a Tau AI enemy, for example -- in the games I have been playing.

[LarkinVB]

Placement around HQ is hardcoded and rally point can not be set by AI. AI is screwed on some maps.