I would def. recommend removing Swap from all DA builds. The AI is always going to use it to put itself into stupid situations, unless you do tons of area checks at both the source and destination. The AI's mana is much, much better spent on Spine and Strike. Warp Area may need some additional conditions associated with it - right now its weight calculation function just checks whether or not there's any 'threat' in the immediate vicinity (point blank), but
[quote who="OMG_pacov" reply="242" id="2959204"]jtreads 100 6700 godplate 110 10000[/quote] This is a problem, as it means the AI will sell artifacts to get these. Try to keep your 'real' priority numbers below the level Peppe has owned artifacts set to (100). [quote who="OMG_pacov" reply="246" id="2959239"]- remved AI's desire to purchase any graveyard upgrades[/quote] Graveyard I is really effective for Nightmare AI teams, and is
And now you see the problem with assigning only one priority to each item, rather than using the (admittedly incomplete) built-in system that Peppe disabled which assigns each item health, mana, or damage weights. It's perfectly possible (likely, even) for an AI to end up never buying Vlemish, or selling Scaled Helm before buying it, or selling Vlemish for a non-mana item, because it doesn't understand that it needs at least one mana item. It would probably be best to us
Re: distribution, I'd recommend keeping the name separate. You have to keep the UID separate - that's true even between different versions of the mod. Re: Priority, like Darkliath said, you can't over-prioritize a cheap item or the AI will never sell it for a better item. This is true of conditional priorityfunctions as well. If you gave Nimoth 100 priority and all of the artifacts 50 priority, Nimoth would never be sold under any circumsta
[quote who="OMG_pacov" reply="211" id="2958386"]well... I've dropped the killhero weight quite a bit and I might give the weakhero suggestion a try... that said, I think something else might be at work here at the AI seems to target the hero unit with the lowest hp anyway (eg if 2 units are nearby and one with more hp is in front and there is another one behind, the AI will still beeline towards the one that is a little bit behind and only use abilities on them. Anyway, obviously shouldn&
One thing you might want to try is keeping the KillHero weight down on Grasp (like -5), and pumping WeakHeroNearbyAdd to -45 or so, saving most grasping until the target is low on health.
[quote who="OMG_pacov" reply="200" id="2958003"]OK miri - need to pick your brain. In trying to sort ub's grasp (eg he never used it before i started sorting it), I came across a problem. I can make him use the function just about every time its available (which is actually what I'm looking to do atm), but I'm having to force an error in the code to do this. Sounds bad, of course. If I do it "proper," I see a marginal improvement. If I don't, then I get the desired
[quote who="OMG_pacov" reply="178" id="2957080"]I'm thinking that I will ZERO out all of the priorities in AIGlobals[/quote] Do not do this. If you want to set them to low values, that's fine, but you want to make sure you have at least some priorities if nothing in the skill build is available. If anything, a better system might be adding the skill build amounts to AIGlobals amounts (adding to 0 if the item isn't in the AIGlobals list), so that when doing skil
Well, see, that's why I asked - if it's a sensor or action, commenting it out just means it'll use the version from the original file. If it's an override that peppe added somewhere in the goal code, then commenting it would probably disable it.
[quote who="OMG_pacov" reply="161" id="2956479"]- TEMPORARILY turned off the attack structure code[/quote] Removed an override somewhere, or actually nilled the attack structure action?
Whoops, I neglected to return the output of each hooked function. Here's a correction, that also logs what build mode the unit is registering: http://pastebin.com/JUT8dASF
[quote who="OMG_pacov" reply="156" id="2956353"] So the only variable is hoping that the AI, if its a fire build, changes to fire form. I'll do some testing.. hopefully the AI isn't too dense about that and jumps forms before too long. Otherwise, I'll just lock down the fire build and only allow ice... that is, unless you have an idea that would force the AI to jump to fire mode if it is a fire build at the start.[/quote] It should at least switch in combat, if not wheneve
It should always be able to switch into its proper form. The check would just stop it from switching back to ice if it's using a pure fire build. I think you misread what I said about the 3 second wait action. That is only used for the Flee MasterGoal. It has nothing to do with the delay before purchasing at the beginning, nor anything to do with the lack of delay after purchasing. That's why I said you need to find out what MasterGoal th
[quote who="OMG_pacov" reply="145" id="2955987"]Miri - I'm actually VERY pleased with the changes I've worked into the build I'll be releasing soon. Could you check into 2 bits of code for me? The tb thing I mentioned (if the build is ice, stay in ice form - if fire, stay in fire form - no hybrid build will be used here)[/quote] Try this - it goes at the end of HEMA01_AIActions.lua: http://pastebin.com/JUT8dASF Upon
Just replace Rank with Score, and adjust the amount appropriately? But I don't know why you'd need to modify the existing ones - they're probably fine where they are, I just added Score capability for FS1. Just shuffle the current indexes up, and add in FS1, e.g.:[code="c++"]SaveForUpgrades = { [1] = { Name = 'CBuildingHealth01', Score = 200 }, [2] = { Name = 'CGoldIncome01', Rank = 2 }, &
Use a WarScore check to force the AI back to shop just before War Rank 2. The WarScore levels for each War Rank should be in game.lua, if you don't have them memorized. Send the AI back <200 WS before WR2. Also, make sure that shopping condition only happens once, by setting e.g. unit.ShoppedForFS1 to true inside that goal condition, and adding a check to that condition for 'not unit.ShoppedForFS1' so it gets skipped once that AI has been told to shop once.&nb
Sorry, but I don't really have enough time to go through and answer every question or issue in this thread, so I'll just address what I remember: 1) Do not use WR1 in the SaveForUpgrades table. This forces the AI to save immediately, meaning it will only purchase cheap items. There is no reason to do this for FS1, as it's cheap enough that a simple Validate.CanPurchaseUpgrade check or a raw gold ch
I'll try to take a look at TB's mode switching when I can. I assume the best way to handle it would be to use the ActionFunction to determine which build it's using, and always return false for the other mode. How are you increasing cast rates of abilities? Lowering action WeightTimes?
No, the saving system does not directly affect priority. You need to insure that when the upgrades being saved for are available, that they're prioritized sufficiently. In a sense, the AI will be more likely to buy them anyway, because the save-for system (as before) will tell them they have more gold available when it's that particular upgrade they're considering, and if they only have enough gold for one upgrade, they'll get that one because the saving system wil
I didn't change much, functionally, other than significantly reducing unnecessary sim load and preventing the AI from saving for too many things at once. It still only saves for Cur1 and the four creep upgrades, starting at WR2 for Cur1, and WR6/Enemy WR7 for priests and angels. It's all in a table that you can clearly look at and edit now (SaveForUpgrades), instead of being stuck in a convoluted conditional mess with 10+ branches that was forcing them to save too much gol
I went ahead and pastebinned the full files for AIGlobals and AIShopUtilities, so there's no ambiguity when pasting them in. Just overwrite everything that's there. And any work I do on this mod will probably be in response to a problem you're running into, like the last two things. I don't really have the motivation to play it a bunch and evaluate behavioral problems on my own, but I'm happy to help with code when you've isolated an issue.
Oh whoops, I missed an AIGlobals function in that pastebin (GetGoldRank). Added that. Full AIGlobals.lua: http://pastebin.com/5YYKWnau Full AIShopUtilities.lua: http://pastebin.com/Esn55ysp
That's AIAbilityUtilities, which I made (so I obviously have the contents of that). I need AIShopUtilities. Edit: I just noticed you posted .41. If you haven't made any changes to that file since then, I'll just use that.
Oh, I just realized you've probably made changes to those two AIShopUtilities functions, and that the copies I gave you might erase some of those (isn't destructive modding great?). If you don't want to pick out the changes I made, pastebin an updated copy of your AIShopUtilities.lua and I'll handle integrating the changes.
Yes, I tested both the summon code and the gold save code in-game. I explained in my post what the error was, and why it was occurring. I also ran the game long enough to see the AI actually save for and purchase Currency I, and to acquire the Priests save-for at WR 6. Feel free to tweak the WR levels that I have set in the SaveForUpgrades table, just don't pile too many upgrades onto any one WR / enemy WR level, because each AI will only save for one upgrade at a time
Demigod Forums