This is now possible because the [value] tag in recruitment_instructions has become optional.
Thus, any valid old recruitment aspect is also a valid new recruitment_instructions aspect.
This is mainly so that they are easily identified in the AI components overview in the gamestate inspector,
but it can also be used with [modify_ai]. (It replaces the previous use of * for this.)
Also some minor syntax simplifications:
- If no [recruit] tag is provided, a default is added (as if with importance=0 and no other attributes)
- [pattern] and [total] tags expand to [recruit] with the attribute of the same name set to yes
- Facets no longer have to be standard aspects - they can be lua aspects or even a nested composite aspect
- Ensure aspect tags from simplified aspect contain name=composite_aspect (normally not a problem, but could be in some unusual cases)
- Merge default aspect tags instead of simply taking the first one
- Fix crash that occurred if a composite aspect somehow lacked a default (an unusual case, but not impossible)
- Fix Lua aspects
- Fix simple Lua aspects (with value= instead of code=) quoting numeric values
- Ensure Lua aspects always have name=lua_aspect and standard aspects always have name=standard_aspect
- A few additional [modify_ai] cases:
- aspect[id].facet[*] matches the default facet; this facet can be changed but not deleted, and if it's composite, subfacets can be referenced
- action=change works on aspects (with path=aspect[id]); requires the new aspect to have matching id= key
- aspect[id].facet[id].facet[id] etc works in the case of more deeply nested aspects (or even aspect[id].facet[*].facet[id])
This changes the following:
- Fixes the experimental AI, without changing any of its code except for that in the [engine] tag
- Returns a dummy self from the dummy Lua engine, so that external CAs are more easily switched to using [params]
- Changes the order in which parameters are passed to AI component code. The order is now:
state/self, params, data
I've done this avoid giving the illusion that it merely loads another composite AI definition by its ID.
It can, of course, still be used to do so, if that's really what you want, but normally it should not be needed.
The advantage of this over the get_* functions is that it will automatically
update whenever new aspects are added.
It doesn't support the deprecated recruitement aspect.
This commit potentially breaks any Lua AI customization, except for external Lua candidate actions.
In practice, though, Lua aspects and goals will probably continue to work for the most part.
- The ai table now has a read_only attribute.
If true, functions that change the game state will be missing from the table.
The read_only attribute is false in CA execution and in stages.
It is true everywhere else.
- Every Lua AI component now supports a [args] subtag.
The contents of this tag are passed as parameters to the component code.
This data is immutable; components cannot alter its contents.
(External Lua candidate actions do not receive this data.)
- Accessing the persistent engine data is now supported in all Lua components.
When calling a Lua component, the Lua engine now passes two parameters:
1. The contents of the [args] tag in the specific component.
2. The contents of the [data] tag in the Lua [engine].
The return value of the [engine] code, if any, is stored for later used.
It will be passed as the third parameter to any other Lua component.
This data can be changed, but will not be saved.
The default engine does not return any such data.
