the_hunger the_hunger

AI Skirmish Mod, v. 23 (big update! - 8/16/2010)

▼

AI Skirmish Mod, v. 23 (big update! - 8/16/2010)

Some revisions to Peppe's mod

from Demigod Forums

This mod is a revised version of Peppe's AI Skirmish mod, version .22 (http://forums.demigodthegame.com/369930).  It further refines Peppe's excellent work by fixing a few outstanding issues.  The mod is designed to make single-player skirmishes more challenging and enjoyable.

Current Features (v .23):

  • Teleporting: AI demigods will no longer teleport very short distances.  Demigods are likely to carry at least 1 teleport scroll, but a little less likely to carry more than 1.  Generally, AI demigods teleport more intelligently.
  • Flag Capturing: Greatly increased desire of AI demigods to capture and hold flags for warscore.  Also, coded custom flag-capturing routine for most maps.  AI demigods battle for flag control more and are more aggressive at capturing portals (and recapturing their own portals and other important flags).
  • Tweaked AI builds for Rook and Regulus.
  • This mod is best played on Nightmare difficulty, with the Conquest win condition, and with 2v2 or larger teams.  However, the AI improvements apply to other difficulties and win conditions.  The AI in the single-player tournament is unchanged.

Known Issues (v .23):

  • Occasionally starting Regulus, Oak, or Unclean Beast in the number 2 slot on either the Light or Dark team will result in the demigod not leaving the health crystal at the beginning of the game.  I am not sure why this is, and it does not occur every game.  The solution is simple: Don’t place any of these three demigods in the number 2 slot.
  • On a few maps, AI demigods can be overly aggressive about going after portals in enemy territory.  Generally, AI demigods are good about avoiding enemy towers and staying away from tower-protected portals.

Installation:

Place the Skirmish_AI_v23 folder in your Mod folder in your Demigod game directory.  This is usually found in C:\Program Files\Stardock Games\Demigod\bindata\mods.  After starting the game, go into the “Mods” option and enable the mod.  Be sure to disable any previous version of this mod.

Disclaimer:

I should say here that all praise should go to Peppe for this mod.  Just looking at his work, I am amazed by his grasp of the coding and the things that he's accomplished. Thus, I make no claims to this mod.  He's done 90% of the work; I just added 10% tweaks to refine it a bit.  I hope that he's cool with these tweaks (and maybe flattered by our continuing interest in his work), though he seems to have left the community some months ago.  In any event, I do take just a little credit for inspiring him to start the mod in the first place (see http://forums.demigodthegame.com/369842).  Again, many thanks to Peppe for giving this game some extended life.

Download:

Get version .23 of the Skirmish Mod at: http://www.filefront.com/17207898/Skirmish_AI_v23.zip/. Download includes mod folder and readme.

 

______________________________________________________________

.22 Changes: 2/08/2010

Tweaks to new or changed items in 21.  Should avoid flags protected by towers (more often).

 

.21 Changes: 2/07/2010

Custom actions created to teleport to towers and portals under attack by enemy Demigods.

When looking for flags to capture all Demigods consider all flags.   Actions for flags nearest HQ, near to demigod, and portal flags.

Capture lock changed to only lock portals and valor flags under enemy threat.

 

.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.

 

.19 Changes: 1/25/2010

Mainly Stun/Interrupt Changes.

UB + Rook will save thier skill for interrupt or a low health target.

Sedna + Oak, will fire thier interrupt skills as long as they have mana and should stop using it once they reach low mana, but will fire if an interrupt opportunity presents itself.

Erebus,  Will use charm mostly for interrupt, but if he can stun multiple demigods will fire it off.

Demon Assassin,  Didn't test this, but should only shadow swap to interrupt may add additional conditions later.

Teleport and Large potions set back to require a safe distance from enemies to use.

 

.18 Changes: 12/15/2009

Sedna Heals earlier, @75%

QoT Casts shield earlier, @75%

Some flag cap changes.

 

.17 Changes: 12/14/2009

Sedna build changed.

Minor changes to survival goals.

Flag capture range extended.

 

.16 Changes: 12/13/2009 Mark II

Minor changes to Teleport distance check and consumable item priorities.

UB build changed to Ooze + Spit maxed by lvl 10.

Sedna Item priorities changed.

 

101,232 views 37 replies
Reply #26 from Demigod Forums Top

Quoting miriyaka, reply 24
Well, I traced the single player launch process up to LaunchSession(SetupSinglePlayerSession(sessionInfo)), which is an engine command that does who-knows-what.

Do you have to do anything special to use UI mods in single player?  If not, there should be code somewhere that differentiates between UI and sim mods for a single player session, and it should just be a matter of finding out what happens after LaunchSession, lua-wise.  This is a part of the engine I don't have much experience with - I know some lobby code, and plenty of in-session stuff, but not what order the whole session init process happens, or how it's different in SP vs MP.

 

Edit: LO, when I see a tower Rook in .23, he's always, always raising towers.  During an average mid-game fight, he pops at least 2-3 of them, and usually chains them out properly when advancing on a creep wave.  Are you sure you're not doing something that's disrupting this?

If he is getting attacked it seems yes, but if he joins in a battle and is not getting hit, tower production is not high.

Reply #27 from Demigod Forums Top

I see how to force skirmish AI in campaign, but there's no way to do it in an actual mod itself.  Unless there's a way to shadow/override files within dgdata.zip outside of the mod system, you'd have to insert a modified mods.lua or SinglePlayerLaunch.lua into dgdata.zip, which would probably cause desyncs in multiplayer with anyone who didn't also have the same modified dgdata.zip.

If the game will read / overwrite files contained in a dgdata folder, it will still desync, but you could at least make a batch file that runs the game specifically in campaign mod mode, moving/renaming files, and leaving multiplayer sessions launched with a normal shortcut unaffected.

Or if the latter is true, just overwriting SinglePlayerLaunch.lua may not cause desyncs, as it should never be loaded in a multiplayer session.

 

Update: 

Ok, I can get single player mods working, but it requires adding a new mount point to \Demigod\bin\RetailDataPath.lua, and then an overwrite of /lua/mods.lua in the new mount path.

I'm pretty sure this will break multiplayer compatibility (except with someone else who has the exact same files), but the good news is that it can be easily controlled by a batch file that swaps out two copies of RetailDataPath.lua for a dedicated Campaign Mod Mode launch.  I can set this up, if anyone's interested.

Elemental: Reforged
Reply #28 from Demigod Forums Top

Welp, no luck.  No matter which directories I mount in RetailDataPath.lua, no matter the order in which I mount them, the game ignores all files in those directories, including within hook subdirectories.  I can't find any other files that reference mount paths other than GameDataPath.lua, also in \bin, which seems to do absolutely nothing and is never called.

So, unless I'm missing something, the only way to do this is to make a copy of dgdata.zip with the modified files contained therein, and switch between the two with a batch file.  Not exactly convenient.

Reply #29 from Demigod Forums Top

Quoting miriyaka, reply 28
Welp, no luck.  No matter which directories I mount in RetailDataPath.lua, no matter the order in which I mount them, the game ignores all files in those directories, including within hook subdirectories.  I can't find any other files that reference mount paths other than GameDataPath.lua, also in \bin, which seems to do absolutely nothing and is never called.

So, unless I'm missing something, the only way to do this is to make a copy of dgdata.zip with the modified files contained therein, and switch between the two with a batch file.  Not exactly convenient.

It's not so bad if you do it right.

Simply make 2 demigod bat files. ;)

One loads up single player AI.

The other loads up the normal set.

Also, looks like I finally found an advantage to destructive modding. :D
One copy paste and my work is done. XD

Reply #30 from Demigod Forums Top

I already have that part worked out; the problem with using dgdata.zip is distribution.  dgdata.zip contains all of the lua for the entire game, and is 20mb.

I can just distribute a batch file and a mods.lua, but then installation is a pain in the ass, and either people won't figure it out or won't even bother to try because it's unnecessarily difficult.

 

Quoting LORD-ORION, reply 29
Also, looks like I finally found an advantage to destructive modding.
One copy paste and my work is done.

Why do you think everyone does it?  Because it looks easier, and maybe it is at first.  Of course, then your 'work' won't work with everyone else's, and you just limited the audience of your mod to the few people that will choose it over others.

Reply #31 from Demigod Forums Top

Quoting miriyaka, reply 30
I already have that part worked out; the problem with using dgdata.zip is distribution.  dgdata.zip contains all of the lua for the entire game, and is 20mb.

I can just distribute a batch file and a mods.lua, but then installation is a pain in the ass, and either people won't figure it out or won't even bother to try because it's unnecessarily difficult.

 


Quoting LORD-ORION, reply 29Also, looks like I finally found an advantage to destructive modding.
One copy paste and my work is done.
Why do you think everyone does it?  Because it looks easier, and maybe it is at first.  Of course, then your 'work' won't work with everyone else's, and you just limited the audience of your mod to the few people that will choose it over others.

This is why you need to make a complete package for offline mode. This is pretty much how my warmonger mod for Total Annihilation competed with UberHack when I left the project. eg: Made the AI completely non-Cheating and better, AI style profiles, changes to the campaign to make it better... plus the real agenda of the balance changes.  A year later, and I had 1/3 the downloads of uberhack, which is pretty good. Balance changes alone? Probably wouldnt have even got a 1/4 of the downloads I did.
 
So... have a pure uberfix, but then have a uberfix+ or whatever, that contains the useful things that are appealing.

For the final CrazyTown... the name will change, the AI will work in tourney mode, the AI will be as improved as possible, it will include Item Roll Over + Team Panel + some other non-disclosed ideas I have to make the tourney experience better, and the balance changes.

Basically, you have uberfix, and then you have your vision of what the game should be in one package. (it could be as simple as including the mods you use)

Reply #32 from Demigod Forums Top

There's zero excuse for that in the moho engine though.  It lets you combine any number of mods smoothly and efficiently, and all you need to do is to learn some simple shorthand for editing blueprints.  I see people coming into the FA community all the time with this 'mod pack' mentality, and it's retarded, because then you end up with this stagnant set of a bunch of mods that are all individually being updated and improved and that work just fine together, but that the mod pack author doesn't have the time to keep up with and continually re-integrate.

Even when two mods don't play nice, the engine amazes once again by allowing a much smaller and simpler third mod to step in and integrate them from the outside, also with a minimum of destructive overrides (none in many cases).  This allows the mods to be individually maintained and improved while still working together just fine with the arbitrating mod.  There's simply no excuse to use destructive methods for anything but Baby's First Mod(tm) - take the hour or two to learn how to do it right, and I promise it will pay off-- especially if you're going to be spending dozens or hundreds of hours on a big mod project.

If you're making major code alterations, you need to learn how the game's lua works inside and out anyway, and this just gives you some basic experience with that.  When I started modding FA, I didn't know the first thing about lua, but I quickly memorized how to do some quick and easy hooking methods by looking at other people's mods.  Then after using them for a week or two, I understood why and what I was doing with these rote methods, and within a few months that segued into learning lua well enough to accomplish just about anything in which I have the time or energy to invest.

 

And I see you're already talking about merging other people's perfectly viable standalone UI mods into yours.  Again, why?  Who does this help?  Everyone already uses these UI mods, and they're great individually.  There's nothing to improve by mashing them together.  Nevermind that you would need the permission of all their authors to do this.

Reply #33 from Demigod Forums Top

Quoting miriyaka, reply 32
There's zero excuse for that in the moho engine though.  It lets you combine any number of mods smoothly and efficiently, and all you need to do is to learn some simple shorthand for editing blueprints.  I see people coming into the FA community all the time with this 'mod pack' mentality, and it's retarded, because then you end up with this stagnant set of a bunch of mods that are all individually being updated and improved and that work just fine together, but that the mod pack author doesn't have the time to keep up with and continually re-integrate.

Even when two mods don't play nice, the engine amazes once again by allowing a much smaller and simpler third mod to step in and integrate them from the outside, also with a minimum of destructive overrides (none in many cases).  This allows the mods to be individually maintained and improved while still working together just fine with the arbitrating mod.  There's simply no excuse to use destructive methods for anything but Baby's First Mod(tm) - take the hour or two to learn how to do it right, and I promise it will pay off-- especially if you're going to be spending dozens or hundreds of hours on a big mod project.

If you're making major code alterations, you need to learn how the game's lua works inside and out anyway, and this just gives you some basic experience with that.  When I started modding FA, I didn't know the first thing about lua, but I quickly memorized how to do some quick and easy hooking methods by looking at other people's mods.  Then after using them for a week or two, I understood why and what I was doing with these rote methods, and within a few months that segued into learning lua well enough to accomplish just about anything in which I have the time or energy to invest.

 

And I see you're already talking about merging other people's perfectly viable standalone UI mods into yours.  Again, why?  Who does this help?  Everyone already uses these UI mods, and they're great individually.  There's nothing to improve by mashing them together.  Nevermind that you would need the permission of all their authors to do this.

No, that only applies to the grognards of the game.

The average gamer couldn't give a crap about the valid points you make. They think like this when looking at mods... hrmm, balance? Who cares, and weird. UI maybe. AI? Sure.... then they see Package: Play all encompassing game with this one download that promises to fix the glaring flaws with the game.... yep, that's the one they choose.

I honestly get what you are saying, but that should not the your target audience... especially in the game's current limited player state.

This is 1/2 what you think of the game and 1/2 marketing of your mod. ;)

Reply #34 from Demigod Forums Top

Actually, the absolute most common question in the FA mod forums is "is this mod compatible with that mod" even when they're huge, balance-changing mods that add tons of units.  By a factor of 50, over all other questions by 'average mod users'.  So yes, everyone definitely cares about which mods can work together, because these games are unique in making that possible.

None of the teams producing the big TC-type mods for FA intended for their mods to work together, but they eventually ended up that way by popular demand.  One guy did a solo rework of the massive mod he and a team made over 3 years for the express purpose of working with other mods, when it hadn't before due to destructive changes.

Basically, 'your vision' for the game isn't what most people want, no matter who you are or what it is.  The best way to build a mod that's popular, well-received, and worth maintaining is to do some of the things you want, but to appeal to the widest possible audience - which in Demigod or FA, is as simple as keeping different kinds of changes (balance, added features, AI tweaks, etc) in separate mods.

 

Either way, integrating UI mods into a sim mod is silly and pointless.  UI mods are great precisely because they can be used online, in any game, independent of any other sim mods.  If a sim mod tries to integrate those UI mods, and then the user tries to enable standalone versions, whoops, you've got problems.

Reply #35 from Demigod Forums Top

Quoting miriyaka, reply 34
Actually, the absolute most common question in the FA mod forums is "is this mod compatible with that mod" even when they're huge, balance-changing mods that add tons of units.  By a factor of 50, over all other questions by 'average mod users'.  So yes, everyone definitely cares about which mods can work together, because these games are unique in making that possible.

None of the teams producing the big TC-type mods for FA intended for their mods to work together, but they eventually ended up that way by popular demand.  One guy did a solo rework of the massive mod he and a team made over 3 years for the express purpose of working with other mods, when it hadn't before due to destructive changes.

Basically, 'your vision' for the game isn't what most people want, no matter who you are or what it is.  The best way to build a mod that's popular, well-received, and worth maintaining is to do some of the things you want, but to appeal to the widest possible audience - which in Demigod or FA, is as simple as keeping different kinds of changes (balance, added features, AI tweaks, etc) in separate mods.

 

Either way, integrating UI mods into a sim mod is silly and pointless.  UI mods are great precisely because they can be used online, in any game, independent of any other sim mods.  If a sim mod tries to integrate those UI mods, and then the user tries to enable standalone versions, whoops, you've got problems.

As mentioned, they should incorporate the popular aspects into their mod, and probably even provide their own slant on it. What you are describing is some commie hippy commune utopia that degenerates into a "blend this mediocrity together" stew of permutations that nobody else will ever be playing.

What I am describing is a bunch of competing and evolving parcels that force the authors to achieve excellence.

Also, you are slanted towards "what is visible" in the community vs what is reality. The biggest question may be "does this work with that?" but it is completely irrelevant when that is asked 1 time for every 1000 downloads of your mod.

This is not to say that I wont ever make a non-destructive version of CrazyTown, I've made that known to you that it is on the todo list. what I am saying is the final iteration of CrazyTown will be 1 complete package. So when some guy a year down the road picks up DG in the bargain bin, he has a way to get better value for the game without getting lost. If there was a Uberfix+ vs Crazytown vs Items+ (favor mod + a bunch of other cool stuff) complete packages, so much the better, the 3 packages would be forced to be better and offer features, or be unconsidered.,,, maybe the author would be fine with that... depends what motive he has for creating the mod in the first place. And that's OK too.

Reply #36 from Demigod Forums Top

This is a silly derail, but I'd just like to add that certainly not everyone sees it your way, especially mod users in GPG's game communities, who are quite used to being able to combine mods at will, and will actively avoid mods that break compatibility with or cause problems for the myriad other mods that they're using.  Demigod is a bit different because they provided limited to no ability to add new units or items (also because nobody plays it, loool), but the same UI / sim exclusion expectations apply, and should.

Reply #37 from Demigod Forums Top

This is amazing, especially for all us LAN players out there! Thanks so much, keep up the great work. My suggestion is to have allied demigods occationally group up with each other to take towers and get kills, and to improve the point at which they run. As it stands, they occationally do this well but most of the time they wander around alone and fight way past the point of no return.

 

Regards,

Violetsreason

P.S. accidently necrothreaded your last update, but on the plus you got karma