The sorian PA AI thread

Or they're turtlers who don't understand why the AI just won't turtle like they do!

Maybe not for this project, but for the next one you need a console so I can what any variable is set to for any AI at any time

I've encountered an issue where a block with personality_tag check is changing the opening of a different personality.

Code:

{
         "name":"Basic Bot Factory",
         "to_build":"BasicBotFactory",
         "instance_count":1,
         "shared_instance_count":"Factory",
         "priority":376,
         "max_num_assisters":5,
         "builders":[
            "Commander",
            "AnyBasicFabber",
            "AnyAdvancedFabber"
         ],
         "build_conditions":[
            [
               {
                  "test_type":"CanAffordBuildDemand"
               },
               {
                  "test_type":"CanAffordPotentialDrain",
                  "string0":"BasicBotFactory"
               },
               {
                  "test_type":"UnitCountPerPlanetRadius",
                  "unit_type_string0":"Factory & Basic",
                  "compare0":"<=",
                  "value0":200
               },
               {
                  "test_type":"CanFindPlaceToBuild",
                  "string0":"BasicBotFactory"
               },
               {
                  "test_type":"HasPersonalityTag",
                  "string0":"bronze",
                  "boolean":true
               }
            ]
         ],
         "placement_rules":{
            "buffer":3,
            "threat":{
               "influence_type":"AntiSurface",
               "compare_type":"<",
               "radius":10,
               "value":50
            }
         }
      },

With this block, the uber personality will open as follows on Forge in slot 2:

factory - assist out fabber - assist fabber to 25% - energy - energy - factory

With this block removed the uber personality will change to:

factory - MEX - MEX - energy - energy - factory

Yet as you can see the block has a personality check on it and should have no impact on the uber personality. No other block seems to have this issue, but I can't see anything special about this one.

Code:

'Uber': {
            percent_vehicle: 0.55,
           percent_bot: 0.1,
            percent_air: 0.2,
            percent_naval: 0.1,
           percent_orbital: 0.05,
            metal_drain_check: 0.52,
            energy_drain_check: 0.65,
            metal_demand_check: 0.72,
            energy_demand_check: 0.8,
            micro_type: 2,
            go_for_the_kill: true,
            priority_scout_metal_spots: true,
            enable_commander_danger_responses: true,
            neural_data_mod: 1.0,
            adv_eco_mod: 1.3,
            adv_eco_mod_alone: 0.85,
            personality_tag: "uber"
        },

All other mods were disabled.

I found if I removed the placement_rules block then the issue disappears.

Code:

{
         "name":"Basic Bot Factory",
         "to_build":"BasicBotFactory",
         "instance_count":1,
         "shared_instance_count":"Factory",
         "priority":376,
         "max_num_assisters":5,
         "builders":[
            "Commander",
            "AnyBasicFabber",
            "AnyAdvancedFabber"
         ],
         "build_conditions":[
            [
               {
                  "test_type":"CanAffordBuildDemand"
               },
               {
                  "test_type":"CanAffordPotentialDrain",
                  "string0":"BasicBotFactory"
               },
               {
                  "test_type":"UnitCountPerPlanetRadius",
                  "unit_type_string0":"Factory & Basic",
                  "compare0":"<=",
                  "value0":200
               },
               {
                  "test_type":"CanFindPlaceToBuild",
                  "string0":"BasicBotFactory"
               },
               {
                  "test_type":"HasPersonalityTag",
                  "string0":"bronze",
                  "boolean":true
               }
            ]
         ]
      },

Yet this placement_rules block is the same one used in the very next block. It's used everywhere.

I'm at a loss, but this is 100% reproducible. I replaced the placement_check with the identical one from the next block just in case, but same issue. What's more, I think this might be a new issue following the most recent patch. I couldn't swear to that though.

My other concern is that while I noticed this issue, perhaps other more subtle issues are leaking in from other blocks.

Silver has a slight variation of this block which causes the same issue.

Code:

{
         "name":"Basic Bot Factory",
         "to_build":"BasicBotFactory",
         "instance_count":1,
         "shared_instance_count":"Factory",
         "priority":376,
         "max_num_assisters":5,
         "builders":[
            "Commander",
            "AnyBasicFabber",
            "AnyAdvancedFabber"
         ],
         "build_conditions":[
            [
               {
                  "test_type":"UnitCount",
                  "unit_type_string0":"Factory & Basic",
                  "compare0":"<",
                  "value0":1
               },
               {
                  "test_type":"CanFindPlaceToBuild",
                  "string0":"BasicBotFactory"
               },
               {
                  "test_type":"HasPersonalityTag",
                  "string0":"silver",
                  "boolean":true
               }
            ],
            [
               {
                  "test_type":"CanAffordBuildDemand"
               },
               {
                  "test_type":"CanAffordPotentialDrain",
                  "string0":"BasicBotFactory"
               },
               {
                  "test_type":"UnitCountPerPlanetRadius",
                  "unit_type_string0":"Factory & Basic",
                  "compare0":"<=",
                  "value0":100
               },
               {
                  "test_type":"CanFindPlaceToBuild",
                  "string0":"BasicBotFactory"
               },
               {
                  "test_type":"HasPersonalityTag",
                  "string0":"silver",
                  "boolean":true
               }
            ]
         ],
         "placement_rules":{
            "buffer":3,
            "threat":{
               "influence_type":"AntiSurface",
               "compare_type":"<",
               "radius":10,
               "value":50
            }
         }
      },

Can you influence the performance of the AI through the order of the tests? For example, is UnitCount more expensive than HasPersonalityTag? Would placing HasPersonalityTag at the top of a block cause it to drop irrelevant blocks faster and thus improve performance?

So I have this check in a factory file

Code:

               {
                  "test_type":"UnitRatioOnPlanet",
                  "unit_type_string0":"Fabber & Air & Basic",
                  "unit_type_string1":"Factory & Air & Basic",
                  "compare0":"<",
                  "value0":10
               },

In a 8 AI game on Amplus, this check appears to cause some severe spikes in the factory manager from around 11min (sometimes later) onwards. If I drop value0 to something like 1 then the issue appears to go away (or it might just happen much, much later).

As you can see from these screenshot the unit count is pretty low.

The shot on the left is with value0 10 and the one on the right is value0 1.1



On the other hand, given the spike in fabber manager I wonder if this isn't just a big coincidence, or is this check using fabber manager somehow.

Yet if I leave in all the Queller files except the factory_ files then the issue goes away, it's only once I introduce bronze_factory_air, bronze_factory_land, silver_factory_air and silver_factory_land that the issue returns. I suspect the naval files would cause the issue too if the AI entered the water more reliably.

Can the tests be ordered to put cheaper ones first, or does the order in the files not reflect how they're processed in-game?

Great! Also, balls.

On that note, is placement searching cheaper or more expensive than unit counts? I'm going to assume the default AI is optimally ordered.

Surprised to see the CanDeployLandFromBase and CanDeployNavalFromBase checks low lower than everything but placement checks. My assumption was these would be incredibly cheap to query and would be a flag set against a base ID (since it seems to be set when enemy units are spotted), rather than being something that's actually checked on test.

I think this should be called sorian and quitch thread

A couple of questions about platoons:

Do the limits defined in the platoon_templates file matter after the platoon has been formed i.e. will a large platoon never have more tanks in it than its max? Does dipping below its minimum after creation do anything?

Given that you can define your minimum requirements for troop numbers when forming the platoon in platoon_builds, is there any reason to set the minimums in platoon_templates to anything other than 0?

Also, the Commander never ubercannons when on the way to a build job.

@Sorian Random inquiry: Have you tried recurrent neural nets at all?

So I reordered all of Queller to minimise test checking and to keep it cheap (that was tedious ). I think the fabber manager spikes were because the low end personalities had more fabbers than they could use, which presumably was causing it to continuously run through the checks over and over for all these idle fabbers. I solved that by adding a catch-all at the end to keep them busy. Seems to have done the trick.

Now I just need to figure out why one personality always opens air, when it shouldn't and even shares the same air files as personalities which don't (I'm hoping just a cock-up assignment somewhere). Also why those placement checks in one personality appear to be causing another personality to change its opening. I must admit, that one has me scratching my head because I can see the behaviour change as I remove and replace the placement check, but it should have nothing to do with anything.

It appears to be the buffer value. If it's 3 then you get the factory into assist behaviour, if it's 4 or higher than you get the factory into MEX behaviour. It shouldn't impact the uber personality at all because as you see it has a HasPersonalityTag test. If I remove the file and leave the uber file behind (which also uses a buffer of 3) then I get the expected factory into MEX opening..