Jump to content


Member Since 14 Jan 2006
Offline Last Active Jan 28 2007 03:18 PM

Topics I've Started

Beta testers?

23 May 2006 - 07:31 PM

Why doesn't the team (not really me, I'm part-time at best) get a few more beta testers? Some serious work into knowing the AI's exact weaknesses (in a list!) would be a good idea, as well as testing the numerous fixes from the last release.

Larkin has said we basically have no testing team but the developers. ;) A post in the Relic boards or something might help, or Thud can ask around a few of the teams and see if anyone is spare (the AI is quite easy to test compared to balancing the game or testing for mod bugs!).

Hardcoded functions documentation

02 March 2006 - 02:41 AM

I personally am going to try and learn more of the AI in a short amount of time. Its took me a half-week to get up to knowing most of the basics.

I'm moving onto documenting the hardcoded AI functions: http://www.relic.com...ar/AI/Functions

Note, however, that the section is likely to change dramatically.

For instance, duplicated "Update" functions, the rather random appearance of the entire (old) strategy.ai and plan.ai file's contents, as well as no information on many functions and how they work means it probably will be recategorised.

Some functions seem to be usable on a lot of "things", some seem pretty random and "why would you use that" kind of thing, so I need to delve further. Only the unit/squad stats makes much sense to me at the moment.

I'd request the AI team document the functions on the wiki themselves, but I really doubt I can ask that of them since not that many people actually mod the AI in any capacity :p

Custom unit stats in RACEunitstats.ai file

01 March 2006 - 10:34 PM

Excedrin and Corsix, after I "interrogated" them about the AI, and custom stats, pointed me out this:


Getting rid of RACEcustomstats.ai and its relations, and getting a proper custom stats file, and related functions, to get the data in an updated version of unitstats.ai would be great.

Basically, things like troop cost, unit max's and bases, immunity to morale damage, and other things excedrin added to his sample code would be great.

A few more to allow better commander attachment and unit stat pairing off, also allows the race code to be continually moved to the stats files.

Basically, there are several reason for attempting this:
  • Allows one place for unit stats to be created and tweaked by the user to affect how the AI uses that unit
  • Removes the requirements of hardcoding things into the AI files, ie: anything which is "squad_" in strings anywhere in the /core AI folder!
    • This allows custom races to be added and perform at full functions straight away, with just a few variables.
  • Allows better use of commanders, among other things, since they'd be able to automatically ignore some units to attach to (eg: getting a space marine squad with lots of plasma isn't a good idea for a melee bodyguard), as well as knowing if a unit has a comparable HTH attack - since for example, chaos space marines and cultists both perform well enough in melee for melee commanders to use them to attack with.
  • Could mean a much easier and quicker way to sort out some things the AI has trouble with, in relation to units.
I will look into getting Excedrins ideas sorted with me doing the commander AI, removing the RACEcustomunitstats.ai files completely, and adding a new custom.ai file, with functions to:
  • Return any one of the AI stats, and enemy units should be passable too. Perhaps a function for each one.
  • EG: self.custom:GetCanCapture() - gets and returns, if there, able_to_capture (boolean)
  • someone.custom:GetTrooperCost() - gets and returns, if there, troopercost (integer)
  • ally_unit.custom:GetMoraleImmune() - gets and returns, if there, moraleimmune (boolean)
  • ...and so on
These would work based on the squads name, unless I can get it to work with the unit setting the information on itself somehow, rather like how self.stats is set to GetUnitStats() or somesuch.

Would need some way to make sure this works with all enemy and allied units...

...so since I'm still not 100% sure on the workings of functions (ie: started a few days ago on it!) and the strange table-based storage of functions and how they work when not referencing self, especially with custom functions. Still might be able to get somewhere though :blush:

Commander Attachment AI

01 March 2006 - 03:15 AM

Okay, this took me a while to get working in any form.

How does the AI know when to attach things? How does it deattach? A quick lesson for us all...

Firstly, certain things run on a squad. A squad is each seperate entity on the battlefield which can be selected.

This was my first hurdle of understanding, that, in fact, commanders when attached cannot be got at except through a few info functions such as GetAttachedHealthPercentage() and an important HasSquadAttached().

So, when a squad has a commander attach, the squad's AI determines when the commander de-attaches.

Also, this means we cannot check stat info of the attached unit, since they are not a seperate squad, they don't have gettable names, stats (eg: ranged, stances) or suchlike.


There are some additional problems with the AI code. Namely, some useful information, such as if a unit is unbreakable, are unavailable (things like squad size, "rating" and suchlike are available). A shame.


So this is what I'm working on:

- A table set via. the squad's ID, when they are attached to by a commander unit, with ranged and stance information, as well as a special field "keep_attached", which if true, will never deattach the unit.

- An additional (table) input for TryAttachSquad(), called something like best_attach_unit. Possibly the table will include some stats to check for, or requirements for attaching to the best squad. Range limits still apply of course. This code would allow the farseer to attach (permanently) to seer councils, for instance. Will get this table to be priority based - possessed marines over khorne beserkers for instance.

- Will add a way to make sure units stay attached to a commander for a greater amount of time. Units attaching then suddenly detaching just because the current battle is over is counter productive sometimes.

- Might detach during combat, need to look into switching to a really close, better CC squad if the commander is in CC.

- Will attach some ranged heroes to ranged squads mostly permanently (eg: Sorceror, who is a bit weak in CC)

- Broken squads will not automatically get deattached, since the commander might just be better off staying with them for a few more seconds (especially with space marines).

- Only named, primary heroes (in the exsisting hero table to be precise) would have permanent fixtures applied.

- Might attach melee commanders to (primarily) ranged (but still good/mediocre in CC) units if there are a few around, to provide some cover for the commander (eg: Space Marines, Chaos Space Marines, Cultists, Shootas, Guardians).

- Might attach ranged commanders to primarily melee units, and set the squad to range, if there are a lot of them. For example, Khorne Beserkers do have pistols, as well as Banshee's, Sluggas, Nobz, etc. Could happen when damaged (it was meant to according to the code before anyway), but this might happen before combat.

- TryAttachSquadMelee() should be revamped to allow a commander to look for specific squads first.

Perhaps most importantly, besides the permanent fixtures mentioned:

- Commanders might well attach well before combat with good or large units, meaning they are ready with a good unit as cannon fodder/backup right away and provide bonuses before hitting enemy units. Also groups commanders with the army better.


I will post code changes later if I can get some of the stuff working well. It'd mean changes to each commander's specific AI files, but that'd not matter too much.

I will look into the tables info, and see if some decent logic can be decided on how commanders attach to units and how they deattach according to conditions.

Will also see if we can have the race code "race"infantrytatics.ai file, return "moraleimmune" function as true if an actual unbreakable unit (EG: Khorne Beserkers).

A lot to do? not much, to long winded. Any suggestions on how you attach commanders, and how the AI should, would be welcome. Might as well get it right first time.

Checking Cpu_DoString

27 January 2006 - 01:39 PM

Hey AI team,

I want to know if anyone knows anything more about the SCAR function Cpu_DoString.

Official description:

Runs a string on an AI player
Void Cpu_DoString(
PlayerID player,
String s,

I added a little about what I thought it implied to the wiki:


However I do not know the specifics on how this works.

It could be useful for singleplayer AI - since the SCAR script ditacts the difficulty, and activation (or lack of) the CPU AI files, and can interject some commands and stop the AI from using some units.

This, in combination with the other things, could allow a specific map to have, for a race, a specific build pattern or something - if the string is activated when the AI is enabled, it could load new files or something.

But I'm not entirely sure how it works. My example is:

-- Possible example. Run this on an AI player to do the same thing as Cpu_CounterVictoryObj
Cpu_DoString(World_GetPlayerAt(1), "CpuManager:CounterVictoryObj()")

Which may not actually be a correct use of it.

can anyone either be able to test is or perhaps say what it could be? Or provide a better example of a function to execute which'll provide feedback (or how to add a simple one to the default.ai file perhaps) when executed via. this so I can test this?

Thanks for any info guys!