really like this mod it brings a whole more to single player.

You mind if i add it to my mod? I will give you full credit for it.

This mod? [Mod] FavorMod - V1.7 22/01/2010

Probably the only reason to make it part of your mod is if you plan to modify my AI to use your new items?  Otherwise people can just enable both mods and they should run fine together.

You or anyone, feel free to merge it with any other mods or mod collections.   My updates have obviously slowed down as the remaining changes that would improve the AI generally take longer to develop and longer to test.

Just had a play a bit with this mod as I hadn't checked on Demigod modding before and I'm really impressed, it's way more challenging (read fun), even on normal difficulty they are better than what they used to be like on Hard when they were cheating!

Hey Peppe --

Did some additional playtesting with 1.9 tonight.  Things are really coming along - several of the builds are excellent at this point.

My major quibbles, still, with AI behavior are the following:

1.  The AI's are still suiciding themselves periodically on enemy towers. Just really idiotic behavior with no purpose.

2.  The Ai's don't prioritize capping portal flags, or even recapturing their own portal flag, nearly enough.  That should be their 1st priority:  as in, tele over there and recapture as soon as possible.

3.  I think they're returning to base a little too often for my taste, but this may be hard to tweak at this point.

Hope this helps.

-- Severian

Noticed something bad...

Sigil should not be fired if mark of the betryer is on and it will kill them.

Of course this is something in general (don't kill yourself with MoTB) but Sigil seems to be the one with the most problems since the AI wants to use it when it has low life.

Been a couple of AIs suiciding themselves and blowing the sigil at the same time.

Nobody worked out how to fix Rooks bad retreating?  He looks like he has a broken leg the way he keeps stopping and starting.

I will take a look at the stuff above when i get a chance.  Not using sigil with betrayer on should be easy.  

The other stuff is hard to track down/control, but i can keep tweaking.

I believe i tested rook in the vanilla AI and he did the same thing, so i didn't dig deeper at the time.  I thought it had something to do with his ranged attacks.

That's a huge problem, but I have only seen it affect AI Rooks (human-played Rooks retreat fine).  Peppe's mod is already excellent, but if he could fix this issue that would be a tremendous benefit to Rook's survivability in single player.

P.S. Peppe, I noticed that you recently included an Erebus build that includes Mist.  That's fine for variety's sake, but I wonder if it is truly an effective use of skill points for the AI (doesn't seem so).

I put the mist build in as a mist/charm build to play around with interupts.   If anyone has a viable charm build I would be happy to swap out the mist/charm build.   The other build is full minion if i recall.  

With the interupts in I am pretty happy with the way it plays at the moment.   Overall its decisions are not always great, but I find it a lot more interesting to play against than the base AI.

Hopefully get some free weekends coming up to work on this... if I don't burn out on coding first (RL dayjob).

Rook retreats fine without the Archer's on his shoulder, so must be something with the archer AI.

Played around more with rook.

Looked into his shoulder archer tower.  It is 12 arrow shooters with a fire rate of 2.   His hammer has a fire rate of .58 for reference (lower = slower).     Reducing the arrow fire rate seemed to have a positive impact on his ability to retreat.

I am testing values now, but it needs a lot of gametime watching.  Watching the opening 5-10 minutes.

The lowest i tested was .25 I pretty sure I saw no retreat interuptions.  

.5 had some failed retreats

.4 is looking good.   Might have seen a stutter step or two, but most of the retreats were clean.

I am wondering if targeting and firing all 12 of the weapons ends up reaching some max action limit for the AI, so it starts removing actions (like the retreat action).  

I might do a release at .4 and see what people think.

There is a slight gameplay change though, as the arrow damage has to be upped to maintain DPS.   Instead of a constant barrage it is now arrows on for about a second, then off for 1-2 then on, etc.

Original values: 6 of the archers do 5 damage and the other 6 do 7 damage. 

If my math is right: changing the Rate of fire to .4 the archers damages should be multiplied by 5 (2/.4 = 5).   6x25 and 6x35 = 395 damage a volley, fired a little slower than he can swing the hammer.

.20 Changes: 2/03/2010

Rook arrow tower firing rate dropped and damage increased in attempt to improve the AI Rook retreating stutter-step issue.

Hmm, that is weird.

And why this happens only with the AI rook, and not when a human plays rook?

p.s. thx for continuing to release new updates and improving your mod.

I've never coded LUA, so there could be something deeper  I am missing as the syntax is not yet second hand to me and I only dug a few layers.

My thought of the issue being cuased by action overload from performing what I believe is 24 actions a second (from just arrows, should also be doing a lot of other actions) is just a SWAG.  Humans wouldn't be subject to this becuase the AI isn't running to override a human move command.   If there is some cap somewhere like AI's can only perform 30 actions a frame or some action depth limit then that could be the root cuase.

It could also be the Rook AI thinks he is ok after X number attacks without a retailiation,  but i don't recall the move to safe location action or move to health statues action doing any kind of ongoing damage checks.   They basically find an end point and run a safe path function that returns a list of points to travel, and then it loops over that list until it gets to the final spot.   I don't believe there is a way to protect an action, so if enough other actions cue up I think the AI sacrifices the old action to do the newer ones and the arrows fire so quick that other actions may only get a few frames to excute.

Incidently i ran anouther test to see what would happen, and disabling all but one tower and setting it to fire 24 times a second cuases a a noticable retreat stutter step.  Disabling 11 towers and running one at the default of 2 cuases a stutter (less pronounced, but every arrow fire cuases him to stutter).  

Looking at other demigods, every other DG has just a single weapon.   The highest rate of fire is .74.   Expanding to all items with Rate of Fire the highest value is 2.0 for imobile towers.  I don't see any movable objects with a higher rate of fire than .74 (only rook with his tower)

Other issues could be Rate of Fire over 1 is not handled by the AI weapon functions well.  I tried to look at these, but it all looked pretty generic to me.   Maybe the attack functions for demigods doesn't handle having multiple attacks well.

Whoa! That is really impressive Peppe, I think you might know more than GPG coders, he he

I think it may have something to do with the way the archer towers are coded (they are a ranged weapon and not an active ability, so when archer towers shoot they are the equivalent of performing an auto attack). There are 12 of them on rook (note that the bug gets works as he increases levels - probably due to more of the archer towers being activated.

Has anyone dropped the number of archers down to 1 and increased the firing rate to compensate for the addition of extra towers?

Exxcentric,  see my posts above, but after narrowing it down to the shoulder mounted archer towes i have tried many varitions to trouble shoot.   I am fairly sure i did Rate of fire = 1 for a single tower and all other towers 0 (they fire once, but don't reload until death).

The file to play around with this is now in the mod, Hrook_unit.bp  (mod folder\hook\units\units\heroes\hrook\Hrook_unit.bp).  I looked at sorians fire on the move fix for TB (needs the two lines at the top to merge/override the original settings).   I started out applying his fire on the move fix to the rook arrow weapons, but had no affect.  If it was a fire on the move issue it would affect plays too, but worth a shot.

Line 599 begins the Rook's weapon section:     "Weapon = { ..."

You can find the arrows by searching for "DamageType = 'Arrow',"   Or "Label = 'Arrow01'," "Label = 'Arrow02'," .... up to Arrow12.

My modded values for arrows are:

"RateOfFire = .40,"

"Damage = 25,"  Arrows 1-6

"Damage = 35,"  7-12

"TargetCheckInterval = .75,"  all arrows, reduced from 1.1.  No noticable impact, but reduced to a more common value.  Most primary weapons on other demigods have a .2 value, while minions and rook secondary weapons have 1 or higher vallues.  I Figure .75 is still often and may cuase less actions per frame or second.

Interestingly Erebus has check for target of 1 on his weapon (every other DG primary wep is .2).   If poeple notice he engages better/faster maybe all demigod's primary weapons should be upped to check for target = 1.  I never noticed a difference, but there may not be one unless you know what to look for.   If the interval is like rate of fire then .2 would maybe 1.5-2 seconds.

Thanks.  Would nice to get some time with the original developer of this code or his/her documentation.  You can look at it and figure out what is going on in each piece, but some comments on the bigger picture would save trial and error. 

Think i would rather code for games than my day job of coding databases and web applications.   Frogboy, if you read this thread and Gas Powered Games doesn't give you the suport you need PM job offer(s)

If I'm not mistaken TargetCheckInterval is the amount of time between weapon target checks (either in ticks or seconds). So a TargetCheckInterval = .75 would be every 750 ms (or 75% of a tick which I forget is how long). There is also AlwaysRecheckTarget which forces a target check every TargetCheckInterval. However, I'm not sure that these are implimented correctly, altering them doesn't seem to have a reliable effect on unit performance.

I browsed around the Rook's weapons when I was trying to find a fix for his shoulder weapons targetting problems. I never found a real solution unfortunately.

One thought that occured to me is that the Arrows might be having range issues. Does the stutter step happen even when the target the arrows is firing at is very close to the rook? The test you ran where you limited the arrows to a single arrow suggests that it isn't a problem with command stacking, but it may be a range limitation or a firing problem. The problem also only occurs when the rook is retreating, right?

With default setting rook will stutter heavily at the edge of his range, but also stutter steps the entire retreat (from his melee range out to the archer range).   He will also sometimes stutter for a while and re-engage in battle if something is near enough even when he is well below a safe health level.   The stutter can also stop him completley where even if he can retreat he will stand still for long period of time waiting to die.  Very rarely waking up and contining to run if he is attacked without being killed (usually his health is too low and he dies in one volley from enemy DG skills+weapon).

Does 'FiringTolerance = 2,' have anything to do with firing just at the edge or out of range?

The current settings in version .20 have him shoot all arrows less often (.4) and seems to have relieved the issue.  Interestingly his other weapons from skills are not built on him in the same as the archer tower.  The treb and his light tower are not 'weapons' in his unit blueprint.

FiringTolerance = 'n', <How much misalignment can the barrel be before starting to fire. Used when you are trying to target ammo that does not require lots of accuracy due to the size of their damage radius or because the ammo does automatic targetting>

As a good reference for fields that the Moho Mod engine uses, I use the Supreme Commander Lua wikis. The best one I've found is: http://supcom.wikia.com/wiki/Blueprint.

Looking good, peppe.  I hate what you did with .19 as oak keeps interrupting me :)  Glad to see your still working on this mod.  Good stuff!

Oh - and a comment on .20:  the AI still seems to prioritze recapturing portals at a low rate.  I was playing a 2 human v 5 ai game recently and the ai did not really try to retake its portals or not enough ai did anyway.  I had taken both enemy ports on cata and held them without making an appearance for 3-4 min.  This was reasonably late game.  I'm just not sure if there's a value you can tweak so that the ai might be a little more protective of the portals. 

Anyway, what you've done to date is so much better than the original AI coding.

Good to see you back in the thread pacov.   .20 just had the rook changes in it.  Yeah, the interupt stuff can get nasty...  Again i think UB is rising to the top.  Simple build for the AI to play and instant interupt... just brutal.

Related to interupt.  Does anyone know what skills cannot be repeated (game shows 'immune!' in green when skill is used)?   When testing rook I just had 4 of him vs 4 of random AI's and saw enemies are immune to boulder roll for a time after getting rolled by any rook.  I should be able to check for this immune status and not use the skill, but wonder how many other skills this affects.

I'll see if i can amp up flag priority. Actually think its the flag search that needs some logic written for it.  My earlier changes basically just extended the range the original AI searched for flags.   Original setting i would say is maybe the distance between the middle flags on cata to the next nearest flag.  I doubled that, so it should see flags pretty well in one lane, but it is still a dumb search in the end.

I think i may try to max it out the range it looks to just find all capturable flags on the map and then sort them in some useful way.

For those interested the files doing stuff:

MasterGoals.Lua : CapturePoint template :line 274

 local flags = unit:GetAIBrain():GetUnitsAroundPoint( categories.FLAG, unit.Position, 64 )  #default was 32

Basically a dumb function that looks for capturable flags near the hero.  If it finds flags and then the capture flag action can be fired.

CaptureActions, has imiliar flag searches, except it looks for nuetral then enemy flags and goes after the closest ones in the same distance.

I will do some offline testing with large value and have it search hopefully the whole map.   I am wondering if centering the search on its own citadel (instead of itself) will get it to capture its side of the map that should be defendable first and work its way out looking for lightly defended flags.

Maybe I'll also write a second Capture Action specifically for portals.   Give it a slightly higher weight than the general capture flag function, and see if maybe can be induced into going after portal flags better.

Probably take some time to get some of that going, but i'll try a little tonight and over the week if it doesn't come together quickly tonight.

Hah.  Tried a larger search area for flags and the game got upset at me:

warning: 00:00:44: Error running lua script: You're asking for all units for over half the map!

Going to try to re-write it to just get all the flags and find some other function to sort them by distance.

That's an awesome error.