Fixed build lists for vanilla AI?

posted on April 5th, 2014, 4:51 am

As I have determined via Observer testing, the build lists for FO 3.2.7 Normal AIs are broken, at least insofar as the AIs ever fail to eventually leave the light cruiser "era". This holds true for all factions but the Borg, which behave almost identical (if with less ships and more sparse attack waves) to their Hard version.

- Now, it did not take a whole lot of testing to notice, so I cannot be the first one. Did anyone bother to fix these lists (mainly, make use of the "maximal built" or "tech level" restrictions)?

Furthermore a couple of inquiries on AI in general: rifraf's improved strategic AI files contain a couple of questionable entries (I have in this case not bothered with the vanilla files as someone already had tested and documented the results):

In RTS_CFG.h:

Code: Select all

// how many freighters can we have around each resource?
int cfgFREIGHTERS_PER_MOON = 5;
int cfgFREIGHTERS_PER_NEBULA = 5;
int cfgFREIGHTERS_PER_PLANET = 5;

I understand that this is not actually an AI setting (Or is it?) but I have also found that the AI does put more than the optimal three freighters towards dilithium and tritanium moons, and also that it fails to recognise (as the Armada 1&2 AIs could, if not quite reliable) that its ally already had filled out a moon with the optimal number (was four freighters in Armada 1&2, is three now except for Borg).
- Both issues were alleviated by setting these values to '3' instead. I am not yet aware of ill side effects.
Are there any?

Code: Select all

float MEDIUM_AI_COST_HANDICAP = 0.2;
float MEDIUM_AI_SPEED_HANDICAP = 0.7;

Does this mean what I think it mean? That even a Normal AI pays only 20% of a ship's cost and builds it in 70% of the time!?

Code: Select all

// Pathing cost for asteroid belts
float ASTEROID_BELT_PATHING_COST = 400.0;

Should this not be "IMPASSABLE_TERRAIN"?
If not, what exactly is an "asteroid belt" in game terms?

Code: Select all

// How far ahead to project a collision
float COLLISION_LOOK_AHEAD_TIME = 1.2;

// How much wider than reality to pretend objects are for collision avoidance
float COLLISION_SAFETY_MARGIN = 1.1;

Ships colliding in-game is a frequent occurance, and it looks pretty ugly. Should these values not be somewhat higher? I currently set them to 1.6 and 1.3, but I currently lack the time to properly observe the effect.

The most annoying weakness of the AI is its inability to spread: Current Normal and Hard AIs will secure two expansions and leave it at that. Obviously this is tailored to small maps and the AI would end up to clutter its main base with mining stations if no more expansions were available. Yet, it effectively removes harrassment as a game element after the first minutes of a game, as there will be nothing left to harrass.
Incidentally, with the "cfgFREIGHTERS_PER_"-settings as they are, the second AI expansion will typically lack any freighters. Set to '3', there will be AI freighters mining moons without stations - which enables harrassment but is a bit too stupid.
- What means are there to change between build lists in a running game?
This seems to be the only proper means to fix this problem, as unlike in say Warcraft 3 conditional expressions in build lists are not supported (due to them being structs, not functions).

Finally, the AI on game start behaves quite a lot more satisfying than after the game has run for some time: Small groups of ships patrol its sphere of influence, guard bases, scout the map...
- Once it reaches a certain point, all of these activities seem to cease, all that remains is blobbing in the bases and occassionally sending fleets to attack hostile bases. That fleets are not exactly smart about this and may sit and wait right next to other fleets in deadly combat, is probably a hardcoded issue though (but in general, it looks as if the AI's actions were somehow 'cut off', like a script language interpreter may decide to terminate subtasks over a certain execution time threshold - commonly suffered in TES:Skyrim for example; but the time necessary here seems to be far too miniscule to promote this as a satisfying answer).
It may be, that the AI at some point switches its behaviour aip and that the starting one works fine while the later ones are broken... any insight?

--

I am not amused at this forum arbitrarily ignoring my line breaks. I set these for a reason and chose their positions with care.

posted on April 5th, 2014, 5:58 am

Welcome to the forums - and good observations Zsar!

As you have noticed, the AI is not so... intelligent. This is one of the last areas we investigated in Armada 2 - Fleet Operations and we did not put much effort into adjusting it. We had planned to completely replace the AI with our own work, however now have other plans

Due to the rather clumsy implementation, the point of the AI in Fleet Ops was merely to provide a challenge that you and your friends can defeat - a horde of ships, albeit stupid, can still be a challenge in numbers! In order to do so, yup, we forced the AI to obey certain very handsome handicaps and also to produce more freighters than normal (that way you always have something to shoot at ). That's not to say we didn't screw anything up - the build lists were done by hand, unlike most other aspects of Fleet Operations.

The AI in FO is forbidden from using tech level, but it is of course possible to change that easily .

Information on RTS_cfg.h values can be found here, in the guide: http://guide.fleetops.net/guide/modding ... THING_COST . Collision values appear to have no function in the engine as far as I've been able to tell.

So far as I know, it is a mystery currently how the AI decides to change between build lists, if it indeed actually does so (the AI user interface says the AI does, but behavior does not appear to change). Again, the AI is quite crude and rudimentary. We are working to remedy that in NX - but for A2-FO, this is unfortunately what we had!

posted on April 5th, 2014, 6:37 am

Mmh. I hope you will implement not build lists but a proper decision forest with one tree per build source (constructor, ship yard, offmap, etc.).
- Or you could choose the weight approach, as seen in Company of Heroes or Space Empires 5. This has proven to be hard to balance though and only hides the necessity to compute what is why how much desirable under a second layer of abstraction.

Anyhow, the Guide is not necessarily accurate. See for example GRID_SIZE. It does not work. At least it did not work, when I defined it in RTS_CFG.h as '50' (half of default) and activated the grid in-game: The grid resolution did not change, and certainly not to half.

The AI in FO is forbidden from using tech level [...]

I do not understand. The one viable interpretation seems to be that providing a build list with entries like

Code: Select all

"fed_saberZ",               3,0, -1,  -1, // Saber class

(taken straight from the guide) would result in undefined behaviour.
- But if the Guide were wrong on this part too, the rest of the sentence would not match:

[...] but it is of course possible to change that easily [.]

So, there must be a flag set somewhere, to actually enable this functionality?

... What about, by the way, the Build_List_Class struct? Is this legacy and/or unused code?
What about the syntax? This looks like some sort of C dialect, but definitely not ISO C.
What if I wrote a function into one of these files?
The guide claims that definition of custom build list elements were possible - how would the engine comprehend which value represented what:

Code: Select all

typedef struct Example_Element
{
  char unit_type_name[20]; // If memory serves, internal arrays need to have their length specified at compile-time...
                           // Well, this one differs from the others '80' -
                           // would have to be translated into a char ** and heap-allocated char[20].
  unsigned_int units_to_build; // Cannot build half a unit, can we?
  int m_techLevel; // intentionally maintained type but left out m_buildMAX
} Example_Element;

Is it going to interprete the values according to their names? How important are those type declarations?

Finally, if I am not mistaken, Armada 2 utilises level specific build lists. Surely those cannot be loaded based on a dynamic algorithm but must be hardwired to the level they belong to. If such functionality were still available in FO, surely one could count the moons and set the desired number of expansions accordingly. Not elegant, but an available means to a necessary end.

--

Please excuse the shoddy formating. It looks beautiful before the forum processes it and swallows my line breaks!

posted on April 5th, 2014, 5:15 pm

Yes, sorry, I forgot to write in those respected lines which commands are only available in Version 4.0. I have done so now. There is an unofficial unsupported 4.0 loader floating around somewhere, but we are not supporting it. Still, I have decided not to delete the documentation for 4.0.

Ah, I misunderstood the question - yes, technology level is fully functional. There is a flag at the top of the AI file that disables technology tree checks, which is for some reason what I thought you were referring to.

Armada II - Fleet Ops engine is compiled, so writing functions like that will not work. Yes, originally A2 was written in C++ as I recall,

I'm not sure what you mean by Build_List_Class, but there is indeed a lot of legacy code in the AI. We haven't spent terribly much time investigating. I'm no coder and can't answer more technical questions here. Yes, A2 recognizes each string and value associated with each string (name) - but no, they are not malleable. I believe in these C++ cases, the game will crash immediately if it encounters something wrong with these AI strings.

The AI only recognizes 'location' information - not the number of moons it has access too. There is a relatively detailed explanation in Base Location, but again, we have not investigated beyond the basics.

Beyond maintenance, we will no longer be adding functionality to Armada II - Fleet Operations. Our efforts are now entirely focused on NX

posted on April 6th, 2014, 11:42 pm

I'm not sure what you mean by Build_List_Class [...]

Aipdef.h:

Code: Select all

///////////////////////////////////////////////////////////////////////////////
//
// Build_List_Class
// -------------------
// Specifies a list of unit types, from which we should try to build one
struct Build_List_Class
{
   char class_name[80];            // The names of the build list
   double priority;               // How important to build form this list
};

Not useable for the problem at hand (different number of desired expansions per player per map), but interesting to provide variation (say, implement the Strategies from the guide).

Armada II - Fleet Ops engine is compiled [...]

Uncompiled ISO C code in Aipdef.h, which I refer to:

Code: Select all

///////////////////////////////////////////////////////////////////////////////
//
// Mo_Better_Build_List_Element
//
// Specifies a type in a build list, which base to build it from, and how many
// times MAX we can rebuild this thing
struct Mo_Better_Build_List_Element
{
   char unit_type_name[80];         // The names of a unit type
   double units_to_build;            // How many of this type per city
   int m_base_num;                  // Which base do we put it at?
                              // (only used for stations)
   int m_buildMAX;                  // How many UNITS max can be built
                              // from this line?
};

Furthermore uncompiled non-ISO C code from borg_instant_action_build_list.aip, which again I refer to:

Code: Select all

Way_Better_Build_List_Element the_build_list[MAX_ELEMENTS] =
{
   //Startup
   "bor_assemblerZ",          1,0, -1,  1,
   "bor_uni_matrix",          1,0, -1,  0,
   "bor_resource_nodeA",       2,1, -1,  0,
   "bor_resource_nodeA",       2,2, -1,  0,
   "borR_connections1",       1,0, -1,  0,
   "bor_freighter",          4,0, -1,  0,
   "bor_uplinkZA",             1,0, -1,  0,
   "bor_detector",             1,0, -1,  0,
[...]
};

Something similar can actually be compiled with GCC 4.8.1:

Code: Select all

typedef struct test
{
  int a;
  int b;
} test;

int main()
{
  test c[2] = { 1, 2, 3, 4 };
  return 0;
}

Throws a "missing-braces" warning (obviously) but does produce an executable.
Switching to G++

Code: Select all

#include <iostream>

using namespace std;

typedef struct test
{
  int a;
  int b;
} test;

int main()
{
  test c[2] = { 1, 2, 3, 4 };
  cout << c[0].a << ' ' << c[0].b << endl << c[1].a << ' ' << c[1].b << endl;
  return 0;
}

this also returns the expected output.

So, as you implicitely answered, this is not C but only looks like it.
Then of course I wonder, what tokens are valid within these files?

Beyond maintenance, we will no longer be adding functionality to Armada II - Fleet Operations. Our efforts are now entirely focused on NX[.]

... You need not restate. This is the reason why I opened this thread in the "Modifications" subforum.
- Hard to believe that no one has taken the time to produce a proper build list for at least some faction, considering that it does not require any technical knowledge or experience and is therefore something literally everyone able to play FO is also capable to do.

To reiterate my former, somewhat important question - is it possible to force the AI into a specific build list by map, say via some form of map script? It should be a core functionality of missions, so should be possible.
- One may then count moons per map and provide a build list based on this count.

posted on April 7th, 2014, 1:17 am

Hi Zsar, I'm sorry, I don't know more than what I've written there - I've done very little experimentation with the AI. My primary interest has been with multiplayer, hence the lack . Optec has done quite a bit in the past with A2's AI, but it has been many years and documentation was poor back then. If you have more fundamental knowledge of programming and would like to assist in future development, getting in touch might be mutually beneficial.

I do not know whether it is possible to force the AI to switch build lists - as you state, it would be nice if it were of course.

I wish you the best of luck - if you document things, I will surely update the guide

posted on April 10th, 2014, 4:33 pm

Code: Select all

For the AI, resource priority appears to be tritanium and then dilithium (with infinite versions of these resources taking the highest priority).

Actually, an emergent effect of the weighting algorithm, not actual priority:

Code: Select all

/////////////////////////////////////////////////////////////////////
// Resource Tendencies:
/////////////////////////////////////////////////////////////////////
// Priority for this AIP to build each type of resource mining bases.
// If you are not Borg, you cannot build metal, and the value will be ignored. Larger numbers make it more likely to build that type of base

Code: Select all

double resource_dilithium_tendency = 1.0;
double resource_latinum_tendency = 1.0;

Code: Select all

// how likely are we to build bases we don't already have

Code: Select all

double resource_lack_multiplier = 0;

So, dilithium and tritanium have equal tendency.
Without explicit reshuffling, AI will always resolve the order in the same way ... so it always chooses Tritanium.

Code: Select all

// How likely are we to build resource bases far from our main base
// ACTUALLY, this is how IMPORTANT it is that a base be close to our main base
// This gets multiplied by the inverse of the distance...

Code: Select all

double resource_distance_multiplier = 0.2;

Obviously this decides between several instances of the same resource, which has already been chosen according to tendency and (hopefully) lack muliplier.

--

Currently testing, whether the parameter is additive, multiplicative or broken and whether placed or finished bases are counted.
- So far, apparently unlike build list items, bases do not count before finished, so the first entries of the build list:

Code: Select all

Way_Better_Build_List_Element the_build_list[MAX_ELEMENTS] =
{
   //Startup
   "kli_chorZ",                1,0, -1,  1,
   "kli_field_yardZ",             2,0, -1,  0,
   "kli_mining_stationZ",          1,1, -1,  0,
   "kli_mining_stationZ",          1,2, -1,  0,
   "kli_mining_stationZ",          1,3, -1,  0,
   "kli_mining_stationZ",          1,4, -1,  0,
[...]

will ignore the parameter.
Or it is broken, that might be it as well.

--

addendum:

Code: Select all

double resource_dilithium_tendency
double resource_latinum_tendency
double resource_lack_multiplier

All three parameters are broken.
The priorities displayed by the AI tool do not change with either small ( [0,5; 1.0] ) or large ( [4.0; 40.0] ) changes.
The lack value is always 0.

Furthermore, the AI tool itself is broken: Dilithium priority is continuously higher than Tritanium priority, yet Tritanium moons are selected. Furthermore, distance to starting point is irrelevant for the selection between resource types.

Whether or when a dilithium moon is selected, seems to depend on starting position: On BlueAmber upper left player built always tritanium-dilithium-tritanium-dilitium, upper right, lower left and lower right player always built 3xtritanium-dilithium.

I assumed a possible conflict with

Code: Select all

// how far away must latinum resource bases be? (to keep them from building
// clusters of mining stations around clusters of nebulas
float cfgRESOURCE_LATINUM_SPACING = 5.0;

but setting it to 0.1 did nothing.

--

Yeah... I can see, why NX seemed such a great idea.