The Updated Enhanced AI Mod Thread

pacov

Join Date 02/2008

+183

The Updated Enhanced AI Mod Thread

Updates:

Public version 1.03 live 1/18/2012 at 6:07 PM EST

Download links:

Link to the latest version PUBLIC version of the mod: http://www.box.net/shared/g8lbbhpojik4tbkjn6su

I created a post that tracks the history of the AI in Demigod and it covers a good chunk of the development that has already been handled by the modding community. If you are interested, see over here for more details: http://forums.demigodthegame.com/409712

The Project

Using the last version of peppe’s AI mod (0.26.35), I’ve started development on updated versions of the AI mod. I’ll be releasing those versions here, tracking bugs, enhancement requests, rebalancing, etc. I won’t be adding a new version to my combined DG installer until we make a decent amount of progress or come up with some sort of significant enhancement to justify a new release to the community at large. It took us a long time to get reasonable adoption rate on the existing ai mod – I’d rather not force folks to redownload the bundle over and over.

The Project Team

Project lead: pacov
Lead design/coder: pacov
Lead support: miriyaka – without miri, the majority of the changes we are looking at would not happen
Testers: sledge, plaguewraith, and darkliath
Contributors: Lord_Orion

If you’d like to help in any way, we are happy to have you on the team.

Current status (what’s being worked on)

Build updates (removing inefficient builds and replacing them with new ones) - complete
Reprioritization of citadel upgrades, items, trips to the shop - largely complete - some late game tweaking still possible, but its improved quite a bit
Implementing a fix for AI’s with summonable minions so that they do not waste mana summoning more after the have created the max number of minions (miri created some code and I’m looking to make it work) Resolved in 0.26.41
Recoding the ShouldSave functionality to improve the coding efficiency and gives us additional flexibility. If we get this working, it will be a very solid improvement and provide more options. - this has been implemented

Bug list (unless otherwise noted, these are all bugs from the original 0.26.35 version)

Stuck AI – the AI can get stuck on occasion for > 30 seconds
Poor scaling based on AI difficulty - this has been improved but there is still room for improvement
Not enough shopping trips for the AI unless it is killed or sent back the base with low HP (eg an AI could have 10k gold and still not attempt to shop and get better items) - 1 forced shopping trip at wr 4 has been added... might be good to do more, but much better now.
AI is not always getting fs1 in a timely manner (resolved in 0.26.39)
Some abilities are not being used as often as they should (a sedna, for instance, with pounce as her only ability would use it once in a blue moon) - continuing to make improvements (pent/pounce/grasp/deep freeze have all been fixed)
Some abilities are being used at inappropriate items and wasting mana as a result
Customized settings often throw the AI off. For instance, if you set a game to being at WR10, the AI don’t shop (not sure if we want to try to code this to cover all possible settings) - improved some.
AI standing around at the shop at the beginning of the game (introduced in 0.26.38 – happens randomly and seems to only impact 1 ai on a team) - resolved in 0.26.40
Not truly a bug, but something I want to change - need to make it so the high gold dg can still buy things for themselves (resolved in 0.26.49 "siesta")
AI considers minions as part of a DG's army... this is good and bad - its good to target healers from time to time, but if I can make an enemy target a shambler while I'm wailing on him...

Enhancement requests (these are changes that folks would like to see happen with the AI)

Better healer distribution. The over all goal would be to ensure that monks/clerics/etc are sent to appropriate players. The basic code works fine, so this is a lower priority change imo.
Improve da’s shadow swap usage – plaguewraith suggests removing it completely from his build (might be a good temporary solution until we can tackle this) (removed 0.26.55)
Better creep farming with skills. Plaguewraith indicated that he never saw a tb use circle of fire to farm. This is something we could tweak, but we’d need to think it through
Lord-Orion suggests we remove all ub builds except for Spit/Ooze life - REMOVED 1 OF THE BUILDS 0.26.40 - still 2 left
Lord-Orion suggests we optimize all builds for skill dmg output as the AI cannot currently rationalize like a human can.
Lord-Orion suggests we go with a basic item prioritization of 4 life/1 helm builds – I agree to some extent… (pretty much done as of 0.26.52)
Come up with a way for the ai’s to intelligently chain stuns or interrupts to go for kills. In theory, the AI could be even better than a human at this if it was tied to precise timing
Teach the AI to teleport for ganks (this could be tricky – would probably result in a lot of pointless tp’s)
Find a way to help the AI manage mana better. Early game the ai’s are almost always out of mana
Teach the AI when to shop! (big improvement with 0.26.49 "siesta")
Have the AI always engage a simple enemy opponent if on a flag if hp is good, etc
Have the AI choose to engage towers on a regular basis (improved a lot since 0.26.54)
Have the AI refuse to run past towers in most circumstances and instead TARGET THE TOWER if no dgs around
Improve cataract map logic – the ai often goes into the middle of the map instead of staying in a lane. This is probably due to the proximity of the creeps when the ai is working on capturing the middle flag (or if all flags are controlled by their team). Ideal behavior would be to try to capture the middle flag and if its already controlled, then get into a lane on HP or Mana.
Override the flee functionality if there is an enemy dg and its likely possible to get a kill
Better decision making for flags – Ai heading over from mana side all the way to Hp without capturing mana. this is likely due to flag weights… just not sure why it didn’t evaluate hp as the priority initially – could be some conflicting code?
Send the AI back to base if its low mana (sledge) – We might do something for this, but it would have to be a conditional statement – perhaps add a check to see if they are at low mana around X Ws have > X money, then run back and prioritze getting a helm as an override
Plaguewraith suggests removing mist from erb’s build – I’m not sure about this yet. He says remove it or build a routine to cause erb to use it just to get rid of negative buffs – I agree that we could use a routine like that. - mist removed in 0.26.40
Encourage the AI to react quickly if they are losing a flag that is near 2 or more towers (eg gold flag)
Increase the frequency that the AI picks up sigils – not sure about this one – I agree a good player should generally have one, but the AI might just blow a lot of money casting when it doesn’t need to and fall behind as a result. Perhaps this becomes a conditional statement to raise the priority after ws X (0.26.47 - implemented)
Add an override so the ai will only go for flags like gold if the tower is down. Add another override so the ai doesn’t go for portals early (probably WS related)
plaguewraith – delete the tb builds and just stick with 1 fire tb build - REMOVED 1 BUILD - only pure fire and pure ice remain 0.26.40

Change log

version 1.03
-Created new UID
-Adjusted hero/squad targeting values to increase AI skill use aggression
-Adjusted range cutoff multiliers to mitigate the chance of the AI from running past towers to cap flags
-Adjusted/fixed errors in Oak, Queen of Thorns, Unclean Beast, Regulus and Demon Assassin AI builds
-Re-enabled Sedna Pounce build and Queen of Thorns Shield_Spike build
-Homogenized AI build names so it is obvious what skills the AI is using.

version 0.28.00 BETA
- removed unclean beasts AA build as the Spit ooze build is generally a little better

version 1.02
- created new UID and incorporated all changes since version 1.01

version 0.27.09 BETA
- Disabled a substantial amount of logging (will result in a substantial performance boost for many)
- added miri's scenario name capture function to CommonUtils.lua (doesn't work now, but isn't being called)
- began to tweak ub's usage of ooze. Reduced health activation from >= 40% hp to >= 30%. Also reduced the deactivation health value from < 40% to < 30%
- reenabled the attack override in herogoap
- updated the flee mastergoal to set at 50% HP instead of the current 75% hp
- Added an action time to health pot usage to hopefully keep the AI from using a pot at lower HP, having the pot bring them up to full strength and then having the ai immediately sigil

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)

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

version 0.27.06 BETA
- reduced sigil activation health % from 50% to 45%
- changed orb of defiance usage check so that it will consider using it before sigils
- removed grunt check on orb of defiance (previous the AI would refuse to use use the orb if the threat level was < 15)
- added nearby enemy hero check to orb of defiances - if no enemies nearby, then orb will not be used
- reduced the value of narmoth's ring on the AA ub build so that it is not choosen as the only item at the start of a game on nightmare difficulty
- reduced the captureflag override at the start of the game from 60 seconds to 40 seconds
- disabled the attack override to allow the ai to make its own decisions based on weight
- Reduced the reteat values if there are nearby enemy heroes and towers from 85% to 75%
- modified rules for dg vs dg fights. AI will run if there are more enemies than allies present

version 0.27.05 BETA
- removed the nonworking per map flag settings
- revised the generic flag settings
- disabled all existing rook builds
- added new "more balanced" hammer slam tower build

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

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

version 0.27.02 BETA
- major revamp to DA's swap ability - da will now only swap if the number of allies is > enemies near da
- disabled existing DA build
- enabled STANDARD_ASSASSIN da build (eg what most players use when playing da) now that swap is working as desired
- disabled pounce sedna build

version 0.27.01 BETA
- updated TB's frost nova so that it is used more often

version 0.27.00 BETA
- created new UID - this is done so folks can still keep the release version 1.0 installed and try out new "beta" versions and help with testing, etc
- added additional documentation to AIGlobals.lua
- adjusted the saving routine so that angels are not saved for until ws 7
- changed the way the AI evaluates additional shopping trips. Now based on warscore
- fixed a minor bug with reg's mark of the betrayer squad target
- added additional shopping trips (see details below)
    # SHOP PERIODS
    # Warscore >= 300, AI with most money, possible to buy fs1, at least 600 gold
    # Warrank >= 3, AI with most money, possible to buy cur1, at least 1800 gold
    # Warscore between 2450-2575, NOT AI with most money, at least 1500 gold
    # Warscore between 3100-3225, AI with most money, at least 1500 gold
    # Warscore between 3800-3925, AI with most money, at least 1500 gold
    # Warscore between 4150-4275, NOT AI with most money, at least 1500 gold
    # Warrank 8 OR AI already bought the upgrade, priest/angel/cats available, AI can afford the upgrade
    # Warrank 10, possible to buy giants, AI can afford the upgrade

version 1.00
- created new UID
- removed any "pacov" labeling
- changed name to Enhanced AI (peppe's original version was Enhanced_AI
- updated version name to 1.00 (numbering convention will be 1.00/1.01/etc going forward)

version 0.26.56 (misc fixes + pounce sedna build is live)
- removed CaptureFlag goal weight from oak's pent functions
- removed CaptureFlag goal weight from rook's hammerslam functions
- removed Captureflag goal weight from tb's deep freeze functions
- removed CaptureFlag goal weight from ub's grasp functions
- removed ub's mygraspstatusfunction and replaced with DefaultStatusFunction
- removed oak's myPenitenceStatusFunction and replaced with DefaultStatusFunction
- removed sedna's myPounceStatusFunction and replaced with DefaultStatusFunction
- substantially increased sedna's desire to pounce
- re-enabled sedna's pounce_tank build

version 0.26.55
- fixed a bug that still allowed demon assassin to pick up swap
- fixed a bug with unclean beast's grasp code
- enabled new hammerslam/tower rook code and tweaked desire to hammerslam
- increased sedna's desire to pounce (did not re-enable the pounce build yet)

version 0.26.54
- removed the remaining demon assassin build and added a new build without swap per request
- reworked the valor flags weight. Should be less desirable for AI prior to ws 8
- tweaked deep freeze to be cast much more often
- re-enabled ai priority to attack structures. Tweaked the formula so the AI will immediately back off if any enemy dgs come into range. This should reduce the odds of death and also keep the AI from wandering past towers for the gold flag, etc

version 0.26.53
- increased artifact weight so they will be kept if the AI purchases
- added mageslayer to the generic equipment purchase list with a priority of 110, moved godplate to 120
- enabled oak to cast surge when trying to flee

version 0.26.52
- substantially increased the odds that oak will attempt to interrupt
- removed demon assassin speed_spine build
- re-enabled the graveyard level 1 upgrade
- minor misc changes
- changed ai's desire to pick up locks from level 3 to level 4

version 0.26.51
- rebalanced the general equipment builds
- rebalanced the specific demigod equipment builds
- removed AI's desire to purchase any graveyard upgrades
- removed "cloak of invisibility" from artifact prioritization as the item does not exist

version 0.26.50
- Reduced priority from 35 to 20 for boots of speed on UB HP/ooze build to keep the AI from purchasing boots of speed as the first item if the AI is set to normal
- increased priority of grofflings plate in the general build
- substantially increased ub's desire to grasp in game
- updated flag goal for cataract to reduce the AI's desire to grab the valor flag early (eg the AI running to the middle of the map)
- increased ice tb's goal to make it use deep freeze more often (tb's abilities all need a bit of an overhaul)
- various item selection tweaks

version 0.26.49
- changed desire for flag locks to increase at wr3 instead of wr4
- adjusted AA ub build so that it will never choose mana items (unbreakable is still acceptable, though)
- implemented the "siesta." At warrank 4, any ai (not the high gold AI), will return to base to shop as long as they have 1500 gold. Then, towards the end of wr4, the AI that is the highgold AI will shop alone.

version 0.26.48
- added miri's check to force the tb to stay in whatever mode its build is designed for. This should improve the AI's usage of abilities tied to the pure ice or fire builds. Confirmed that fire tb will stay in fire form and ice in ice form based on build.
- continued to balance item selections
- Changed Rook's favor item to blood of the fallen
- TEMPORARILY turned off the attack structure code

version 0.26.47
- made MANY balance changes - all changes are noted in the files, but too many to detail here (so I'll cover highlights)
- changed ideologies for the mod. Before the goal was to force the AI to do everything I wanted it to do (simply buy cit upgrades) - now I'm planning on having it scale that back and focus on becoming an arse kicker
- odds your ai will have a sigil is MUCH higher - this improves survival odds ALOT
- ai will always purchase fs1/cur1/priest/angel/cats/giants - that's it. AI will no longer get any levels of experience.
- ai will VERY OFTEN have locks - I still need to teach the AI how to use locks better though... so at least for now, it will have them...
- MANY item prioritization changes - If you understand the modding side of things a wee bit, there are 2 ways a dg chooses equipment/items: 1 - a general list that contains all recommendations. 2 - a list that is specific to demigod build. I spent quite a bit of time improving the general list today and started working on the 2nd method that includes build specific items. I've only started on QoT, but I will likely get her to mimic my standard QoT build for items.
- removed some additional checks to help reduce overhead of the AI

* note - I have not begun to force shopping trips on the AI outside of fs1/cur1/priest/angel/cats/giants. I'll be looking to start phasing in shopping trips to encourage the ai to get even better items as appropriate. AI will still shop if it gets its arse kicked, but I want to schedule some trips so the AI will get stronger at different intervals even if its doing fine.

version 0.26.46 (the getting back on track version)
- added miriyaka's changes to the save function so that we can evaluate based on warscore as well
- added saving for fs1 as a priority after ws 200
- updated value for fs1 to increase its priority to 200 after ws 300
- removed log writes from miri's savefor, etc to see if that helps the lag issue that's been mentioned
- confirmed - the generals will now choose monks if they are a normal ai with default settings (instead of saving for fs1)

version 0.26.45 (the lesser of two evils/back to basics version)
- the title gives you an idea - if you play on normal settings with 1 general ai, they will NOT purchase monks at the start. This is not desired behavior. But in allowing this, the AI does not freeze between ws2 and 3 for any extended duration. Sadly, the other option right now is you get monks, but the ai stands around like an idiot at ws2.
- Added additional documentation for the herogoap file
- disabled the trip to the shop for ws 5 to get cur2
- developed basic test code to send the ai to the base if its not the high gold ai
- backed out the changes that increased rate of fire for bite/pounce/pent. We'll visit this again, but I'm concerned that the ai is overriding their flee function due to the high priority I put on these abilities resulting in more pointless deaths. My goal is to simply make them use their abilities more often... not die like goofs.
- tweaked the rules for purchasing sigils. AI will not buy them until ws 2 and only if the AI has a max health > 2750
- removed assassin sedna build again until I get back to sorting pounce

version 0.26.44
- hopefully corrected a bug that would cause the ai wait around to purchase an upgrade if it did not have enough money of the ws for it. This should give us new opportunies for balancing upgraded in the future. The short version is I updated HeroGoap perform a check if the ai can afford the upgrade they are saving for before heading off to the shop. Not enough money = no shop. I'll be looking into explicitly sending specific ai's to shop on some sort of interval in the future
- (not a real change... but started deep dive into integrating miri's savefor function)
- removed cur2 shopping trip for now - it still gets a high priority, though

version 0.26.43
- added miriyaka's save for gold functionality
- disabled ai goal chat function from herogoap 1198

version 0.26.42
- substantially increased the rate that erebus uses bite
- substantially increased the rate that sedna uses pounce
- re-enabled assassin sedna build now that pounce is used more often
- substantially increased the rate of oak's penitence
- added another shop period at ws 4 - the ai with the most goal should head for base a 4. This might result in a different dg being choosen for highgold after

version 0.26.41
- added miriyaka's summon shambler fix. The code would work for QoT, Sedna, and Oculus. I'm only implementing it for QoT as this would be a disadvantage for the Oculus build and sedna does not use yetis in the AI mod
- Removed anklet of speed from all TB builds and replaced with Blood of the Fallen. The ai is not smart enough to use a speed fire tb build
- Removed the file mod_units. This contains fixes already in uberfix and is not needed here
- Enabled master goal chat - this is a debug function that broadcasts what the AI's goals are - you might find this annoying...
- Re-enabled code that adds a destroy structure goal for the AI. Peppe turned this off at some point... probably for a good reason, but I did see the AI being more aggressive attacking towers, so I'm leaving this on for now.
- Made some adjustments to the flag weights on cataract. This SHOULD end dgs running over the the mana flag at the start and then rushing to HP before they capture the mana flag. Reduced the weight of the gold flag to encourage the ai to attack structures first. Reduced the value of portals prior to ws8.
- Removed all oak builds and added a new shield/pent focused build
- Minor change for reg's build - added impedance bolt at level 16 instead of stats 1

version 0.26.40
- removed the code that placed a limitation on what items could be purchased at the start of the game (AIShopUtilities 736-741)
- Changed the priority level trigger from WarScore to WarRank for fs1 (AIGlobals 1433) - this appears to have resolved the ai's standing at mid issue. The Ai will purchase fs1 at ws2 now correctly
- Changed AI's priority to get xp2-xp4 to 0. AI will no longer purchase these upgrades
- removed mist and added coven 1 as erb's level 2 skill until we get a chance to write a routine for him to use mist to remove negative buffs
- Updated ai priority values for minotaurs to 0/5/10/15 (eg an ai will never buy the 1st level minotaurs now) - I was seeing the ai pick this up as a cheap filler if they have the money - not worth it
- Updated ai priority values for level 1 archers - dropped from 15 to 0 so the ai will never buy
- updated ai priority values for hauberk of life - dropped from 40 to 35 so that unbreakable would be chosen over this if money was available
- updated ai priority values for unbreakable - removed conditional formula and set to a static 39
- removed ub skill build spit_ooze_mana (essentially bots ub)
- removed hybrid_fire_ice build from tb (bots tb)

version 0.26.39
pacov is learning things…
- reprioritized AI to purchase fs1 at ws2. Previously, it only purchased it if made it back to base with enough money; this forces it back to base to get it if no one else has
- raised priority for currency 2. Logic mirrors currency 1 as I want this purchased every time. Also sending ai with the most gold to purchase at ws 5.
- removed assassin sedna build until I have a chance to look at the pounce training – assassin sed should be pouncing left and right… right now its like once in a blue moon – heal_tank sedna is solid though

version 0.26.38
removed unitstatussensors code – concerned it might be causing an issue
- tweaked erebus build so that he gets mass charm later – he’s not using it well as is

version 0.26.37
bugfix – just resolving a sytax issue

version 0.26.36
copy of peppe’s version 0.26.35
- removed 3 old sedna ability builds
- added 2 new sedna ability builds
- removed old qot ability builds
- added new qot ability build
- removed 2 old erebus ability builds
- added 2 new erebus ability builds
- uncommented some code peppe developed in UnitStatusSensors that might help resolve the frozen dgs
*note – all builds that have been added by me will be announced in team chat at the start of the game and will say “pacov” folowed by the build name.

demigod faq support

Pinned, Locked Post +1 Karma

Advanced Search

Watch this post

Do not email me updates for this post Email me updates for this post

Successfully updated karma reason!

Quitch

pacov

Join Date 02/2008

+183

I'm actually really pleased with the build I'm toying with right now. There are still "Stuck" moments, but I'm seeing some substantial improvement.

Successfully updated karma reason!

pacov

Join Date 02/2008

+183

heh... well, working on one of my test builds... let's just say that 2 experts probably could not beat 3 nightmare ai's on normal settings... ever.

if you want a comparison, with the vanilla ai, I can win against 5 nightmare ais solo with a little work. On the current release version of the ai mod, I can take out 3 nightmare ais solo, but its a challenge. And this crazy build ups it another level - (eg take 2 pacov's and we can't beat 3 nightmare ais).

it's basically pit bull mode... the only time the ai feels like not killing you is when its getting items to kill you better... it literally will not stop until its dead or you any enemy near it is dead. So, if you are playing against dgs with interrupts... you aren't getting away.

it's release worthy, but would not even be remotely challenging on hard and less for experienced folks.

The reason? The AI has absolutely no concept of fleeing. So, if its under equipped or just playing solo, it will be easily farmed. But in a 2v3 setting, its pretty damn well unstoppable.

The only major priority the AI has is trying to kill its opponents no matter the cost. If no opponents are around, it will go back to its flag capturing/farming routine.

From what i've watched, this setup does keep the AI from freezing (thought I'm sure it probably has a moment here and there).

Anyway, the thing I'm working on is coming up with a more acceptable fleeing routine. But that said... that's going to be very complicated to strike a solid balance between going hyper aggressive for kills and backing the fug off.

Successfully updated karma reason!

pacov

Join Date 02/2008

+183

MIRI - perhaps you can lend a hand here - I'm trying to set some goals in heroGOAP. specifically, in that huge elseif chain that sets ai's priorities to override the normal goal sets. What I want is to develop the rules for assassinate/flee a bit more (around line 1000-1200 or so). I want to get a count of the allied heroes and a count of enemies in the area and drop the flee % accordingly. I just need the logic for the count... but it needs to work as a part of the else if.

Successfully updated karma reason!

pacov

Join Date 02/2008

+183

also... holy shite is the ai stupid late game. There's the basic try to save the portal/valor flag logic (side note, the ai won't make that its #1 goal if its busy doing something else), but the ai literally gives a crap about its citadel. meh... a bit to tweak there... someday.

I've got a build I've been toying with that is a compromise between the bulldog build and an ai that cares a little more about survival... I'm not a fan atm, though. We'll see... maybe I'll release the bulldog to give you an idea. Side note... if you have a wee brain, you should whoop the bulldog in 1v1

edit - you folks have any thoughts on what I should release? The bulldog will give a STRONG challenge in the scenarios I described. EG more challenging than any AI you've had to deal with in DG... but its utter crap in other modes. Eg the only way to play it is by giving it an advantage and hoping you can catch up.

Or i could release my other version. Its a little better than the current AI, but still needs some balancing. Anyway, I'm busy for most of the day tomorrow. No release tonight. Appreciate any additional play tests on the previous version paying CLOSE attention to when the AI decides to shop.

Successfully updated karma reason!

I would like to try the "bulldog" version.

So, I would have a way to compare the two, almost opposite, behaviors of the AI. The good settig would be somewhere in between, I guess.

Successfully updated karma reason!

pacov

Join Date 02/2008

+183

Ok. I'll see if I can release the bd version sometime today.

OK - here's just a plain version so I can keep a clean, but updated build.

version 0.27.01 BETA
- updated TB's frost nova so that it is used more often

live now through the beta link. I'll upload the bulldog version soon if possible.

Successfully updated karma reason!

pacov

Join Date 02/2008

+183

Here's a link to 0.27.01 BULLDOG - includes same tb fix as 0.27.01 with the AI aggressiveness changed: http://www.box.net/shared/5aem4y3lz0g06boi2k86

It has a different UID than the normal beta, but it overwrites the beta directory.

And here's an alt version that I'm not quite happy with, but it sports a more aggressive AI (not at all as aggressive at bulldog, but closer to what I want to release - still needs ALOT of tweaking): http://www.box.net/shared/alnij4eypx5f03q5id1b

Successfully updated karma reason!

I don't really have the time or energy to look into the AI right now, sorry. Like I've said, the whole mod needs a re-write from the ground up to expand the goalweight system, and that would take hundreds of hours. Anything else you do is going to fix one thing, and break two others. If you're unwilling to spend the time to understand the whole goalweight system (and I wouldn't blame you, it's pretty cryptic), then I would be very careful with the force changes you make elsewhere in the decisionmaking loop.

What did you change to remove the AI's desire to flee, and how do you know that is what was causing the stuck state?

Edit: I'm still willing to review specific bits of code if you want to pastebin them, but I'm not going to spend hours digging through the AI to try to better understand it myself. Maybe in the future, but probably not.

Successfully updated karma reason!

pacov

Join Date 02/2008

+183

actually, nevermind - I just figured out syntax that will work.

anyway, miri... believe me, I get that there is a complex underlying system that increases and lowers goal weights based on hp, etc. That said, it certainly looks like GPG choose to go the same route I am with some of their later releases. I archived herogoap from one of a earlier builds of DG (well, I archived dgdata.zip). Anyway, in that version, there are NO overrides that I can see here (eg no explicit RUN if you are 30% hp, etc). Then, in a later version of dgdata.zip (not sure when it started), they started inserting overrides that would intentionally IGNORE the weighting system and force other priorities. I'm just looking to enhance that override logic and am not paying attention to the weighting (eg what GPG did when they started forcing some goals in herogoap).

Successfully updated karma reason!

pacov

Join Date 02/2008

+183

oi - side note... the retweaking the overrides is a pain in the butt. Its going to take a bit to come up with better overrides than what is in place. Still - knowing that your ai teammate will always attack a tower with with you if its needed or that the ai will go to work on one solo if the conditions are met.. very nice. Anyway - good progress now...

Successfully updated karma reason!

If you want to get net enemy hero count (enemy heroes - allied heroes) then set enemyHeroCT = enemyHeroCT - allyHeroCT immediately after myHealthPercent is set based on enemyHeroCT. Then you can refer to enemyHeroCT (which will be a number rather than a bool like enemyHeroes) for the enemy advantage factor. If it's 0, there are either no enemies within range 15, or enemies and allies is equal. If it's >0, then there are more enemies than allies. If it's <0, the reverse is true. Just keep in mind that the range at which enemyHeroes triggers (30) and enemyHeroCT is set (15) are different. I don't know that there's necessarily a reason for this, but whatever.

Quoting OMG_pacov,

reply 335

GPG coded quite a bit of flee logic into the herogoap file that certainly seems to override any weights.

Peppe added that, actually. There were zero overrides in the original SelectGoal. Adding these may have seemingly simplified making changes to the AI, but is also what's created most of the problems that the mod has added (stuck AI, ignoring nearby enemy sensors, etc).

Quoting OMG_pacov,

reply 336

No, look at HeroGOAP.SelectGoal in 1.3 dgdata.zip - there are no overrides, and the function is about 60 lines long (as opposed to ~400 in the mod). Every single one of those conditions could have been boiled down to a handful of sensors instead of being forced, better interfacing with the current sensor system, although this would have required a much more complete knowledge about the goal weighting system, and optimally the addition or one or two new mastergoals and/or goalweights.

The main issue with this is that having even one single override in that function invalidates a host of sensors and other behavior control mechanisms, throwing the entire AI off balance and requiring more and more and more overrides to force the AI to behave somewhat like it did when it was working entirely off of sensors.

The transition to sensors could still be done without destroying the mod's other changes (which are almost entirely positive as far as I can tell), however it would be a lot of work.

Successfully updated karma reason!

So, I've tried the bulldog version once and haven't looked closer. Suicide version would be the better name!

But I've played several games with the other version (0.27.01 BETA NO QUITE BD,Cataract, Uberfix1.05, high towers, all difficulties exept easy) and I think I know waht you mean with "not so happy". But there were a lot of situations where I thought "not so bad".

- The AI is ignoring towers very often. Of course it is ok if they're chasing another DG but even (o especially) when they're alone they don't attack the tower. In an game where I watched 3 TBs (which has improved I think. Using his skill now more often. But only on Dgs. Fire Nova is a nice exeption. I've seen the AI farming creeps with it) it seemed that the decision to attack the tower was interrupted by some thing. The AI TB went toward the tower the AA animation started and before the attack was really completed (and the fire bolt released) it backed off again. It was at WR 8 where I saw them attacking the first mana lane tower with AAs. They only started using skills when an enemy DG showed up, hitting the towers "accidently" then.

Unfortunately I can't help you with the code and and I don't now how it works, so if I suggest something it might be stupid to some point... But that won't stop me! ^^

Can towers get the same priority than DGs? I mean that they are not the main target, but that the DGs also attack them with skills. Unfortunately, if that is possible without loads of work, it has to be triggered by some event. A lvl 1 DG that makes the decision to destroy a tower... Well, we now the outgoing. Lvl could be a good restriction (lvl 7 for example) or item restriction (when nimoth is bought).

Most of the other things are still the same.

I would really recommend to tell the AI at WR 8 to get locks. Before that they really waste them. All the other things may be difficult to manage but when they start wasting them at WR 8 it might feel more comortable.

In a game where I watched AI Rook with the hammer/tower build I think it gets hammer to early because it is always oom.

My suggestion would be 1. tower 1 --> 2. shoulder 1 --> 3. save --> 4. tower 2 --> 5. shoulder 2/boulder 1 --> 6. hammer 1 --> 7. tower 3 --> 8. trebuchet --> 9. save --> 10. tower 4/boulder --> ...

The idea is, that maxing out hammer later is saving some mana. Another thing is, that the shoulder weapons are a really good for a AI that sometimes struggles in making decision, because they attack indepently.

Successfully updated karma reason!

pacov

Join Date 02/2008

+183

quick thoughts... I think I might remove the assassin sedna build again. It still doesn't fire off anywhere near as much as I want it to.

Successfully updated karma reason!

pacov

Join Date 02/2008

+183

Quoting Plaguewraith,

reply 339

Well - there is always room for tweaking that. My ideal version would be to have the AI start using locks aggressively if it falls behind by >300 or > 400. I can pretty easily remove the AI's desire for locks until later (until I get around to changing that).

I'll think about your suggestion re: rook. The nature of the beast with most builds used by humans that include HS is that mana starts running out. Mayhaps I'll try your suggestion. I could increase his desire for mana items, but then he'll be a bit more weak... and die more as a result...perhaps anyway.

I could force the "Bull dog" behavior with an function pretty easily. EG attack a tower until you die, etc. That's undesirable behavior as well... but its doable.

Successfully updated karma reason!

pacov

Join Date 02/2008

+183

Miri - is there any simple way you could help me understand the range thing? EG - range of 15, range of 30, etc. I can do trial and error, ofc, but any better understanding would be good. Thx.

Successfully updated karma reason!

Quoting OMG_pacov,

reply 340

quick thoughts... I think I might remove the assassin sedna build again. It still doesn't fire off anywhere near as much as I want it to.

Yeah, it's a bit strange. It uses heal often but no pounce lategame. When the game starts AI Sedna pounces from time to time, but later no more. So the 4 skill points are wasted somewhat. Heal_tank is much more of a challenge at the moment, imho.

Just another quick idea:

Is it possible to implement some code where a human player can tell the AI which build to get?

For example, I write "1" just when the game starts and the AI will always get a certain build I can rely on.

Successfully updated karma reason!

pacov

Join Date 02/2008

+183

Quoting Plaguewraith,

reply 343

Is it possible to implement some code where a human player can tell the AI which build to get?

that's a miri question for sure. It might be possible with the chat mod to sent a command across.

Successfully updated karma reason!

Quoting OMG_pacov,

reply 342

Miri - is there any simple way you could help me understand the range thing? EG - range of 15, range of 30, etc. I can do trial and error, ofc, but any better understanding would be good. Thx.

Your guess is as good as mine as to why those two ranges are different. I guess Peppe was using the myHealthPercent to decide when to attack, which I think will work similarly with the range matched to the enemyHeroes range (30). It might actually make the AI more likely to flee when new enemy heroes enter that extended range, which I think is ok - it doesn't flee enough when truly outnumbered. If this makes it flee too much, then adjust the trigger percents (the version I have has them at .50 to .85 depending on the goal).

Depending on what you specifically removed when you made the 'no-flee' AI, this range separation may actually have something to do with why the AI gets stuck. Definitely match them up.

Quoting Plaguewraith,

reply 343

Is it possible to implement some code where a human player can tell the AI which build to get?

Possibly, but it would require a significant rewrite of the AI's build- and skill-choosing code, because right now this happens instantly upon AI initialization, not when the AI actually chats its build. Delaying the actual choice of build and initial skill(s) might be somewhat tricky, and the AI would not be able to do anything (including running the pre-shopping priority sensors) until it decided on a build, which would definitely delay the AI's startup.

I think it's a much better idea to simply remove any questionable builds or skills, especially if implementing a system like this is just going to lead everyone to order the same builds every time. If a build is sub-optimal, then improve it or get rid of it, don't force the player and AI to sit around for another few seconds just to make what amounts to a non-choice.

Quoting OMG_pacov,

reply 341

This should be as simple as adding a comparative WS check to the action's InstantStatusFunction, and returning false if WR/enemy WR are below 8 and there isn't a >400 negative difference in WS. You still probably want to keep them from buying locks at all prior to WR 4 via priority, though, so they don't waste 500 gold.

Something like:

Code: c++
        local enemyBrain = AIGlobals.GetEnemyTeamBrain(unit)
        local aiBrain = unit:GetAIBrain()
        if (enemyBrain.Score.WarRank < 8 and aiBrain.Score.WarRank < 8) or (enemyBrain.Score.WarScore - aiBrain.Score.WarScore < 300) then
            return false
        end

..replacing the existing 'local aibrain' at the top of that InstantStatusFunction. This should only allow them to use locks when either team is at WR 8 or the enemy team has 300 more WS.

Successfully updated karma reason!

pacov

Join Date 02/2008

+183

miri - thanks again for you time. I'll read your post in a bit, just want to add this:

I could use some help with 1 thing in particular... and sadly, I'm not 100% sure its "the problem," but all of my tests are leaning that way. Generals seem to assume that if they are attacking a demigod with minions, then they are attacking a demigod... and other demigods often assume that if they are attacking minions, they are attacking a demigod. This seems to cause some confusion. The ideal goal would be to always have minions and dg's attacking the same target. The issue seems to happen most often with sedna, but probably all generals. It also generally means that a dg will stay in the back row with full HP, etc, and just send their grunts to attack. For example, an enemy is on the exp flag on cata (mid of map). A sedna will walk up and then send just minions at the dg and stand safely by a tower. This usually doesn't happen exactly that way (as the intiial capture action takes them closer to the flag... if the sedna chooses to back off... then the behavior i described happens. This also happens close to 100% of the time if a full HP sedna is near a tower. She will stay back and send her minions to attack. Sadly, I haven't been able to track down what is causing this. Any thoughts?

Successfully updated karma reason!

pacov

Join Date 02/2008

+183

Quoting OMG_pacov,

reply 346

Depending on what you specifically removed when you made the 'no-flee' AI, this range separation may actually have something to do with why the AI gets stuck. Definitely match them up.

side note... please don't consider me serious with my no flee ai. There was no removing... I simply put the attack rule in front of the flee rules in the elseif chain... eg YOU MUST ATTACK IF ENEMY DGS ARE THERE before any checking on HP etc. A blatant override in that chain can force any particular objective 100% of the time... as long as you don't care if your dg dies. Though this override LARGELY solves the other weighted decisions (resulting in the stuck AI issue), I don't consider it practical (outside of maybe a conditional application of doing this if you are down in WS or something to that effect.

It was really just a testing ground to see if that "fixed" the stuck issue... and since then, I started toying with the logic to see if I could improve base logic any. For instance, conditional logic around whether or not to assassinate based on the number of enemies and allies present. This "kind of" existed through the myhealth % modifer, but I want to make it more concrete with explicit rules. Anyway, my tests have proven less than perfect. I can make it work where the AI will flee if low HP, but anytime I tack on a run if towers also command, it starts to go to piss. Anyway, as soon as I get inspired, I'll tackle this again.

MIRI - please confirm. I've been working with the understanding that the AI is SHITE for interrupts. So, when I "fix" an ability, I'm generally removing any interrupt check that currently exists and then SLIGHTLY bumping the desire to use that ability. This has been successful generally, but I wouldn't mind you agreeing that this approach is appropriate.

And last - I have another concern around the stuck ai issue (though I might be imagining it). It seems as if not all ai's have a check to determine if they can use an ability before it is called. For (hypothetical example - not sure if this one is real) example, ub doesn't care if he has no mana for spit. He will still try to use it. I've seen ai's standing around when oom before. I wonder if there is any tie to trying to use an ability even if its impossible. I'm leaning towards believing this is the root cause as immediately after they use an ability, I often see them start moving again. Might be a total fluke. Anyway, can you provide a block of code that just evaluates for the following - ABILITY IS READY. ENOUGH MANA FOR ABILITY. I can dig it out of the code, but I'd like your input if you have a minute. I'll be reusing this over and over, after all.

Successfully updated karma reason!

pacov

Join Date 02/2008

+183

edit - nvm - I sorted it.

Well - I have now have some pretty solid logic in place for DA to use his swap again. I'll probably enhance the logic further, but as it stands, right now he will only swap if he has 2 allies in the area. Tested and works. So, its just a matter of adding some other qualifiers and I think I can get this working pretty damn close to how it should be used... granted, it will never be 100% for interrupts, but its much better now.

Successfully updated karma reason!

pacov

Join Date 02/2008

+183

OK - finished developing my DA swap code. We have a lot flexibility on the parameters if we want to tweak it... and the AI seems very responsive to what I've coded so far. We can choose to swap based on the number of allies, number of enemies, or difference between the 2 of those numbers. Right now (eg what I'll release) is that DA will swap if there is at least 1 more ally than enemy near da (eg in a 1v1 da won't swap... in a 2v2, da won't swap... in a 1ai+da (2) v 1, da will swap). As long as there is 1 more dg there than the other team has, DA will consider swapping. Now, he still could go for point blank swaps, but again remember... this will ONLY happen if your team has more dgs in the area. So while its not brilliant, its much improved.

DA won't be trying to interrupt as that's not possible in the game code. But he will attempt to unload every ability he has access to and swap if there is a teammate nearby.

Anyway, the code I developed should be modular enough to use in many other places. So, I'll likely expand this a bit. Open to suggestions on da's tweaks once I release a version with it in it.

Successfully updated karma reason!

pacov

Join Date 02/2008

+183

OK - new release inbound in a bit. I'm very pleased with the changes with da. I think my next dg to sort is erb. He doesn't use bite anywhere near enough and still tries for int's with his stun. Anyway, with the new code developed, I think I can jump back to working on general ai priorities and start tackling the stuck AI nonsense again soon.

stand by...

Successfully updated karma reason!

pacov

Join Date 02/2008

+183

changelog
version 0.27.02 BETA
- major revamp to DA's swap ability - da will now only swap if the number of allies is > enemies near da
- disabled existing DA build
- enabled STANDARD_ASSASSIN da build (eg what most players use when playing da) now that swap is working as desired
- disabled pounce sedna build

live

OK - so pacov request - I REALLY need folks to test the shopping system I updated. I need to have feedback on whether or not the AI is shopping at the particular warscore or not. I like the changes and would happily add them to the standard build, but I really don't want to back out anything out because it wasn't tested sufficiently. If the AI doesn't shop when I say it will (see the last 3-4 change logs), please give me an explanation as to what is going on when it refuses to shop. I'm also VERY curious about any time the AI just stands at the shop for a long duration (long being > 10 sec).

And last - test the DA improvements and let me know if you think I should change this or that. Be VERY detailed if you want a change... eg I want to see da NOT swap if ____.... and da should have swapped if ____. I don't mind you telling me, but right now, only having da swap at max distance is not an option.

Hopefully we can get a few more folks than just plague doing a few tests over the next few days. Remember, the more interested you folks are, the more likely I'll keep cranking out content (and after erb, the next big focus is nonstop on trying to kill the stuck AI issue... which si the one thing that makes this mod POO). honestly, I wish I'd have been able to sort the stuck ai by now. Then all this stuff I'm working on would be gravy. Anyway, the changes I made with da are MUCH improved from what we had.... and what I learned while coding will make a big difference going forward.

The next thing I need to develop code for (looking at miri in case he feels inspired) is creating checks for AI HP so that I can force the dgs to pursue if very close for a kill. It literally took me like 3-4 hours tonight to learn how the syntax should work for what I was coding and develop some best practices for testing. That's not so good... but still.... pacov learns more lua and can create more good stuff quickly.

And last - miri - I'm completely willing to do the legwork if you can provide some info. Is there a way to make the changes in the AI action blueprints nondestructive? As it stands, its simply a hard copy of everything in the non modded files. Then abilites you don't want to change are commented out... and abilities you do want to change are updated. Is there any way to improve this that you can think of? Or is this as good as it gets?

Successfully updated karma reason!

Quoting OMG_pacov,

reply 346

Yes, this is fine. Like I said, the action / goal system does not update often enough to handle the <1s timing that interrupts require.

I don't know quite enough about goal choice to say for certain if it'd be possible to use an 0.5s ability use sensor to force an action execution, or at least a SelectGoal - I would assume that if not possible, it could be made possible with some minor restructuring. But that won't work so well while there are conditions within SelectGoal.

(Now that I think about it, you could probably use the sensor to tag a given demigod as casting an ability using a brain/goap class table with a timestamp, immediately fork a call of SelectGoal right from the sensor update function, make sure SelectGoal bypasses the rest of the conditional logic if the timestamp on the interrupt flag is up to date, make sure interrupt ability action CalculateWeights functions all look for and check the timestamp as well, jacking their GoalWeights way up and clearing the flag. Again, I still don't really know enough to say whether or not this would force those abilities 100% of the time, or that it would force them to target the casting enemy unless you also created a new AIAbilityUtilities function specifically to handle targeting for interrupt abilities.)

Quoting OMG_pacov,

reply 348

Now, he still could go for point blank swaps, but again remember... this will ONLY happen if your team has more dgs in the area. So while its not brilliant, its much improved.

Easily fixed by making sure the nearest enemy demigod is at least some minimum distance away. If there's a way to get the actual action target (which may be decided by the AIAbility function that actually casts it, I can't recall), then distance-check that for even better accuracy.

Quoting OMG_pacov,

reply 346

No. Look at the chain of functioncalls in AIAbilityUtilities - all of the cast/target functions go through both GetReadyAbility (which uses ValidateAbility.CanUseAbility, which checks mana cost among other things) and TestEnergy, while the status functions still use just GetReadyAbility. Any ability that whose mana cost it can't afford should be returning false immediately for both the status and action functions.

It's almost definitely something in the way the mod-added conditional goal logic is structured. You'd need to log / chat for every single conditional statement that passes to see which one(s) is coming up when the AI is stuck.

Successfully updated karma reason!