Gamers Bill Of Rights
Home | News | Case Studies | Forum
Search
Forum Home | Login

The Updated Enhanced AI Mod Thread

demigod faq support
19 PagesFirst 13 14 15 16 17  Last
pacov
Plaguewraith
Join Date 04/2011
+9
Reply #351 July 13, 2011 8:42:12 AM
from Demigod ForumsDemigod Forums

Concerning eAI 0.27.02 BETA, Uberfix 1.05, high towers

AI battle, hard difficulty 3 TBs vs 3 DA

- saw fire_tb use CoF at towers (nice) but the other two ice_tbs just stand aside out of tower range, doing nothing. One of them started to attack the tower later when an enemy DG shown up

- at WR3 a TB just walked middle lane into the enemy base, attacked nothing and just teleported out in time

- fleeing routine failed on both sides at least once

- DA stood at the right lane tower, idle, while attacked by a TB. Might "thinking" it is save near tower? So, maybe there is a way to tell the AI to hide behind the tower? Would be save of ranged attacks by DG and could get creep exp.

- TB moving near tower and used fireball then. Just a very small issue but wanted to mention it.

- still useless lock using in the lanes (I will mention it anytime I see it )

- nice (for AI skill level. humans would do better of course) swap action when 3 DA encountered a TB in the middle. Could be luck (I`ll make more tests) but the formula "we're more than the other" seems to work

- swap actions while one DA was running away. AI should consider allies HP if possible (for example HP<50% doesn't count for allies nearby to trigger swap usage)

 

more general things

- I've often seen (but always forgotten to mention) fire TB try to AA minotaur creeps near him, but his fire bolt misses them. Don't know if that can be fixed. If not, using skill can be an option or moving back (because TB trying to kill creeps without any success is even worser than being stuck because it looses HP as well ^^)

- I wonder if the AI consider the enemy HP for attacking? Could be nice if they attack always the actual lower HP enemy if two targets are available

- when catapults are out DGs should use skills to kill them if they decided to attack them. It's not overall bad though. DA does it well I think, and Reg also uses his mines frequently and Sed of course don't have much of a choice (hopefully NR equipped) and it's also not so bad for Rook because of his enhanced AA against small creeps when he gains a certain damage amount but I think it would be an improvement if DGs target catapults with some priority and skills. Sure it would be nice if all the AOE skills would be used to the maximum effect (like humans try) but that could be difficult of course. But to take out the catapults (taht use to mass after a certain amount of time) would be nice

 

That for now.

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
pacov
Join Date 02/2008
+183
Reply #352 July 13, 2011 9:26:35 AM
from JoeUser ForumsJoeUser Forums

Quoting Plaguewraith,
reply 352
- I wonder if the AI consider the enemy HP for attacking? Could be nice if they attack always the actual lower HP enemy if two targets are available

As long as the AI is not "stuck" it will attack the enemies with the lowest HP within range.

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
pacov
Join Date 02/2008
+183
Reply #353 July 13, 2011 8:38:06 PM
from Demigod ForumsDemigod Forums

version 0.27.03 BETA
- removed erb's desire to cast stun as an interrupt as its not possible
- increased erb's desire to bite
- increased oak's desire to use surge to kill units
- removed sedna's desire to use silence as an interrupt as its not possible
- added comments to heroGOAP to try to track where the AI is getting stuck (NOTE - this could slow down some lower end pcs)
- added new logic to count the number of grunts near a hero for decision making purposes - previous check was based on threatlevel
- changed the balancing capture flag logic so that the AI will re-prioritize capturing flags if there is a difference of 50 in warscore
- changed AI's desire to buy capture locks from WR 4 to WR 6 - AI will not purchase them prior to WR 6

 

 

edit - going live with this version

 

MIRI - I could really use your help on one thing in particular... been trying to sort it for about 2-3 hours now.  I can issue a destroy structure command at any time in hero goap (even as the #1 priority - eg how I made that silly "bulldog" build).  BUT, because of some check I can't seem to find, the ai REFUSES to immediately attack a tower.  It will only attack if something "unique" happens that causes the AI to move to the tower.  So, somewhere, there is something telling the AI to stay just out of firing range of the towers.  And when I tell it to destroy structure, it has no idea what to do because it understands the command I'm sending it, but it has some restriction in place that won't allow it to move to the structure to attack.  The destroy structure command only seems to work if the AI is already next to a structure (for instance, if I tell the AI to capture flags, it might run past a tower to do so... then it will run back to the tower and attack it to try to destroy it).  But if I say destroy structure, it won't do crap.  Anyway, if you could spend a few minutes on this, I'd really appreciate it as I'm quite baffled.  Thanks

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
pacov
Join Date 02/2008
+183
Reply #354 July 13, 2011 8:51:34 PM
from Demigod ForumsDemigod Forums

0.27.03 live now

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
miriyaka
Join Date 11/2008
+76
Reply #355 July 14, 2011 12:40:33 AM
from Demigod ForumsDemigod Forums

This is complicated - I spent about 45 minutes looking into it, and found out a few things.

Whenever a new mastergoal is chosen, SelectIterativeDeepenedActionPlan runs and decides which actions to execute in which order based on status function results, calculateweights results, etc.  Normally, the DestroyStructures mastergoal would only be selected if the AI were within a certain range of a structure, as per that mastergoal's GoalStatusFunction.

However, since you're forcing this goal on, it's entirely up to the status, calculateweights, and action functions of each action with DestroyStructures = true in its GoalSets to find a structure with which to interact.

 

Other than individual demigod ability actions with the DestroyStructures goal (spit, snipe, struct transfer, etc), the only structure attack action is 'Attack Closest Building' in AttackActions.lua.  Other actions with this goal are defensive, repositioning, flag capture, etc - goals that have nothing to do with actually moving to or attacking a structure.  This is by design.  Do not change this.  If you remove DestroyStructures from these actions in an attempt to force it to attack, not only will that not work, but it will break many other things like ability mode switching, summoning, fleeing, etc.

This action's actionfunction (like most) uses unit.AttackCutoffRange modified by a near-1 multiplier (1.2 in this case) to find targets.  Its CalculateWeights function also uses range 20 to find structures to attack, otherwise it returns false.  unit.AttackCutoffRange is set to the higher of the unit's weapon radius (at the time of GOAP creation) or 15 - in other words, 15 for all demigods other than Regulus, multiplied in this case by 1.2, for 18.

Most ability actions with the DestroyStructures goal use the ability's RangeMax * 1.5 both to confirm status (CalculateWeights) and to find targets (ActionFunction).

This means that if there are no towers within 20, the attack structures action will not be used at all.  If there are towers within 20 but not within 18, the actionfunction will fail.  If there are no targets within the demigod-specific ability ranges * 1.5 (if the demigod in question has any), or the AI doesn't have enough mana to use abilities on those structures, this will likely result in the AI spinning its wheels while your logic forces it into this goal even though all of its goal actions are non-viable.

 

So this is basically another example of why forced goal logic is uh, not so great, and should definitely not be used for the DestroyStructures mastergoal at all.  It's highly likely that a lack of in-range targets for other mastergoals that are prematurely forced (rather than nudged into when appropriate by sensors) is what's causing many if not all of the stuck AI issues.

The forced goal logic is also certainly what's causing the non-retaliation by the AI near towers, flags, etc, as it's not allowing the AI's sensors to properly push it into either attack or flee goals.  The more I learn about the AI, the more clear it is that these forced goals are like using a sledgehammer for watch repair.

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
pacov
Join Date 02/2008
+183
Reply #356 July 14, 2011 8:48:29 AM
from JoeUser ForumsJoeUser Forums

Thanks for taking the time to dig into this and for all the notes.  That helps.  0.27.03 disabled the attack structure forced code again and I'll leave it out (as its pretty clear its not working as desired).  I might try to reduce the majority of the forced goals and see where that gets me next. 

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
pacov
Join Date 02/2008
+183
Reply #357 July 14, 2011 9:26:43 PM
from Demigod ForumsDemigod Forums

ok - did some testing.  I dropped all the FORCED goals except the shop for 20 sec at begin and look to capture flag from 20 sec to 60 sec.  And the other shopping goals.  I kept in the logging that would show me the current master goals.  Then I increased the actual weight of destroy structure... to very high levels.  Same thing happened as if I was issuing an attack command.  The ai refuses to go after towers when then command is issued.  It seems like the ONLY way an ai would attack a structure is if he just happened to be right next to one... I dropped the value some and the ai would just run past the tower to try to get another flag. 

Anyway, here's what I've learned... with hard coded goals of destroystructure, the ai freezes for a bit... but then sometimes, it will actually attack.  But only after its been standing around like a putz for a bit.  Seems like if NOTHING is around and it has to resummon minions or something, that will job it loose and then it ACTUALLY WILL attack a structure... but only then.

Going by weights produced about the same results as the normal ai.  I think it needs to have a move to enemy structure action written... if that would work, then perhaps its possible.

 

 

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
miriyaka
Join Date 11/2008
+76
Reply #358 July 15, 2011 1:20:00 AM
from Demigod ForumsDemigod Forums

Quoting OMG_pacov,
reply 358
Then I increased the actual weight of destroy structure... to very high levels.

How?  If you're forcing goalweights up without using a sensor that shares ranges with the actions, then that's no different than just using conditional logic to force the mastergoal on.

You glossed over the bulk of my last post, which is that these attack/structure goals are not meant to be forced in any way, because they have limited ranges (for good reason).  The AI should only go into an attack goal if it already has a target nearby, and it should use capture, retreat, and flee goals for most movement (I haven't looked in detail at how the AI actually does most of its movement, as that would take a ton of time, but that's my best guess).

 

You could try creating a new action on the attack/destroy GoalSets that searches in a wider radius for both hero and structure targets, and issues a move to an area nearby, but finding a safe spot to move to is more than slightly dicey, even when you know what you're doing.  On top of that, the way the AI decides on its action queue would mean that only that one action would be queued up (because all other actions' calculateweights/statusfunctions would fail, not having targets in range), and it would need to re-evaluate its goal choice once it reached that destination.  I'm sure that some actions already work that way, but I don't know enough to say whether or not this would be responsive enough if e.g. its target moved toward it and met it halfway.

A temporary solution might be to slightly increase the range multipliers on the basic attack and attack structure actions to somewhere around 30 (use unit.AttackCutoffRange * 2 for both CalculateWeights and the ActionFunction for consistency), but that might have some undesirable results, and will require quite a bit of testing.  You'll also probably want to make sure any nearby hero / weak hero sensors have a similar range.

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
pacov
Join Date 02/2008
+183
Reply #359 July 15, 2011 8:29:55 AM
from JoeUser ForumsJoeUser Forums

Quoting miriyaka,
reply 359
A temporary solution might be to slightly increase the range multipliers on the basic attack and attack structure actions to somewhere around 30 (use unit.AttackCutoffRange * 2 for both CalculateWeights and the ActionFunction for consistency), but that might have some undesirable results, and will require quite a bit of testing. You'll also probably want to make sure any nearby hero / weak hero sensors have a similar range.

ok - I'll toy around with that. 

You glossed over the bulk of my last post,

Apparently so... :/

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
pacov
Join Date 02/2008
+183
Reply #360 July 15, 2011 9:28:20 PM
from Demigod ForumsDemigod Forums

well... toyed around a bit... still no dice...

if you get a chance, would you mind providing a quick example of the "temporary solution" you mentioned?

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
miriyaka
Join Date 11/2008
+76
Reply #361 July 15, 2011 11:29:43 PM
from Demigod ForumsDemigod Forums

What did you change?  And how did you test it?

Two or three of the functions for each attack goal (CalculateWeights, StatusFunction, and ActionFunction) should be getting lists of enemy units in a certain radius.  Some of them use a set radius (like the CalculateWeights for the Attack Closest Building action), while some use unit.AttackCutoffRange * some multiplier.  Start with one action, e.g. Attack Closest Building, and find all of these unit- or threat-grab instances, and use a unified, increased range like I mentioned: unit.AttackCutoffRange * 2

This should result in the base target search radius for that action being nearly doubled, for its weight calculation (essentially action priority), status, and its actual attack order.   This should mean it should be more likely to be enabled and at least somewhat prioritized while the AI in question is in any of that action's goals (as defined in its GoalSets), since it no longer has a tiny, myopic target search radius.
Make sure you look through some of the sensor files as well, and check the ranges of any sensors related to nearby enemy heroes, targeting, pushing into attack goals, etc.  Make sure those sensors use a similar or identical method for their target-check range, so their ranges are consistent with the actions they end up prioritizing.

Make note of which sensor and action names you modify, and let me know, so I have some idea of what you're doing and why it might fail / not be enough.  If you're not sure you're doing it right, post an example of a target check that you've modified (and its original version).

 

The difference may not be profound, in fact there may be little if any noticeable difference at all, unless lack of action targeting range was causing or contributing to the stuck AI issues.  If you're increasing ranges and then forcing these goals in any way other than a same-range sensor, you won't see any better performance, because actions with slightly boosted ranges still won't cause the AI to move across the map to attack something.

Depending on the GoalWeights and/or the CalculateWeights return values of the action in question, it may also be put on the back burner in favor of another action whose CalculateWeights function returns higher values for the GoalWeights most appropriate to the AI's current mastergoal (determined by that MasterGoal's MasterGoalWeights in MasterGoals.lua).  So, make note of any other actions on e.g. Attack, DestroyStructure, and Capture GoalSets whose GoalWeights you or Peppe have significantly boosted.

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
pacov
Join Date 02/2008
+183
Reply #362 July 18, 2011 6:05:47 PM
from Demigod ForumsDemigod Forums

haven't looked at this in a few days.  I'm going to see if I can focus on things other than the stuck dg issue (as I got no where with that and just lost quite a bit of time).  I'll revisit that later.  Might be a release tonight with some changes.  Mostly I'm thinking about changing the ai's rules of engagement based on numbers of dgs present.  Mostly that's to keep a full HP ai from attacking 3 other full hp dgs.  But it should also help the fleeing from ganks as it will be based on dg's and not hp.  We'll see how far I get with this tonight... not planning on spending alot of time.

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
pacov
Join Date 02/2008
+183
Reply #363 July 18, 2011 8:39:19 PM
from Demigod ForumsDemigod Forums

well... here's all I've done for the night.  Not going to bother with a release until there's a bit more.


version 0.27.04 BETA
- continued to enhance the documentation in heroGOAP
- added new logic to provide a count of heroes/enemies in heroGOAP for decision making
- added rule so that the AI's goal will not be set to assassinate if 3 or more enemies are present vs 1 ai

 

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
Plaguewraith
Join Date 04/2011
+9
Reply #364 July 19, 2011 6:43:03 AM
from Demigod ForumsDemigod Forums

Quoting OMG_pacov,
reply 364

- added rule so that the AI's goal will not be set to assassinate if 3 or more enemies are present vs 1 ai
 

As far as I can tell, fighting two enemy DGs is a sure death. If one of them is at low life and I think I can kill him before getting killed myself it may be an option though, but can the AI consider this?

Think about having a 3 vs 3 and one player drops out. If the AI then considers engaging two enemy DGs at once is a fine idea, I think it will be easily killed, wouldn't it?

 

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
TheChosenOne@tutamail.com
Join Date 02/2009
0
Reply #365 July 19, 2011 11:49:21 AM
from Demigod ForumsDemigod Forums

Are there already improvements during the latest updates to the 'defendingcapability' of the a.i?

I read from another post that on a certain map the a.i. didn't defend, which I experienced on another map (The Brothers?).
A.I. doesn't defend at all, 4/5 enemy's vs 1 human = losing battle.

 Thanks for the mod/continued work. 

edit; I asume this works together with Crazy Town (1.4)? CT changes some skills and stuff. Mostly favor items and skill-lenghts/powers.

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
pacov
Join Date 02/2008
+183
Reply #366 July 19, 2011 2:58:04 PM
from JoeUser ForumsJoeUser Forums

Quoting Plaguewraith,
reply 365
Think about having a 3 vs 3 and one player drops out. If the AI then considers engaging two enemy DGs at once is a fine idea, I think it will be easily killed, wouldn't it?

I'm going to toy with the balance a bit, so i'm not sure what I'll set it to atm. I've got to see what, if any, problems are created from the new code.  I'm not sure if I'll have much time to work on this, so I might just release an updated version and let you test and tell me how it works.

Are there already improvements during the latest updates to the 'defendingcapability' of the a.i?

With regards to your specific questions, there isn't something in place that causes the AI's to try to balance out their numbers.  Eg, like on brothers, there is no mechanism that will evenly split the ai's if its a 4v1 scenario.  The code I'm working on would simply keep that 1 ai from trying to fight 4v1.  Anyway, coming up with a system that would allocate the number of dgs is probably possible, but not a high priority for now.

edit; I asume this works together with Crazy Town (1.4)? CT changes some skills and stuff. Mostly favor items and skill-lenghts/powers.

They work together just fine, but neither mod is required for the other to work. 

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
Plaguewraith
Join Date 04/2011
+9
Reply #367 July 19, 2011 3:33:38 PM
from Demigod ForumsDemigod Forums

Quoting OMG_pacov,
reply 367
I'm going to toy with the balance a bit, so i'm not sure what I'll set it to atm. I've got to see what, if any, problems are created from the new code. I'm not sure if I'll have much time to work on this, so I might just release an updated version and let you test and tell me how it works.

I would be fine with that.

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
TheChosenOne@tutamail.com
Join Date 02/2009
0
Reply #368 July 19, 2011 4:43:27 PM
from Demigod ForumsDemigod Forums

I have no idea what things you can use to trigger stuff but can't you make A.i. come back to base if there is X number (very very high) creatures/hero's near the base, or Y number of Hitpoints left (1 cpu retreats at X hp's, another at xx% lower and so on till its saved again/clear.

A button that simply recalls them straight to the base is prob not an option for this game?

[/ramblemodewithoutknowinganythingaboutit]

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
pacov
Join Date 02/2008
+183
Reply #369 July 19, 2011 8:22:29 PM
from Demigod ForumsDemigod Forums

recall to base isn't going to happen.  I can force the ai to shop at set intervals, but there no RUN AWAY DUMMY button or logic I can think of.

 

Miri - if you don't mind, please take a look at the syntax here.... I've messed something up and am having a bit of trouble sorting it. 

the debugger is saying the error is happening near the end where I have the }

can pastebin if you find that less obnoxious to read.

Code: c++
  1. local AIUtils = import('/lua/sim/ai/aiutilities.lua')
  2. HeroAIActionTemplates['ShadowSwap - Hero'] = {
  3.     Name = 'ShadowSwap - Hero',
  4.     UnitId = 'hdemon',
  5.     AnnounceAction = false,
  6.     Abilities = ShadowSwapAbilities,
  7.     DisableActions = ShadowSwapDisables,
  8.     GoalSets = {
  9.         Assassinate = true,
  10.         Attack = true,
  11.         Defend = true,
  12.     },
  13.     GoalWeights = {
  14.         KillHero = -7.5,
  15.     },
  16.     ForceGoalWeights = true,
  17.     UninterruptibleAction = true,
  18.     ActionFunction = AIAbility.TargetedAttackHeroFunction,
  19.     ActionTimeout = 4,
  20.     CalculateWeights = AIAbility.TargetedAttackWeightsHero,
  21.     InstantStatusFunction =  function(unit, action)
  22.         local result = false
  23.    
  24.         if(AIAbility.DefaultStatusFunction(unit, action)) then
  25.             local allies = unit:GetAIBrain():GetUnitsAroundPoint(categories.HERO, unit.Position, 15, 'Ally')
  26.             local enemies = unit:GetAIBrain():GetUnitsAroundPoint(categories.HERO, unit.Position, 15, 'Enemy')
  27.             local allyCT = 0
  28.             local enemyCT = 0
  29.             local differenceCT = 0
  31.             if not table.empty(enemies) then
  32.                 enemyCT = table.getn(enemies)   
  33.                     if not table.empty(allies) then
  34.                     allyCT = table.getn(allies)   
  35.                     differenceCT = allyCT - enemyCT
  36.                         if differenceCT >= 1 then
  37.                             result = true
  38.                         end
  39.                     end
  40.             end
  41.         return result
  42.     end,       
  43. }   
Reason for Karma (Optional)
Successfully updated karma reason!
pacov
miriyaka
Join Date 11/2008
+76
Reply #370 July 20, 2011 7:58:09 AM
from Demigod ForumsDemigod Forums

You're missing an 'end' just above 'return result'.  The topmost if statement isn't being closed.

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
LORD-ORION
Join Date 04/2009
+55
Reply #371 July 20, 2011 10:36:06 AM
from Demigod ForumsDemigod Forums

Following the attack structures discussion

Attack Closest Building' in AttackActions.lua = 20
unit.AttackCutoffRange = 15 * 1.2 = 18

"This means that if there are no towers within 20, the attack structures action will not be used at all.  If there are towers within 20 but not within 18, the actionfunction will fail."

This sounds bad to me. It should probably never have a chance to fail if it is called. Especially if the AI has a range 20 skill.

I'm not sure if it should be higher or lower though.
Maybe set it to 35 and 35 to see what happens? That is about the distance from centre flag to corner tower, and corner tower to double towers.

 

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
miriyaka
Join Date 11/2008
+76
Reply #372 July 20, 2011 12:15:56 PM
from Demigod ForumsDemigod Forums

By failing I just mean it will skip that action.  If the AI has multiple actions in its current goal plan, it will process the next one.  In the case of DestroyStructure, there probably won't be any other viable actions in its plan, so it will attempt to re-choose a goal and/or re-formulate the action plan.  Nothing bad will happen, unless the AI is being forced into a given goal and therefore limited selection of actions by external forces that don't take into account a similar target range.

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
pacov
Join Date 02/2008
+183
Reply #373 July 20, 2011 12:48:12 PM
from JoeUser ForumsJoeUser Forums

orion, if you are actually free and want to add the code change and try that out, please do so.  I'll probably be busy again tonight and not have a chance to look at this. 

thx for reviewing that code for me miri. 

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
pacov
Join Date 02/2008
+183
Reply #374 July 20, 2011 2:28:58 PM
from JoeUser ForumsJoeUser Forums

Quoting miriyaka,
reply 373
unless the AI is being forced into a given goal and therefore limited selection of actions by external forces that don't take into account a similar target range.

yeah - I'm still going through and disabling some of the overrides in heroGOAP... if I get a quick chance tonight, I'll disable all of the flee overrides, etc, and just leave the shopping overrides intact to see if that helps with the stuck ai mess.

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
pacov
Join Date 02/2008
+183
Reply #375 July 20, 2011 6:30:46 PM
from Demigod ForumsDemigod Forums

version 0.27.04 BETA
- continued to enhance the documentation in heroGOAP
- added new logic to provide a count of heroes/enemies in heroGOAP for decision making
- added rule so that the AI's goal will flee if 3 or more enemies are present vs 1 ai
- changed default value of gold and portal flags to 0.5
- increased unit.movecutoffrange from 1.2 to 2.5 in attackactions
- fixed a problem with da's new swap logic
- continuing to test out flagassets.lua - I don't think values are being loaded for each map

live now

Reason for Karma (Optional)
Successfully updated karma reason!
19 PagesFirst 13 14 15 16 17  Last
View all recent posts
Mark all posts as read Delete cookies created by the forum Return to Top
Stardock Forums v        Server Load Time:   Page Render Time:
© 2025 Stardock. All rights reserved.
Home News Case Studies Forums