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

The Updated Enhanced AI Mod Thread

demigod faq support
19 PagesFirst 15 16 17 18 19 
pacov
miriyaka
Join Date 11/2008
+76
Reply #401 July 24, 2011 9:22:05 AM
from Demigod ForumsDemigod Forums

The AI does the equivalent of clicking the reticle directly on top of you, which is something that a human player can do just as well - the only reason it hits so often is because the boulder has such a large collision sphere.

If you're not playing with the UberFix enabled, there's a bug with the ability system that allows the AI's ability use to specifically target your current location at the time of the actual ability fire/hit (like the AI's tracking hammer slam).  However, with Boulder Roll, this only gives the AI another ~0.3s or so of advantage, because once the boulder is released, it goes in a straight line toward your position at the time of the throw (as opposed to your position at the time of ability cast if a human player did it).  Again, this is fixed in the UberFix.

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

Ok playing a game right now. Prob play another after this. Will mention some things happening. 

5 vs 5 ai hard on Zikurat.

I saw Torch Bearer hitting a fort until it had a few hunderd HP. A hero came along and killed him before he (even could?) fled.

Not getting the 20% experience flag sometimes even when close and unguarded (2nd flag middle).

Pushing way to far into enemy territory (mine that is, because I notice that the most) and getting killed before being able to retreat. 

It seems like there is a lot more group combat now. Which I consider a bad thing. So much more chance that if your on the frontline alone that a group of 3/4/5 enemy's get on top of you. And your allies are possibly doing the same on the other side of the map.

 

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
pacov
Join Date 02/2008
+183
Reply #403 July 24, 2011 7:51:41 PM
from Demigod ForumsDemigod Forums

I decided to take a break this weekend.  I'll incorporate miri's new code this week (thanks again). 

oh - and keep the feedback coming.  I'll see what I can do about some user request changes this week (and not just my typical if I see it jacked up, I look into it).

My current major priority AFTER incorporating some changes is on flag locking logic.  I think the ai can become a VERY STRONG contender if it learns to lock and leave if down in ws.  That's the biggest problem I still see with the ai... it needs early locks if its behind.

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
pacov
Join Date 02/2008
+183
Reply #404 July 25, 2011 3:18:54 PM
from JoeUser ForumsJoeUser Forums

not entirely sure how much time I'll have to putz around with this today.  Prob about an hour or so.  Should be enough time to get miri's code added at least and a few minor changes. 

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
pacov
Join Date 02/2008
+183
Reply #405 July 25, 2011 7:14:29 PM
from Demigod ForumsDemigod Forums

Quoting miriyaka,
reply 397
Should have been called on initialAgent (the hero unit), rather than agent (a tracking table somewhere in the HeroGOAP mess). My bad.

Also, I just realized that the function I gave you won't work universally for both squad and solo attack, so here's a new CalculateWeights for each: http://pastebin.com/TD6JL0QG

miri - just gave this a test - I'm getting a new error now:  "access to nonexistent global variable: 'GetWeakestUnit'"

Strike that - i sorted it.

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

Quoting miriyaka,
reply 397
So, immediately after this line:
Code: c++

flags = SortEntitiesByDistanceXZ(unit.Position, flags)

..and before the flag-locating loop, add this, so the flag isn't saved to a global:
Code: c++

local flag = false

ok... i get the first part... but not the 2nd... or perhaps I'm getting it exactly right and it isn't working?  What I'm seeing is ai's casting the lock at pretty damn close to the same time.  So, one starts to cast the lock... another starts about .5 to 1 second later (before its actually locked).  Is that something that can be corrected? 

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

version 0.27.07 BETA
- increased sigil activation health % from 45% to 50%
- added new hammerslam calculate rates function - should increase the odds that rook will slam if the unit is stunned (should work for any type of stun)
- rebalanced weights of rook's actions to bring them more into logical numbers
- rebalanced weights of erb's  actions to bring them more into logical numbers

live now

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
miriyaka
Join Date 11/2008
+76
Reply #408 July 25, 2011 9:27:01 PM
from Demigod ForumsDemigod Forums

Quoting OMG_pacov,
reply 407
ok... i get the first part... but not the 2nd... or perhaps I'm getting it exactly right and it isn't working? What I'm seeing is ai's casting the lock at pretty damn close to the same time. So, one starts to cast the lock... another starts about .5 to 1 second later (before its actually locked). Is that something that can be corrected?

New ActionFunction: http://pastebin.com/EHxp2qt1

New InstantStatusFunction: http://pastebin.com/zEqxZUJE

This should prevent two AI from being able to lock a flag.  It won't stop an AI from locking a flag that the player is also trying to lock - that would require a hard override of the flag lock ability script, something I'd prefer not to do.

 

Whenever you have a request, make sure you pastebin an up-to-date copy of the function or action or whatever if you've changed it from the latest beta version, otherwise from now on I'll just be integrating any changes directly into the code from the latest release.  That should save a bit of ambiguity and work on your part.

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

ok miri - i will start pastebinning code from now on for ya.  I do appreciate your help.  I'm doing a bit of the grunt work, but having the help of an expert means I"m not spending 20 hours trying to figure out something that takes u 5 min :{

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

Tried the new one, it is much better.

AI hammers when it can.

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
miriyaka
Join Date 11/2008
+76
Reply #411 July 25, 2011 11:10:30 PM
from Demigod ForumsDemigod Forums

Here's a quick, untested prototype of a map-name mining function - stick this in a blank /lua/common/commonutils.lua hook: http://pastebin.com/spRBmsfZ

And here's another quick, untested attempt at modifying flag priorities by map - a near-total rewrite of FlagAsset.FindCaptureRewards, which was an unnecessarily long conditional mess: http://pastebin.com/w02uQSeW

You might want to start with just the commonutils hook, and add a log message to the top of the current FindCaptureReward that attempts to report the scenario name, just to make sure that bit of code works as intended:

Code: c++
  1.         LOG("FindCaptureReward:"..self.FlagName..": Scenario Name: "..import('/lua/common/commonutils.lua').GetScenarioName() or 'none')
Reason for Karma (Optional)
Successfully updated karma reason!
pacov
pacov
Join Date 02/2008
+183
Reply #412 July 25, 2011 11:13:03 PM
from Demigod ForumsDemigod Forums

Quoting miriyaka,
reply 409
This should prevent two AI from being able to lock a flag. It won't stop an AI from locking a flag that the player is also trying to lock -

the issue has always been ai locking on top of ai.  If this fixes it, we are golden.  I'll try to sort tomorrow or the next day.  Thanks!

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
pacov
Join Date 02/2008
+183
Reply #413 July 25, 2011 11:16:11 PM
from Demigod ForumsDemigod Forums

Quoting miriyaka,
reply 412
You might want to start with just the commonutils hook, and add a log message to the top of the current FindCaptureReward that attempts to report the scenario name, just to make sure that bit of code works as intended:

will do.  My next project then.  I'll provide feedback.  If you get inspired and get any further than me, please do tell.  I expect my time to be limited the next 2-3 days, but who knows.  Thanks again!

And thx for another test, orion!

 

oh - and I'll put this out there and see if any of you disagree.  I really do think that the biggest component that is missing from the AI now is warscore control.  I feel like the builds are generally solid; the item selection is generally solid; the "when to use" abilities logic is very much improved; and the RUN IF YOU SHOULD logic is pretty solid (little tweaks here and there would be good for this).  I do think that if the standard game is 3 hard ai vs 2 humans, that I could get the AI to winning about 75% of the games against tier 1 players if I can teach the ai to use capture locks and maintain a warscore adv.  That's the way is should work 100% of the time in evenly matched teams... AND we are talking about giving a gold and xp adv to the team of 3.  If the ai runs before you can kill it... and it has more money and locks down flags... that will change the meta of the game to interrupting or stopping the ai from getting early locks off... and WONT hurt the ai much to use as it will have more money.  It will eventually cripple the other team unless they can't score some early ganks... 500 gold per 3 ai can go a very long way towards a nice ws adv early.  And as long as the ai hits ws 8 before the other team, odds are that means cats will hit the field earlier with the other team down.  And that changes the meta up a little as well.  Anyway, the mod has a long way to go, but I think this will be the next major step if I can come up with some solid coding for locks to hold ws.  It's certainly not there now (the lock code is not exactly brilliant atm, but to be fair, there are A LOT of angles to consider when to use a lock if you have extra money.  Anyway, I don't have any plans to make the normal able to take out anyone tier 1 (nor do I think that should be goal).

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
Plaguewraith
Join Date 04/2011
+9
Reply #414 July 26, 2011 2:56:58 AM
from Demigod ForumsDemigod Forums


Quoting OMG_pacov,
reply 414
oh - and I'll put this out there and see if any of you disagree.

Refering to 0.27.26

Builds

I'm fine with most builds also. I wonder if the AA UB build should be disabled because the spit_ooze_health seems to be the better variant since the UB does not always ooze even when attacking (or it is standing around oozing senselessly). A routine to activate Ooze when an opponent is really near could help also maybe. But when I play I'm somewhat disappointed when my UB AI teammate chooses the AA build and somewhat reliefed when the opponent AI took it.

(when the transfer_tower Rook build was disabled and Sedna had only heal_tank, Sedna starts to win the AI battles, I'm curios how it goes now)

 

AI Performance

Since 0.27.26 the AI is stuck more often I think. Last game I saw them all standing in the middle. My two teammates at exp flag and the other three at their towers. Like every side was waiting for the other to engage. I can't tell about the health of the three so maybe they did that for a good reason? Hopefully I can mybe tell more about that later.

 

Warscore control

You mean the AI uses locks agressive when behind in warscore (you wrote something like that before)?

That would be fine, I guess. A general usage could be disappointing if, due to AI income, most flags are locked all the time.

But if they are not behind I still think just locking the enemy portal flags at 8 could be a nice thing. I've seen the AI having locks but not using it on the enemy portal flag after capturing it.

 

Difficulty

Normal should be an easy win for a good player (concerning equal team) and then it should scale of course. I think it's ok if it works fine for hard. But one reason for me to play with normal difficulty is the circumstance that I'm a new player that test builds and also have to get currency sometimes (I mostly do in MP games). With hard or nightmare teammates I don't bother at all. But that is personal I guess, so everythings fine with optimizing the AI for hard difficulty.

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
pacov
Join Date 02/2008
+183
Reply #415 July 26, 2011 8:38:51 AM
from JoeUser ForumsJoeUser Forums

Quoting Plaguewraith,
reply 415
But if they are not behind I still think just locking the enemy portal flags at 8 could be a nice thing. I've seen the AI having locks but not using it on the enemy portal flag after capturing it.

The current logic for locking flags requires (if I'm remembering right) an enemy in the area.  The AI has no concept currently of locking and leaving, per se. 

I wonder if the AA UB build should be disabled because the spit_ooze_health seems to be the better variant since the UB does not always ooze even when attacking

I thought I noticed some strange usage with ooze but I forgot to look into it.  Perhaps I'll do that soon.  I still like the AA ub build.  It has a different item build out as well that gets QUITE powerful mid to late game on hard ai.  Spit ub is generally more reliable for tearing down towers, though.  I don't think I'll remove the build, but I'll look into tweaking ooze sometime soon.

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

Quoting OMG_pacov,
reply 416
The current logic for locking flags requires (if I'm remembering right) an enemy in the area. The AI has no concept currently of locking and leaving, per se.

It's definitely possible to make a new flag lock action on only the CapturePoint goalset that instead determines whether or not the flag being checked is an 'enemy' flag, allowing a lock only then (also based on specific WarRank conditions), and doing some kind of goal re-pick afterwards.  I'll have to look into the latter; I'm not really sure how to issue a kosher goal update, but I'm pretty sure there are already some actions that do this on completion.

Regardless, creating a new portal/valor only lock action that triggers at later WarScore and ignores enemy presence should be fairly straightforward.  Just copy the existing action, and in the weights and status functions, just replace any enemy/threat checks with WarScore checks, maybe multiplying weights if there's a particular negative difference in team warscores.

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

Quoting miriyaka,
reply 417
It's definitely possible to make a new flag lock action on only the CapturePoint goalset that instead determines whether or not the flag being checked is an 'enemy' flag, allowing a lock only then (also based on specific WarRank conditions), and doing some kind of goal re-pick afterwards. I'll have to look into the latter; I'm not really sure how to issue a kosher goal update, but I'm pretty sure there are already some actions that do this on completion.

Regardless, creating a new portal/valor only lock action that triggers at later WarScore and ignores enemy presence should be fairly straightforward. Just copy the existing action, and in the weights and status functions, just replace any enemy/threat checks with WarScore checks, maybe multiplying weights if there's a particular negative difference in team warscores.

Yeah - I get the straightforward logic.  I'm just trying to think through all of the variables and figure out what the appropriate rules should be.

Here's what I'm thinking in general.  If you are down in ws by >= 100, then capture any of the middle flags, lock and then leave.  If any enemy dgs are present, you'd just want to leave them on the locked flag and move on to another flag.  Continue locking until the deficit drops to <100 ws.  The current override system as its coded wouldn't work for this as the assassinate override is checked before the capture flag override.  That shouldn't be all that complex to modify (or so I think).  I don't mind quite a bit of waste if it means the game will be competitive.  Most test games against the AI have me winning by like +2k in ws, which is pretty unacceptable.  So what if they buy cats/giants when they hit wr 8 if they never reach wr 8. 

Anyway, there's a bit to figure out to force a lock JUST on key flags, but I think the doing it based on how much down in WS the ai is shouldn't be a problem.  I suppose we could keep the flag lock logic generic and not specific per flag, but I figure this will result in locking pointless flags (locking valor early for no good reason or flags that won't be contested).  On cata, you know that the 3 middle flags will always be contested, so having specific logic would be better here.  I don't know - I think a bit of this will be tricky.

Any code you want to wip up, miri, I'll be happy to test out.  

Then the late game straight forward coding would be to lock the portal immediately or attempt to lock no matter what. 

 

Oh - with regards to the AI's grouping up at mid from time to time and being stuck, I think a bit of that has to do with my current flag weight values.  I tweaked those a bit when we killed the per map flag settings, so I need to revisit that.  Noticed the AI having a tendency to work the middle instead of pushing the portals, etc in a game last night.

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

Quoting miriyaka,
reply 409
otherwise from now on I'll just be integrating any changes directly into the code from the latest release. That should save a bit of ambiguity and work on your part.

oh and thanks for that, miri - that should help out a bit.

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
miriyaka
Join Date 11/2008
+76
Reply #419 July 26, 2011 1:30:05 PM
from Demigod ForumsDemigod Forums

I need to figure out a reliable way to determine when the flag in question is on your side of the map, or the enemy's side, otherwise you're right that they'll just lock any portal/valor flag they come across.   I'll try to work on that sometime in the next few days.

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
pacov
Join Date 02/2008
+183
Reply #420 July 26, 2011 1:59:38 PM
from JoeUser ForumsJoeUser Forums

Quoting miriyaka,
reply 420
I need to figure out a reliable way to determine when the flag in question is on your side of the map, or the enemy's side, otherwise you're right that they'll just lock any portal/valor flag they come across. I'll try to work on that sometime in the next few days.

Yeah - that bit might be tricky... wonder if there is some way to evaluate based on distance to crystal or citadel.  Anyway, the middle flag bit can be covered if we can just do it by flag name.

thx again.  Should take a me a few days to work on the code you've already provided and do some testing... if that code for grabbing the map name works, I'll have my hands full doing some re balancing on all of the maps anyway.

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

Quoting miriyaka,
reply 409
New ActionFunction: http://pastebin.com/EHxp2qt1

there's a syntax error in the function.  I'll debug it a little later tonight if I don't hear from you - thx... debugger is complaining about not having an end statement where it wants one.

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
miriyaka
Join Date 11/2008
+76
Reply #422 July 26, 2011 6:11:35 PM
from Demigod ForumsDemigod Forums

Quoting OMG_pacov,
reply 422
there's a syntax error in the function. I'll debug it a little later tonight if I don't hear from you - thx... debugger is complaining about not having an end statement where it wants one.

Yes, for some reason I tried to put a statement after a 'return', which you can't do.  Fixed: http://pastebin.com/EHxp2qt1

Ran this through a standalone interpreter, so it's at least free of syntax errors.

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
pacov
Join Date 02/2008
+183
Reply #423 July 26, 2011 6:54:17 PM
from Demigod ForumsDemigod Forums

Thanks.  No more syntax issues.  Testing out the code now.

edit - it checks out.  Only played through 1 quick game and watched.  Lock logic seems to be working and I didn't see any dbl locks, so things appear ok.

Reason for Karma (Optional)
Successfully updated karma reason!
pacov
pacov
Join Date 02/2008
+183
Reply #424 July 26, 2011 7:13:55 PM
from Demigod ForumsDemigod Forums

version 0.27.08 BETA
- Added new action and instant status function in useitemactions to keep the AI from "double locking" flags (eg wasting locks on a flag that is locked)

new version is live now.

Obviously, just a minor release - but this tested out and I don't think I'll be doing any more coding this evening.

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

Killed Oak just very very easy when he ran in to use his hammer after a stun from someone (granted he was level 1 but still)

The game is also suddenly abit laggy/shocky. Only since the last week. Might try a game in the future without this mod.

Lightningball guy just died twice very easy because of coming to close/into the area of the towers (on that map without anything in the middle)

Rook just almost captured a flag but took off before it was done.

Oak just followed me through the line of towers and then ran past the Citadel and died.

 

ps. Lock = capture (attempt)?

Just so I understand a little bit of whats going on.

Reason for Karma (Optional)
Successfully updated karma reason!
19 PagesFirst 15 16 17 18 19 
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