Scan area function added back to capture function.  Should break capture action on encountering enemies.

Changed FS1 requirement from > 300 war score to > 100 war score.  Should go to an ai on its first trip back to base.

Set currency to 500 priority.  Not sure if that will help, but if an AI is shopping that is bound to be the highest item

http://www.filefront.com/17562656/Skirmish_AI_v25h.zip

http://www.filefront.com/17562666/Skirmish_AI_v25h.exe

This is my last test for the night - but I'll review your test items tomorrow peppe.

AI skirmish (mod version) .25g/uberfix 1.03RC4

Settings:  Levi/High Towers - all other settings on default
AI settings:  normal

rook (human)/ub/da/tb v ub (human)/ub/da/tb

Observed results:

huge problems.  the tb and ub on my team, after about 3 minutes, went back to my crystal.  They stat there a LONG time.  the tb started moving again after 4 min.  ub after 6-7 min

Ai - bought no upgrades for me early

At one point, the tb on my team was being chased down - i had a da nearby that could have assisted, but he did nothing.

ub froze at my citadel for about 2 minutes again.

Suggest you make your coding changes and make a quick test on cata and then on levi.  Levi was way off.  Cata wasn't too shabby.

I'll be able to test again around 6PM EST tomorrow.  I see you posted version 25h - if you add any fixes, I'll just use the latest version.  Thanks!

edit - and fyi, IN1 has been very helpful to me by assisting me with testing. 

Thanks for the testing Pacov.  I don't have the time to make changes and play full games against it, so it helps a great deal. 

Sorry if we took a couple steps back before going forward.   I'll run some cycles to see how its playing and if I can get any stuck demigods.   I think G had some errors in the flag function that might outright kill until the portal were recaptured, should be fixed in h. 

If you see stuck demigods again save the log after the game and upload it and i'll take a look.

The game log should be in: C:\Users\USERNAME\Documents\My Games\Gas Powered Games\Demigod\DemigodLog.txt

I'll see what else I can tackle tonight and make a release. 

Another thought - we will be submitting several mods for inclusion in the next demigod release (which isn't guaranteed to happen, yet, but I can guarantee that GPG will be aware of the changes we request).  I'd VERY much like to include the AI Skirmish mod (if you'd like to rebrand the mod and come up with another name, now's as good a time as any - mayhaps the AI Enhancement Mod or whatever - or leave it the same if you like).  That said, the mod as is can't be included as it needs to be much more reliable (in my last levi game, for instance, the ai was actually worse than the vanilla ai).  Anyway, if you could focus on ironing out the really bad things (ai's sitting still for 6 minutes) and then focus on tweaks and enhancements after that, we can probably submit this for inclusion (which I really would like to do and I think all of the SP folks out there would enjoy this).  Also, I know you've modded the lobby in your "non-mod" version of this.  We can probably submit those lobby changes to gpg for inclusion, but we'll have to discuss that later. 

I will start generating log files for each game going forward if that helps and I'll note the specific times that things start going nuts. 

Sounds good.  I don't really care what the name is, so if you think another name will have better success being included in the game that would be fine with me. 

I introduced some instability deleting and rewriting the capture actions from scratch.  I think the stuck demigods in the version you tested were directly from that function.  I have cleaned it up and it should be stable now.   Normally i would have caught this before releasing a sub version for testing here, but did not have any test time today.

If we take the next sub version and find the gameplay and overall AI play good we can test it thoroughly and call it a 1.00 release for inclusion in the game.   Are they talking about just distributing it as a mod to everyone with the game?  Or replacing the game files to make it a part of the game?

Version 25i:

http://www.filefront.com/17563334/Skirmish_AI_v25i.exe

http://www.filefront.com/17563346/Skirmish_AI_v25i.zip

Capture flag, shopping for items and upgrades, all appear to be good.

Found and fixed bug in shopping routine on maps with the health stone far away from the shop the AI's would purchase an item -> move to health stone -> move back to shop to purchase next item -> back to health -> etc...   Confirmed in normal AI.  Fixed in 'Move To Health Statue' action by removing purchase items as a goalset for that action.  So AI's will shop without doing the roundtrips.

While I was in there I set the retreat to health status to be active at 50% health.  Anything below 50% and it will continue to retreat to the health stone.  If its health goes above that it will move to a friendly place until it feels safe enough to attack.   Once it gets to 100% health it will pick up one of the override goals and most likely capture flags.  This change seems to increase time in field and reduce shopping trips (each trip to the healthstone turns into a shopping trip).   If we find the AI too easy to kill for a play this is an easy spot to modify how quick the AI retreats. 

Increased the portal threat detection range slightly from 1.5 to 1.8.  Prior to this the AI's would often detect the threat, but not get the TP off in time.  Now they detect and arrive in time without being overly sensitive.

Discovered AI's on maps where the citadel is not near the healthstone/shop area go into find best equipment item function first.  No matter how high the citadel upgrade is they will select the best equipment item and after spending their cash they check for citadel upgrades.   I added a check into the find best item function to call the find best upgrade function and compare the priorities.  If the citadel is higher it prevents an item purchase and gets the AI on track to buying the upgrade.

Added back an active scanning function that breaks from capture action once enemies/towers are detected in area.

Test item fixes:

Are there any maps where the physical portal is far away from the flag?  It was easier to get a list of physical portals than to loop over the flags and find the portal flags, so that part will actually send them to the portal rather than the flag near it, but finding the flag nearest a given portal shouldn't be too much effort if it is an issue on certain maps.

-Yes several maps have portals away from flags.  Function updated to find the nearest portal and then the nearest flag from that portal.

For this version i have the action set to 40 seconds.  If the AI does not make it to the original flag selected in that time the function will run again and it may select a different flag based on the units current position.   We may need a distance check on the closest flag and make sure we don't re-pick to the second closest flag when we are close to another flag.  

-No issues with 40 seconds.    Added distance check for closest flag, so it will not use the random selection if a capture flag is close.

Need to run some games to test artifact shopping.  I think it will run to the health stone, shop locally, then if the team owns the artifact shop it will continue and shop for artifacts.   Shopping could also come up as the master goal through the default goal picker anytime the demigod is less than full health (override action at full health), so artifacts may get purchases this way naturally.  The weight for this is controlled by a sensor that checks item priority (very high for artifacts, 100+) and distance to shop.

-When injured the AI is left to make its own goal choice and will artifact shop if it has the money and the shop is available.  It will also shop for artifacts after retreating to the health stone or entering the normal shopping area.

To Do:

Re-balance upgrade priorities in AIglobals.lua.  Need critical upgrades that should be bought above any item (FS1, Currency 1, others?).  For non critical upgrades I was thinking a nice formula to use would be to set a base priority a little below most items, so it would shop for itself first but multiply the base priority by the number of kills + assists.  So a demigod with kills will prioritize upgrades more than items for itself.

If the AI wasn't stuck due to a loggable error i think i found something that might cause it to loop buying items at  the shop.  It would only happen late game with town portals and capture locks as its consumables.  The capture lock and town portal priorities were changed in.23 or .24.  Priorities on consumables is tricky.  

On consumables the priorities have to be balanced tightly to prevent the AI buying and selling them back over and over.   Like buying a town portal at 30 priority, but once you have one dropping its priority to something low.   If you have another consumable with the same pattern (capture lock).   Then you can get into a loop where it sells a tp scroll cause it has two and values them at 10 or something to afford a capture lock @30.  But once it owns a capture lock it values it at @10 and the townportal scroll jumps back up to 30.  It could buy/sell those back and forth until its out of cash.

Re-balancing the rest of the citadel upgrades and we'll see how this tests out.  Other than critical ones or situational ones (react to enemy getting x upgrade) I am setting most priories to 35.   Nimoth, Hauberk of Life, and Vlemish are higher than that.    

Also played around with the retreat to health stone a little more.  It now has a scaling weight, so the action won't have a chance to be called until the AI is down to 70%.  I will watch a few games to dial it in, but it will be something like this to decide the weight of the action:

Version J changes:

Rebalanced Citadel upgrades, so some items are selected before the upgrades.  Should allow normal or poor ai's to fill some inventory slots before helping with team upgrades.

AI's kept finding sigil, teleport, and capture lock as their lowest item and selling/re-buying them oddly.  Blocked selling those items.

Put an an extra check to block selling items when we have open slots.  Put in a warning message to log every sell.  Will probably leave it in for a bit to make sure it is selling wisely. 

I put in a check to block experience 1 until currency 1 is purchased.   In many games i saw the AI buy this in warrank 2 and then be 1200 or a less short for currency at 3. 

Increased scan range for aborting flag capture.  Default used by base AI is 16 (in these units towers can shoot 15 i think).  Bumped to 20 in testing, think 24 might be best.  Leviathan's valor flags are a good test for this.  The AI can run the inside edge to get to it, but its often a suicide run. 

Put unbreakable boots in a priority function.  At start of game its valued above plenor, but after 20 seconds its valued below.  Result is the boots are purchased above plenor at the start, but end game the boots are replaced before plenor is.  For most AI's boots/plenor are never replaced until artifacts anyway.

A thought on currency,  If currency is super critical we can force the AI to reserve 1800 when shopping in war rank 1 and 2 or in a war score range cut off buying.  Then all of them will have the cash for it when war rank 3 starts.

Things to look for:

Does the AI retreat to its health statue at good times?  Does it get scared and run too soon or too late? 

Stuck AI's.  If it is rich it can shop for a while, but if its in a sell/buy loop trading items it could be an issue.  

Anything else that catches your eye.

I'll let a final test game finish and upload the new version ~20 minutes.

good stuff - can start testing sometime soon.

J is up:

http://www.filefront.com/17565805/Skirmish_AI_v25j.exe

http://www.filefront.com/17565807/Skirmish_AI_v25j.zip

Got one stuck AI in the latest test game.  Not sure what it was doing.  Watched the replay and it was just going to the health stone and didn't pick an action after that for a couple minutes.   It acted like the shopping too quickly freeze, but it never even shopped. 

Going to see if adding some wait times to the move to health stone action helps.

AI skirmish (mod version) .25j/uberfix 1.03RC4

Settings:  Cataract/High Towers - all other settings on default
AI settings:  normal

rook (human)/ub/da/ v rook/ub/da

Observed results:

quick thought - have the ai say what character it announces its build.  No idea which dg on my team is ENDEL, so seeing UB-Ooze-Bots, etc would be much more useful.

ai bought fs1 at 1:30 sec (good).

problem - ai still obsessed with trying to get valor early (walking into many towers to do so).  Tried to get valor at 8min in.  Even if the towers weren't on high, this is MUCH too aggressive behavior. 

The ai needs to SAVE its money for currency after the initial shop.  I would literally not allow the ai to buy anything but upgrades after the initial shop.

only upgrade the ai has bought is fs1 at 11 minutes in.

I bought cur1 at 14 min in after i was sure the ai would not.

17 min in the ai bought xp1

Ai did not respond when I took its portal, though all 3 were alive.  AI did try to retake the flag quickly enough, though, but didn't try to tp in.

Late game the ai started purchasing things for the citadel again regularly.

http://www.filefront.com/17567095/Skirmish_AI_v25k.exe

http://www.filefront.com/17567097/Skirmish_AI_v25k.zip

Added class to build announcement.

At warscore two the AI will hold 1800 gold aside.  The first AI on a team to shop in warscore 3 should be currency.   The primary trigger for shopping is walking near the shop (usually on the way to or at the health stone).

Getting closer...

Atta boy, peppe.  Was waiting on you to release another version before I tested again.  Thanks for cranking another 1 out.  Will test tonight if possible.

oh - and if I gloss over something you want me to test, please just spam what you want me to test again.  I review your notes, but I focus on stable, reliable combat and ignore what you want me to test sometimes if I catch something that sicks out to me.  I'd prefer to make sure you are getting what you need when I test, so SPAM away on me if I miss something you want tested (eg, after I post results, if you don't see what you are looking for, spam what you want).

L released.

http://www.filefront.com/17568765/Skirmish_AI_v25l.exe

http://www.filefront.com/17568766/Skirmish_AI_v25L.zip

Found out there was a bug in the force shopping at war rank 3.  Updated that and now they drop everything and go shop at war rank 3, and every one of them has 1800 they saved in war rank 2, so they can all buy currency.  It may be map dependent, but on leviathan they purchase items for themselves first, but I kept the 1800 reserve on item purchases until currency is purchased, so it will go quickly.

Other upgrades will be slower than that, but the AI is still pretty reliable on upgrading everything.  Most upgrades are balanced against items, so the AI may buy items over upgrades for anything but currency.

Probably need to test each map for consistency I am pretty happy with leviathan and only ran a couple minutes on cataract.  I test mostly on leviathan now as that is one of the more challenging maps for the AI to shop on.  It also has a safe path to a the very dangerous valor flag.  If i can get it to be less suicidal on that flag then things should be good. 

Not really concerned with anything now.  I think i found why it was getting stuck midgame and adjusted the overrides.  I originally had it buy until it had nothing else it could buy (this ensured it went and bought citadel upgrades no matter how far away it was from the current shopping location), but apparently that is not reliable and occasionally would return true that it had stuff to buy when it had nothing left.  Instead of continuing to shop when it thought  it had items to buy i now let the built in goal function decide if it should continue or not.   Passing by the health statue, stronghold, or shop will trigger the start of a shopping trip, but the default function may not continue it to its fullest.

Do you know if the rook changes in Uberfix, fix his stutter step issue when trying to retreat?  I think I saw you guys fixed fire on the move for him?  I fixed a stutter step retreat in my mod by basically quartering the attack speed of his archers and multiplying the damage to compensate.  Wondering if i can drop that file from the mod now.

Thinking on the valor flag suicide risk i might expand the flag selection function to inspect the tower threat around the 3 closest flags and select the flag with the lowest threat.   Rather than select the randomly between the 2 closest flags.

Version M:

http://www.filefront.com/17569022/Skirmish_AI_v25m.exe

http://www.filefront.com/17569023/Skirmish_AI_v25m.zip

May be time for a new major version ;P   With these changes really nothing bugging too much about the AI.

Capture action expanded.  AI scans 4 closest flags.  Sorts them by tower/structure threat.  And randomly selects from the flags with the lowest threat (if there is a tie).

'Attack structures' action changed to be counted as a capture action as well.  Gave it a lower weight on 'capture' category than capture flags, but this change should basically result in pressure on towers/structures rather than purely on flags.   Give the AI a second best choice when all the remaining flags are protected by towers.

Quick test results summary 

AI skirmish (mod version) .25m/uberfix 1.03RC4

Settings:  Cataract/High Towers - all other settings on default
AI settings:  normal

sedna(human)/ub/da/ v sedna/ub/da

Observed results:

Wow, that's much more like it! The AI doesn't get obsessively suicidal over that Valor flag anymore. No "stuck at base" phenomena observed, either. The upgrades are mostly okay (at least, the AI did buy FS1 and Cur1 ASAP). However, in this respect I think too much weight is allocated to Exp upgrades. The AI bought Exp1 during the first few minutes, and, while it never ever bothered with Cur2, it opted to invest in Exp2 at War Rank 5.

The AI is still very bad at coordinated ganking, but it was never his forte in the first place. One issue I'd like to address is minion management for generals. Can something be done in this respect? Sedna doesn't share monks (of course, neither does vanilla AI) and her choice of investing in advanced minotaur minions while leaving monks as is (i. e. not upgrading to clerics, high priests or bishops) is totally idiotic.  So the primary issues are monk sharing and minion priorities (should clearly be Monks>Demolishers>Minotaurs, very few situations will dictate otherwise).

Thanks for the testing IN1. 

Re balancing what it shops for is super easy.  The AI doesn't have a sense of saving its money to afford something, so if it is shopping and only has 2400 left it will buy the highest priority item it can afford. 

If there is an upgrade order we want to force I can make a custom dependency to enforce that.  So it doesn't spend its 2400 gold on exp II when currency II is available.   If it has 3000 gold we can set the priority so currency is higher and always selected above the other available upgrades.  

Minions are the same way.  I haven't tested on normal, so the priorities of monks may need to changed to get them purchased above items in the initial round.  If every general should start with them? 

If any minion levels are just worthless we should drop them to 0 priority, so they never buy them.   I set the first 3 levels of healers to the same priority, which prevents the AI from upgrading to those if it owns any one of them.  Bishops are set higher, so they can upgrade to them from any of the first 3 healthers.   I thought it might be wasteful for the AI to trade up to the next healer vs save for bishops. But if any healer upgrade is a useful one we can do that.

Minotaurs and Demolishers currently have the same priority as each other and scaled to be lower than all the healers.  I can rebalanced their priorities against each other.  No matter what though if the AI has spent all its money down and has 350 leftover it may get minotaur I if they are above 0 priority.

I was looking at the monion AI just last night.  I wanted to get its follow circle smaller.  I will take a look if I can send one healer off to guard someone else.  How should it select who to send a healer to?  Random assassin on its team?

Actually, it is a bit more complicated. For Sedna (and Sedna only) the priority of Monk, Cleric, High Priest, Bishop minions should be set in strictly ascending order. Provided we'll get the monk sharing routine implemented: in games where both Sedna and another general are present, Healing Wind II mechanics dictate Sedna should ideally get only High Priests (not Bishops!), while the other general should get Bishops. Overall, where 2 generals are present, they should have different types of Monk-like minions and share to have one of each type at their disposal, to make healing timers pulsate independently (= double monk heal frequency).

In a situation where it's general + assassin, yes, it makes sense to share the monk with the assassin.

With regards to the splitting monks/bish/etc, thing, perhaps you can simplify, though I'm not sure how this will translate into coding. If a user has 2 monks, send 1 to any other demigod and attach it directly.

As far as logic for purchasing goes, if you want to get very specific:

if there is 1 general on a team, then that general buys monks at the start.

If there are 2 generals on a team, then 1 general buys monks and the other waits and buys clerics (unless it can already afford)

If there are 3 generals on a team, then 1 general buys monks, the other waits and buys clerics, the 3rd buys high priest/bishop.

In some circumstances, though, in a 4v4, with at least 2 generals, its advantageous to have both generals buy monks at the start, but them upgrade when possible.

The maximum benefit from healers comes by stacking different healers together. 

Here is how I would prioritize a few of the upgrades:

1. Fs1
2. Currency (war rank 3)
3. XP1 (war rank 2)

FS1 should be bought as soon as possible after the initial shop (I think the logic you have built in works great for this (at least on the last version I tested)). 

While XP1 can be purchased at war rank 2, its not as important as currency 1.  If what I've read about some of the logic changes you've made, then prioritizing currency 1 and then xp1 right after that should work well - especially if the AI is conserving gold now after the initial shop. 

In MP games, its not always important to pick up XP1 and getting it sometimes is situational, but I think the AI always picking it up at some point would be good. 

Sedna has 3 builds  Healing wind is selected at 2 and 5 on two of the builds and the third gets it at 8,9.

I can do build specific weights to zero out bishops or any item as needed.  Unless the no bishops is more situational then we will probably just want what is best most of the time.

I'll take a look at inspecting what other generals on the team own and see if i can adjust priorities based on that. 

I wrote a function already to split healers on summon.  Right now it is set to send one to a randomly selected ally assassin, but i can drop the assassin check and send it to any random teammate. The AI never interacts with the minion again after they summon, so there won't be any active management, but it is a start. 

Sounds like a good start to me.  Thanks.

Making the AI handle healers like players do is probably going to be somewhat difficult.  It might get it right the first time it leaves base with Monks, but having it decide when to split them (i.e. to not split them off when it's being wailed on, is resummoning its dead healers, and its ally is nowhere nearby) and which other general to mutually share them with is probably a more complex change than the mod needs right at this moment, given that Nightmare AIs will already have a fairly significant healer advantage in the form of being able to buy high priests or bishops (or monks along with a full set of starter equipment) right out the door.

Edit: I see you're already handing them out to assassins.  That's ok, but make sure you check being damaged / demigod health when deciding whether or not to split the healers off.  AI summon healers in combat often, and having them send one away when they desperately need it isn't going to help AI difficulty much at all.

Let's focus on the basics until they're really, really solid, and then start adding in advanced tactics.  Something like group ganking near a friendly tower would probably be much easier to implement than healer sharing, anyway, so starting with that would be a much better idea.

I haven't had time to test this out yet, but it sounds like you've made strides with the early citadel upgrade priorities vs item priorities, and in deciding which flag to capture, both of which are a big deal.

I did quickly browse some of the updated code (that I'm aware of), and noticed a few things:

1) Capture actions are looking at both flags and portals and checking distances to find out which flags go with which portals - this is unnecessary, as flags automatically set a FlagUnit class variable on any unit that they own.  This means you can just use captureFlags[1].FlagUnit to get a definitive handle to that portal's flag, no matter how far it is from the portal.

2) There seem to be two copies of all of the AIGlobals citadel upgrade utility functions, one at the top, and one just above the cit upgrades.  Harmless, but it had me confused for a second.

Had a few thoughts on retreating as well (which file are the retreat actions in? I can't find them):

1) If the AI in question is extremely far away from base, and has a teleport scroll, and has enough health to absorb 3 seconds of damage (in theory; I think there are already functions that estimate this?), it should really, really be teleporting out instead of trying to run back to base.  The early running creates waaaaaaay too many easy kills for UB and DA.  I imagine it should be possible to make it decide this based on (at least) distance to the health stone, if not other factors like incoming damage rate.   Edit: Also consider distance to friendly towers, and when close enough, re-engage.  I think it already does this, but other times it runs straight down an open lane instead of heading to the nearest tower.

2) In keeping with this, does the AI look at enemy demigod health and/or evaluate its health loss against enemy demigod health loss when deciding to retreat?  And do potions in inventory affect its decision?  What about remaining mana and cooldowns?  I've had the .24 AI run from me many, many times when it probably could have won the fight, and definitely could have won the fight with one potion use (even small) or one more ability.  Combined with the problem mentioned above, it creates easy kills that the AI shouldn't be giving up.