[SC-WIP/REL] Further Tweaks to Sorian and Jaws2002

[:1]First, thanks to Sorian et al for such an excellent amping-up of SC!



I love long, massive turtle games against the AI, in skirmish or coop with a buddy. So I set out to tweak the AI to make it even more challenging, and to take advantage of the late game and the fact it cheats. For long and massive read: 200-odd experimentals per AI by 2hrs in.



The small tweaking spiraled into some rather larger changes, and I figure I should give folks a chance to play with them, which Sorian has kindly allowed me to do.

This is very definitely WIP, but certainly playable (Did a bunch of observer testing, just finished a grueling but fun 2hr matchup).



The changes fall into two main groups: tweaking the Jaws2002 Cheat AI and changes made in support of that, and general bakground AI changes. Note that this does not include a new AI archetype, archetype changes are just a mod of the J2002C AI. A rough sketch of the changes:



****

[]Rewriting of (S)EBC to take cheat income into account (still done, as with Sorian, by using a separate file for the cheating AIs rather than checking a flag). This required addition to AIUtils. I also changed (only in J2002C) cheat() to work every half-second, to try to get storage in better line, and to help with the econ gauges when observing. Trend() now works for cheaters too, more or less! This means econ calls from within the AI archetype will actually return correct answers.



[]Modifying J2002c to take advantage of its cheating, i.e. changed priorities, even bigger Exp strike groups, more builders, etc. I'm using number of SCUs alive as a proxy for AI development, so the build orders and platoon sizes ramp up. More T3AA and naval defense builds added, and set to build adjacent to T1 and naval factories respectively. SCUs also get more jobs, like exp, nuke, and SMD.

Nuking code is also tweaked, for more rapid barrages when silos have enough ammunition, and to send >2x SMD instead of >1x, since SMDs can often get off a second shot.



****

[]Changing adjacencybuild behavior when true adjacency is impossible, so the builder moves to the chosen building first, and only then calls AIExecuteBuildStructure with buildclose=true. Stock, it just builds wherever is closest to the engineer and hang adjacency. I also put in some ifs to trap buidling on a dead builder (which caused errors, on the off chance they occurred). The main result of this is that, for example, naval defense actually gets built. See WIP shot below.



[]Changing SCU upgrade behavior to account for upgrades that replace others--i.e. a set of orders that includes both shield and then shieldheavy would error out (rather than skip) if the SCU already has shieldheavy because it can't add shield. Currently it's a hack--I just check last upgrade in the string, rather something smarter. SubCmdrCanUpgrade from Sorian is also tweaked--it looks like it would return false if _any_ SCU is upgrading, limiting the AI to upgrading one at a time irrespective of InstanceCount. I changed it to check both at once, and return true if any SCU that lacks the upgrades is not upgrading. I also added an inverse, SubCmdrsUpgraded(), to return true if and only if all SCUs are upgraded (for this I, messily, pass all three final upgrades, and do an or, so I didn't have to write three cases for everything). This is used to ensure SCUs upgrade themselves before doing any engineering.



[]In basetemplates, for the main base templates, experimentals now have grids that do not overlap, so engineers don't sit around waiting while 3-4 exps are queued up overlapping each other. This means that they now can't be built in some tight spots that would work before, but for the cheating AIs with multiple exp teams going at once, it seems to work better.



****

[]Finally, a change rather than a tweak: randomized building now occurs for engineer-built platoons too! (See thread on InstanceCount.) This works by, each execution of PBMFormPlatoons(), creating a new platoon list where each priority group is in random order, then running the original loop on the new (indices only) table. More expensive than an in-line version, but I couldn't get that to work properly (first time working in LUA). Hasn't caused a noticeable slowdown, and it's still linear time anyway, even if it's now 3n (though probably not really 3x as long--my two passes just fill a separate table, rather than doing any of the build checks or orders of the original loop's code).





NB: This is all based on Sorian et al's work, and you need that mod in your gamedata folder too! All the requirements, etc., from his readme still apply.



Credit, Reuse:

This is a mod of Sorian et al's work, so speak there first; but as regards any work of mine, you are free to change and rerelease at will, so long as proper credit is given.



Link: http://www.megaupload.com/?d=QVTPLZP5

If anyone knows of a better place to stash this, let me know...|||Hey,



I tried to test your mod but it seems to cause some issues, the selection menu for the AI stays empty.|||Do you have Sorian's combined AI mod in gamedata as well?

In your GPG\SC\Gamedata folder you should have, along with all the stock SCDs,

00_sorian_w_NKchanges.scd

01_sorian_ai_merge.scd|||Going to go test it out and here is a mirror its a direct link compared to yours which requires you to jump through two hoops to download it.



Mirror|||Thanks, Kenquinn!|||NathanKell|||Aw man, this would be PERFECT for FA. As great as Sorians AI is, it does suffer late game a little bit. Any plans to updated it to FA, NathanKell?|||Never played FA, didn't seem as much of a builder's game.

I mean to try it at some point, though.



Other than the archetype edits, if the codebase is similar enough you can probably diff my files with Sorian's, and then insert those changes into FA...?

I.e. if PBMFormPlatoons() still exists, and SEBC's/SBC's code is mostly the same.