There are no callers in mainline. The functions are not meant to be called directly at all – for each, there are wrapper functions that are intended to be called instead, which are still exposed.
These functions are not used anywhere, and they have other issues besides the one fixed in this commit – they're implied to return all moves, but they only return one move for each possibly destination hex. However, this will make them at least be minimally usable.
I used level 3 deprecation because this is something that was intended for internal use in the ai_helper module, and the ai_helper module itself is not an officially stable API
Nowdays ability.value and similar attributes can also contain formulas
(That for example make a heal amount dependent on the remaining hitpointsthe unit has
)
With this the lua ai code should no longer crash in these cases.
The method used in the battle_outcome() function is somewhat simplified compared to the default engine calculation and faster in the vast majority of cases, but it can become extremely slow when the combined number of strikes of the attacker and defender is very large.
The new method avoids a lot of path finding that the previous method did, esp. on large maps with many units and/or enemies, leading to significant speed improvements in some cases.
This fixes#6504
This fixes#4924. Note, however, that the recruit rushers CA is set up for single-leader sides and does not work with multiple leaders, so this is of limited use.
Many of the operations of the recruit rushers CA are expensive and are therefore cached. For the most part, this cache can be kept from turn to turn, but in case there are events that change, for example, the map or the recruit list, this parameter can be used to force a reset of the cache each turn.
While most data in recruit_data can stay persistent from turn to turn, some of recruit_data.recruit, such as enemy_types, needs to be updated each turn.
This removes the need for the Generic Recruit Engine and makes Recruit Rushers a "clean" candidate action. In the process, it fixes a bug of data leakage between the Experimental AIs of different sides.
The castle switch CA stores the leader move because the evaluation is expensive. If the leader was killed in between storing and reevaluation of the CA, this would previously cause an on-screen error message and the CA to be blacklisted for the turn.
This fixes#6440.
The passed filter needs to be enclosed in an [and] tag, otherwise the check for visibility might not work correctly, for example if the filter contains a top level [or] tag.
The whitespace-fixing script seems to be slightly different depending on the platform.
Even though it produces no effect in the CI, it made these changes locally on my Mac.
I'm committing them now so as to avoid unrelated files being changed in other pull requests.
- Unit formulas are replaced by inline MicroAIs or candidate actions placed in the unit's [ai] tag.
- The stationed_guardian MicroAI was chosen as the closest match to the guardian FormulaAI. It's not a perfect fit, but it's pretty close.
- The goto and patrol MicroAIs are fairly obvious substitutes for the respective unit formulas.
- The priority test in unit formulas is replaced by fairly basic inline non-external CAs with differing scores.
- The side formulas (opening.fai) have been converted to a separate Lua stage using a new opening.lua. However, that's only a partial conversion. The move and attack functionalities of opening.fai are missing from opening.lua; instead the built-in move, move leader to keep, and combat CAs are used.
- The scouting FormulaAI CA has been ported to Lua. It remains a very basic AI, probably not well-suited to genera use.
- The level up attack FormulaAI CA has been ported to Lua. Like the new scouting CA, this is mostly intended to serve as an example.
