Micro AIs Feedback and Development

[Lord-Knightmare]

Fixed the first one myself, found the next bug:

[beetlenaut]

A suggestion for the coward AI: attack_if_trapped=yes

If a coward has moved as far as possible and is still adjacent to an enemy, it is probably trapped. I would like to see it fight in that situation (like most cornered animals will do).

[mattsc]

A suggestion for the coward AI: attack_if_trapped=yes

If a coward has moved as far as possible and is still adjacent to an enemy, it is probably trapped. I would like to see it fight in that situation (like most cornered animals will do).

I like that. I'll take care of it shortly (after a bit more work on Fred...).

[beetlenaut]

I found a bug in simple_attack:

The hexes it is trying to use are not adjacent, so there is a good reason why the attack was not executed! This happened when an AI unit was unable to move, and the only adjacent units were its own.

Edit: I got the same error with zone_guardian as well under very different circumstances. It seems to involve a tunnel this time. The tunnel connects a trap door on the top level to stairs on the bottom. The attached save file is for this one. Just end the turn to see the errors.

[mattsc]

I found a bug in simple_attack:
The hexes it is trying to use are not adjacent, so there is a good reason why the attack was not executed! This happened when an AI unit was unable to move, and the only adjacent units were its own.

Hmm, do you have a save file of that situation? The simple attack MAI makes units move out of the way for attacks, and it checks whether that is possible, in principle, but it doesn't try to move units out of the way of the unit moving out of the way. Also, there are situations when, theoretically, units can move out of the way of each other, but in practice they cannot. Depending on the situation, there are solutions of different complexity. The simplest way would be to see if the unit that's supposed to attack actually got to where it's supposed to get, and if not, don't try to attack. But that's not ideal, of course ...

Edit: I got the same error with zone_guardian as well under very different circumstances. It seems to involve a tunnel this time. The tunnel connects a trap door on the top level to stairs on the bottom. The attached save file is for this one. Just end the turn to see the errors.

I tried to load this but get lots of "illegal tile" errors. I tried to hack into the save file, but there're too many terrains it does not recognize. This is with the version of SotA from the add-ons server. Did you produce this with a more recent version that has new terrains?


Also, FYI, I've added the attack_if_trapped= key to the Coward MAI.

[beetlenaut]

I tried to load this but get lots of "illegal tile" errors.

Sorry, my fault. I shouldn't have been working on this at 3:00AM. What I was actually testing was a bunch of new terrain and graphics. I modified the save files to use functionally equivalent tiles, and tested them with the version of SotA that is on the server. I don't see any reason it shouldn't load now. The tunnels aren't well marked, but the one that may be causing the problem goes from 14,6 to 14,14. I found an autosave with the first situation too.

[mattsc]

I tried to load this but get lots of "illegal tile" errors.

Sorry, my fault. I shouldn't have been working on this at 3:00AM. What I was actually testing was a bunch of new terrain and graphics. I modified the save files to use functionally equivalent tiles, and tested them with the version of SotA that is on the server. I don't see any reason it shouldn't load now. The tunnels aren't well marked, but the one that may be causing the problem goes from 14,6 to 14,14. I found an autosave with the first situation too.

So I fixed the problem with the Simple Attack MAI. As expected, the reason was that the units thought they had hexes to move to (because hexes occupied by units on the own side count as such), but in practice that was not possible because all of the reachable hexes were occupied. And since this was a bug, it's fixed in both 1.11/1.12 and 1.13.

As for the problem with the tunnel, I am not sure if that is a problem with the Micro AI. If I droid side 2 and try to move units through the trap door, it works just fine. However, when the AI does it and there's an AI unit on the other side of the tunnel (as is the case in beetlenaut's save), I get this:
Error #2006 (E_FAILED_TELEPORT) in full move by side 2 from location 14,6 to location 12,14
You can see that the unit on the far side of the tunnel is the problem by debug-killing the unit on 14.4. After that, the MAI works just fine.

To be honest, I don't know how to go about this at the moment. I think it is clearly a bug, and it looks like it's a bug in the AI (since it works if the player takes control), but I don't think it's a bug in the Micro AI code.

Edit: Correction: the problem also occurs when the side is controlled by the player. We get a big red "failed teleport, exit not empty" on the screen then.

[beetlenaut]

it's fixed in both 1.11/1.12 and 1.13

Great! Thanks.

I don't think it's a bug in the Micro AI code.

I guess not. I'm aware of that problem with tunnels because it affects the player's units too, and I think it's an engine bug. I say, "I think," because it was clearly programmed this way on purpose, but it shouldn't have been IMO. This is just another reason why. Fixing this AI problem will probably require fixing the tunnels, so I'll write a bug report for that. I've been meaning to anyway.

[doofus-01]

Hi,

If I assign a goto micro_ai to a unit, but there is no path for it to reach the target location, would it cause an error like this?

20140727 20:46:07 error scripting/lua: ...l/share/wesnoth1_11_15/data/ai/micro_ais/cas/ca_goto.lua:203: attempt to index local 'closest_hex' (a nil value)
stack traceback:
...l/share/wesnoth1_11_15/data/ai/micro_ais/cas/ca_goto.lua:203: in function 'execution'
[string "wesnoth.require("ai/micro_ais/cas/ca_goto.lua..."]:1: in main chunk

It could be something else, I'm not sure if it is a bug with micro_ai or (more likely) a bug with my own crap. But I wanted to ask, because it looks like the best explanation to me at the moment.

Thanks.

20140729 EDIT: Checked it out a bit more, and "no path" does seem to be the cause. Not sure if that qualifies as a bug, or just bad usage on my part.
20140802 EDIT: "No path" also seems to occur if the destination is blocked by enemy units? That does seem like a bug, if it's true...

[mattsc]

Hi doofus-01,

Thanks for reporting this and sorry for the slow reply, I've been away for the last two weeks. Yeah, this is a bug I apparently introduced a while ago when I was cleaning up the code. I cleaned up a little too much ...

It should be fixed now for 1.11.17 and master. If you want to test it before then, since this is Lua-only code, you can simply take the file from here and replace data/ai/micro_ais/cas/ca_goto.lua with that. That should work both in 1.11.16 and master, the file is identical in both versions. Hopefully that will fix your problems.

A couple more comments:

20140729 EDIT: Checked it out a bit more, and "no path" does seem to be the cause. Not sure if that qualifies as a bug, or just bad usage on my part.

Personally, whenever a Micro AI produces an error message visible on the game screen,* I consider that a bug unless it is caused by completely inappropriate use of the [micro_ai] tag -- which this is not at all, in particular because:

20140802 EDIT: "No path" also seems to occur if the destination is blocked by enemy units? That does seem like a bug, if it's true...

Yes, the path-finding code considers hexes occupied by enemy units unreachable. So this definitely needed to be fixed!

Thanks again for reporting, please keep doing so!


* This is much more than a visual annoyance. It generally means that the AI, or at least the current CA, is stopped for the remainder of the turn and the default AI takes over.

[Lord-Knightmare]

Found two new bugs while experimenting with Micro AIs:

[mattsc]

Hi Lord-Knightmare,

Thanks for reporting. It's a little hard for me to say what's going on here just from the error messages without additional information, in particular for the Wolves MAI. I'll look into that some more to see if I can think up a situation that would cause that error (looking at the code, this should not happen, but obviously it does somehow). If you have a savefile for which this happens reproducibly, that would be very helpful.

The error in the Protect Unit MAI looks like an incorrectly defined input parameter rather than a bug in the MAI, as the error is complaining about the value of the goal_x= key. What is the WML code you use to define the MAI?

Thanks.

[Lord-Knightmare]

Hi Lord-Knightmare,

Thanks for reporting. It's a little hard for me to say what's going on here just from the error messages without additional information, in particular for the Wolves MAI. I'll look into that some more to see if I can think up a situation that would cause that error (looking at the code, this should not happen, but obviously it does somehow). If you have a savefile for which this happens reproducibly, that would be very helpful.

I just copy/pasted the one from the micro_ai wiki page and edited the side number to match the one where I have defined the wolves.
I will PM you the save files and the links to the required scenario files.

The error in the Protect Unit MAI looks like an incorrectly defined input parameter rather than a bug in the MAI, as the error is complaining about the value of the goal_x= key. What is the WML code you use to define the MAI?

Thanks.

This was from a boss-scenario. I was trying to make the boss unit chase after Jahin (protagonist of TLB and HoI). I later replaced it with messenger_escort MAI and making the leader go on a route throughout the map. I also added hunter MAIs to Skeletal Dragons and Ancient Lichs (got screwed in the boss-scenario).

[Lord-Knightmare]

Sorry for the double post, but I found another bug:

Code: Select all

#        {ai/aliases/stable_singleplayer.cfg}
#        [ai]
#            version=10710
#            [engine]
#                name="lua"
#                code= <<
#                    local ai = ...
#                   return wesnoth.require("ai/micro_ais/engines/priority_target_engine.lua").init(ai)
#                >>
#            [/engine]
#            [modify_ai]
#                side=2
#                action=add
#                # wmllint: unbalanced-on
#                path=stage[main_loop].candidate_action[]
#                # wmllint: unbalanced-off
#                [candidate_action]
#                    engine=lua
#                    name=change_attacks_aspect
#                    id=change_attacks_aspect
#                    max_score=999999
#                    evaluation="return (...):change_attacks_aspect('Jahin')"
#                    execution="(...):change_attacks_aspect()"
#               [/candidate_action]
#           [/modify_ai]
#        [/ai]

Whenever I include these lines in my scenario, I get the following message:

I copied it directly from the micro_ai protect_unit scenario file, just changing the ID of the Elder Mage to that of Jahin's.

[mattsc]

Actually, the problem here is with code you do not show. The error messages complain about Micro AI CAs, so I assume you are also using MAIs for the same AI side? That doesn't work, because of the way how the C++ code parses and sets up AIs.

'Technical' reason for those interested

There are two ways to set up AI candidate actions. The "old" method (still works though and is perfectly fine to use) of defining an engine which contains all the CAs. And the new method of using individual external CA files. The code posted by Lord-Knightmare uses the engine method, the MAIs use external CAs so that they can be combined at will. Because of the internal mechanics of the Wesnoth AI, these two methods cannot be mixed.

So if you want to use this functionality, you need to convert the 'Priority Target' AI to using external CAs as well. For that, you need to create a new external CA file in your add-on (same AI code, but different structure):

Code: Select all

local H = wesnoth.require "lua/helper.lua"
local W = H.set_wml_action_metatable {}
local AH = wesnoth.require "ai/lua/ai_helper.lua"

local ca_priority_target = {}

function ca_priority_target:evaluation(ai, cfg)
    -- Set 'attacks' aspect so that only unit with id=@cfg.target_id
    -- is attacked if it can be reached, delete aspect otherwise

    local attackers = AH.get_units_with_attacks {
        side = wesnoth.current.side,
        canrecruit = "no"
    }

    local attack_locs = {}
    for _,attacker in ipairs(attackers) do
        -- Need to find reachable hexes that are
        -- 1. next to target
        -- 2. not occupied by an allied unit (except for unit itself)
        W.store_reachable_locations {
            { "filter", { id = attacker.id } },
            { "filter_location", {
                { "filter_adjacent_location", {
                    { "filter", { id = cfg.target_id } }
                } },
                { "not", {
                    { "filter", { { "not", { id = attacker.id } } } }
                } }
            } },
            moves = "current",
            variable = "tmp_locs"
        }
        attack_locs = H.get_variable_array("tmp_locs")
        W.clear_variable { name = "tmp_locs" }
        if (#attack_locs > 0) then break end
    end

    -- Always delete the attacks aspect first, so that we do not end up with 100 copies of the facet
    W.modify_ai {
        side = wesnoth.current.side,
        action = "try_delete",
        path = "aspect[attacks].facet[limited_attack]"
    }

    -- Also delete aggression, caution - for the same reason
    W.modify_ai {
        side = wesnoth.current.side,
        action = "try_delete",
        path = "aspect[aggression].facet[*]"
    }
    W.modify_ai {
        side = wesnoth.current.side,
        action = "try_delete",
        path = "aspect[caution].facet[*]"
    }

    -- If the target can be attacked, set the attacks aspect accordingly
    if attack_locs[1] then
        W.modify_ai {
            side = wesnoth.current.side,
            action = "add",
            path = "aspect[attacks].facet",
            { "facet", {
               name = "ai_default_rca::aspect_attacks",
               id = "limited_attack",
               invalidate_on_gamestate_change = "yes",
               { "filter_enemy", { id = cfg.target_id } }
            } }
        }

        -- We also want to set aggression=1 and caution=0,
        -- otherwise there could be turns on which nothing happens
        W.modify_side {
                side = wesnoth.current.side,
                { "ai", { aggression = 1, caution = 0 } }
        }
    end

    return 0
end

function ca_priority_target:execution()
end

return ca_priority_target

and include it in your scenario like this (changing the path to the file, of course):

Code: Select all

        [ai]
            {MODIFY_AI_ADD_CANDIDATE_ACTION 2 main_loop (
                [candidate_action]
                    engine=lua
                    name=priority_target
                    id=priority_target
                    max_score=999999
                    location="some_path/ca_priority_target.lua"
                    eval_parms="target_id = 'Jahin'"
                [/candidate_action]
            )}
        [/ai]

Hope that helps.