80 replies to this topic

[LarkinVB]

My question was more like this: Where is DoPossess() called for the chaos lord in the current code of the skirmish AI mod ? As far as I can see it is NOT called at all for him. Therefore I wonder how he manages to transform at all.

[LarkinVB]

Good news: I had no crash with mapdb and the new compass move - yet.

[thudo]

My question was more like this: Where is DoPossess() called for the chaos lord in the current code of the skirmish AI mod ? As far as I can see it is NOT called at all for him. Therefore I wonder how he manages to transform at all.

That... is a VERY good question. Same goes for the BT. However, if you wait, the AI does possess the Lord to become the DP and random chaos marine sargs to become the BT so the DoPossess() code must be somewhere running generically. If not, likely a built-in Relic AI call somewhere outside the scripts.

Going forward, I would probably put the DoPossess() code into both the Chaos Lord and Marine Squads that require it as its 10000x more efficient in conjuring either the DP or BT.

Good news: I had no crash with mapdb and the new compass move - yet.

BooyyahhH! Awesome news!!! Fingers crossy'ed!

[LarkinVB]

Arkhan can you have a look ? Honestly I can't remember the chaos lord transforming to daemon prince. Bloodthirster is a different case as DoPossess() is called from InfantryTactic:DoAbilities() which multiple chaos squads are using. The lord is not. I never saw the daemon prince with dowpro too until I added DoPossess() for the lord.

[thudo]

The Chaos Lord does become the DP in vanilla SS 1.20. Its in the AE code. Lord uses the same code as how the BT is summoned.

[LarkinVB]

OK. Doesn't make sense for me but whatever. Perhaps I'm dense.

[ArkhanTheBlack]

More problems. Ability.DoAbilityArea and possibly other abilities are not handled right sometimes. Check the code below. The coder is using the last number as if it is the threshold of units to trigger but in fact it is the range. It makes no sense to reduce range in case the unit is dying.

Good observation. At that place there was obviously a misunderstanding. Fortunately in most other places, it's used correctly.

1. First the Filters using iCount within won't work as expected and should be removed or reworked.
That is CloseInfiltrator, CloseBroken, CloseInfantryEnemyCC, CloseVehicleHighEnemy, CloseMonsterHighEnemy, CloseMonsterEnemy

I reworked them a bit so they won't crash. This way mods that use those methods won't get any execution errors.

2. Why is CloseSquadEnemy = function( position, tolerance, count ) using an additional check for 4 troopers, rendering the count parameter useless ?

They have different meanings. The count returns a certain number of troopers, regardless if they belong to the same squad or not. Some abilities are directed on squads and should have a certain troop count to be worth to be used. A successfull count of 1000 gives you no guaranty that the 1000 guys are individuals or part of one or several squads. That's the reason for the additional squad trooper count check.

DoPossess() is called in InfantryTactic but chaos lord is not using this. Is this intentional ? I guess he won't morph into daemonprince because of this, right ?

Hmm, it 'shouldn't' work, but I'm sure I saw a DP the last time when I tested them. I'm also pretty sure that the testers would have noticed that very fast. Anyway, I've added the Possess code to the Chaos Lord so it makes sense. Maybe the DP morph also works with squad champs?!? Not sure, it's quite some time.
Not sure if the AE code can cause an 'auto-possess'. That's more a question for the AE coders.

Good news: I had no crash with mapdb and the new compass move - yet.

At last... some good news.

[LarkinVB]

1. First the Filters using iCount within won't work as expected and should be removed or reworked.
That is CloseInfiltrator, CloseBroken, CloseInfantryEnemyCC, CloseVehicleHighEnemy, CloseMonsterHighEnemy, CloseMonsterEnemy

I reworked them a bit so they won't crash. This way mods that use those methods won't get any execution errors.

Wouldn't it be better to remove them as they simply don't work ? Or do they work at all ?

CloseBroken = function( position, tolerance, count )
 
		 functor = function(oSquad, iCount)
			 return (oSquad:IsBroken() and iCount ~= nil and oSquad:GetNumTroopers() >= iCount)
		 end
		 return cpu_manager:GetClosestSquad(position, tolerance, functor)
	 end,

Since GetClosetSquad() is using functor with just oSuad but not iCount it won't work, right ?

Can we make them work by adding count functionality to cpu_manager:GetClosestSquad(position, tolerance, functor, count) ?

function CpuManager:GetClosestSquad( pos, range, functor, count )
	
	local squad_ai = nil
	local current_pos = nil
	local range_sqr = sqr(range)
		
	for squad in military_manager:GetSquads() do
	
	   --fulfills requirements
	   if squad:IsValid() and functor( squad, count ) then
		  
		  local squad_pos = squad:GetPosition()
		  
		  --is in range
		  if distance_sqr( squad_pos, pos ) <= range_sqr then
				
			 --check if it's closer
			 if squad_ai == nil or distance_sqr( current_pos, pos ) > distance_sqr( squad_pos, pos ) then
				squad_ai = squad
				current_pos = squad_pos
			 end				
		  end		  
	   end
	end
	return squad_ai
end

Then we can use them like this and they should work :

CloseBroken = function( position, tolerance, count )

		functor = function(oSquad, iCount)
			return (oSquad:IsBroken() and iCount ~= nil and oSquad:GetNumTroopers() >= iCount)
		end
		return cpu_manager:GetClosestSquad(position, tolerance, functor, count)
	end,

Since it is core code I'd like to get a fix and functionality won't hurt these filters.

Edited by LarkinVB, 02 May 2009 - 08:37 AM.

[LarkinVB]

2. Why is CloseSquadEnemy = function( position, tolerance, count ) using an additional check for 4 troopers, rendering the count parameter useless ?

They have different meanings. The count returns a certain number of troopers, regardless if they belong to the same squad or not. Some abilities are directed on squads and should have a certain troop count to be worth to be used. A successfull count of 1000 gives you no guaranty that the 1000 guys are individuals or part of one or several squads. That's the reason for the additional squad trooper count check.

Ok. In this case it does not make much sense to call it with less than 4 as count. Check the archons use of his abilities. He is also calling CloseSquadEnemy and CloseInfantryEnemy on the same ability.

Edited by LarkinVB, 02 May 2009 - 08:36 AM.

[thudo]

Massive Battles SCAR game mode -- a user noted that when it comes to Orks it ONLY applies to vehicles but not the infantry (should be 150 but instead its the vanilla default of 100). Can be fixed?

[ArkhanTheBlack]

Wouldn't it be better to remove them as they simply don't work ? Or do they work at all ?

Most should work. However there's indeed something fishy with the ones that call the cpu_manager:GetClosestSquad() method.

Can we make them work by adding count functionality to cpu_manager:GetClosestSquad(position, tolerance, functor, count) ?

Yes, I think that's the better way. However I'd improve the speed a bit by using this code:

function CpuManager:GetClosestSquad(vPosition, iRange, oFunctor, iCount)
	
	-- Init variables
	local oCurrentSquad = nil
	local vCurrentPos = Vector3f()
	local iCurrentDistanceSqr = 0
	local iRangeSqr = sqr(iRange)
	if (iCount == nil) then
		iCount = 1
	end
	
	-- Compute all squads
	for oSquad in military_manager:GetSquads() do
	
	   -- Check requirements
	   if (oSquad:IsValid() and oFunctor(oSquad, iCount)) then
		  
		  -- Check if squad is in range
		  local vSquadPos = oSquad:GetPosition()
		  local iDistanceSqr = distance_sqr(vSquadPos, vPosition)
		  if (iDistanceSqr <= iRangeSqr) then
				
			 -- Check if it's closer than the last one
			 if (oCurrentSquad == nil or iDistanceSqr < iCurrentDistanceSqr) then
				oCurrentSquad = oSquad
				vCurrentPos = vSquadPos
				iCurrentDistanceSqr = iDistanceSqr
			 end				
		  end		  
	   end
	end
	return oCurrentSquad
end

Ok. In this case it does not make much sense to call it with less than 4 as count. Check the archons use of his abilities. He is also calling CloseSquadEnemy and CloseInfantryEnemy on the same ability.

I'm not sure if squads that 'touch' the range are counted as full, but usually 1 doesn't make much sense. However it's not really important, it doesn't have any negative consequences.

Ok. In this case it does not make much sense to call it with less than 4 as count. Check the archons use of his abilities. He is also calling CloseSquadEnemy and CloseInfantryEnemy on the same ability.

Yes, fixed the Archon problems!

Massive Battles SCAR game mode -- a user noted that when it comes to Orks it ONLY applies to vehicles but not the infantry (should be 150 but instead its the vanilla default of 100). Can be fixed?

Know issue! Dark40K tried a complex workaround sometime, but even he didn't find a satisfying solution.

[LarkinVB]

Any plans on releasing 3.2 ?

[thudo]

That and DC 2.70 as well based on these code updates as well. Yeah I'd like to see some of those changes implemented.

[ArkhanTheBlack]

Any plans on releasing 3.2 ?

I try to finish an installer this weekend. You were quite active with new changes and so I preferred to wait a bit until you're finished with corrections.

[Zenoth]

@ Arkhan / Thudo / Larkin

I would like to know if the A.I in Sousltorm is still sensible to elevated terrain and can crash in certain situations? I remember it was the case in Dark Crusade, but is it still so in Soulstorm?

[LarkinVB]

No idea but I had no crash with current mapdb code.

[thudo]

Same here.. no crash. Specific map this is reproducible?

[Zenoth]

Same here.. no crash. Specific map this is reproducible?

I haven't been able to reproduce it, but it has been my second crash ever since 3.10 has been released. The problem I believe comes from the fact that both maps on which I've had a crash are custom maps, so don't worry I don't even want support for custom maps, I know what is represents, under those conditions it's irrelevant. But my crashes are extremely rare (as I mentioned, two times only), and it happened after a good two hours of skirmish (big maps, seven A.I players).

I was just wondering if code-wise the A.I was still sensible about elevated terrain, custom maps involved or not, because both of the maps I play in question do have elevated terrain and perhaps a difficult layout especially for teleporting and/or jet-packing units. In terms of the hardware side of things none of it is over-clocked, absolutely nothing, and all drivers are official, etc. But anyway, I don't want to create any panic about that.

Edited by Zenoth, 16 May 2009 - 08:45 AM.

[LarkinVB]

I'm sure Relics terrain analyzer code is still buggy enough to give a rare crash here or there.

[LarkinVB]

CheckSquadCap and CheckSupportCap can cause problems. The function will SaveResources before checking wether threshhold is reached at all. The checks should be switched, first threshhold, than resources. It caused some headache with DoWPro.

-- Arkhan 10.2005: Calculates, if more squad cap is needed
 function BuildBaseStrategy:CheckSquadCap(iMinRequisition, iMinPower)
 
	 -- Check requisition
	 local iRequisition = resource_manager:GetResourceAmount():Get( ResourceAmount.RT_Requisition ) / self.m_iTechBreak
	 local iPower = resource_manager:GetResourceAmount():Get( ResourceAmount.RT_Power ) / self.m_iTechBreak
	 if (iRequisition < iMinRequisition or iPower < iMinPower) then
		 self:SaveRessources(true)
		 return false
	 end
	 
	 -- Check squad cap
	 local iSquadCapTotalMax		= build_manager:GetSquadCapTotalMax()
	 local iSquadCapLeft			= self:GetSquadCapLeft()
	 local iSquadCapCurrentMax	= self:GetSquadCap() + iSquadCapLeft
	 if (iSquadCapLeft <= self.info.squad_cap_threshold and iSquadCapCurrentMax < iSquadCapTotalMax) then
		 return true
	 end
	 
	 return false
 end

Bump. Please fix.