OpenRA Resource Center
Display mission_MasterTables.lua or download file.
Display misc_lua-utilities.lua or download file.
Display user_Events.lua or download file.
Display mission_AIProductionUnit.lua or download file.
Display mission_AIScriptFunctions.lua or download file.
Display mission_SetupAI.lua or download file.
Display mission_Reinforcements.lua or download file.
Display mission_Main.lua or download file.
Display mission_Economy.lua or download file.
Display mission_ActorRegistry.lua or download file.
Display mission_AITeams.lua or download file.
Display mission_Include.lua or download file.
Display user_Reinforcements.lua or download file.
Display mission_AIProductionBase.lua or download file.
Display mission_AIProductionGeneral.lua or download file.
Display user_AITeams.lua or download file.
Display mission_SetupBases.lua or download file.
Display mission_SetupPlayers.lua or download file.
Display user_ScripterOverride.lua or download file.
Display mission_UIDisplay.lua or download file.
Checkout documentation
Description:
VERSION 1.001 - 2017.03.25.0
This is testbed for lovalmidas' Lua-based AI.
A changelog can be read from the package.
Note: WIP.
There is no documentation planned until the code is stabilised. Please stand-by. :)
__________________________________________________
Summary of capabilities:
- Master table to allow redefinition of rules that apply only to AI
- Base Building from base nodes
> Adjustable priorities
> Obey prerequisites defined in Master table
- Unit production from factories
> Adjustable weights
> Parameters to prioritise harvesters
> AI teams take priority over randomised production
> Obey prerequisites defined in Master table
- AI Teams with:
> Condition check prior to team activation
> AI taskforces (types) can be defined and re-defined at runtime.
> AI functions use a set of ScriptFunctions to allow sequential scripts.
> Production is linked to AI teams and/or Pool team
> Defence calls conscript actors from Pool and populating teams.
> AI can actively defend their allies.
Edit map info
Reports of Cold Front + lovalmidas AI test
Lint check for release-20161019
OpenRA.Utility(1,1): Error: Actor e1r1 is not defined by any rule.
OpenRA.Utility(1,1): Error: Actor e1r1 is not defined by any rule.
OpenRA.Utility(1,1): Error: Actor e1r1 is not defined by any rule.
Errors: 4
Lint check for release-20160508
OpenRA.Utility(1,1): Error: Actor e1r1 is not defined by any rule.
OpenRA.Utility(1,1): Error: Actor e1r1 is not defined by any rule.
OpenRA.Utility(1,1): Error: Actor e1r1 is not defined by any rule.
OpenRA.Utility(1,1): Error: Actor e1r1 is not defined by any rule.
OpenRA.Utility(1,1): Error: The map allows 1 possible players, but defines only 0 spawn points
Errors: 6
| Previous revision | Revision | Next revision |
|---|---|---|
|
|
2 |
It's the latest |
Testing performed on playtest-20170304.
A little hard to follow your code but from what I've seen you might need a way to make it more generic so people can extend off it easier. Maybe a clear way to tell the code how to know the difference between the regular Hacky AIs and the scripted AIs.
That said keep up the good work. I'm busy working on my own AI in pieces right now for little help functions. some of the ideas might be helpful. :)
The general idea is to bear a close similarity between my AI and Westwood's AI for the following features:
- AI adjustments and circumvention of yaml rules
- Base building using base nodes
- Base building prioritisation
- Unit production
- Unit production prioritisation
- AI Teams, Taskforces and Scripts (using the RA2 model)
- Reinforcements (the code is present and working, but not used here yet)
- Smart Unit targeting (not yet implemented)
There may be more, but performance issues will likely be the limiting factor to a smart AI.
There will be a documentation planned when the major features are stablised.
Most of the code will be due for a refactoring of some sort for readability and performance after I manage to get the desired logic working. There will also be work on moving 'hardcoded' values to a mastertable for implementation in other mods. Until then, any documentation will be short-lived.
Essentially, the user should only be required to edit a small portion of the lua files.
On HackyAI, I could try to work on pairing the Lua AI with HackyAI for superweapons handling.
However, the Lua AI is currently designed to be independent of any yaml-based AI right now (the Lua AI aims to produce units and builds structures using rules that is derived by separate from yaml rules), so for the most part I do not see them as compatible yet.
hmm maybe you could use the YAML to lessen the amount of Lua needed in some way, Super Weapon handling like you said is one but maybe you could use the build chances and limits for your AI as well, all the while overriding the way the AI builds its bases.
I have to get up to speed on the lua format OpenRA is using though but have my own ideas, I'll see if I can get something posted at some point.
Also you see the Lua Function for telling what tile type is at a given location? Maybe there's a way to make a wrapper around that to make a tile type search function for the AI so it can check where it can get to and with what for transports.
I can greatly reduce the Lua component by sacrificing some aspects of AI customization (which are not yet available in yaml form yet):
- Independent rules for AI (prerequisite / cost / buildtime)
- Base node prioritisation (most adv in YAML follows a strict build order; this Lua can respond to interruptions in the base node order)
- AI teams (there is a build that is developing that now)
- AI teams condition checks with an arbitrary function
- AI teams script functions with an arbitrary function
- AI teams overriding unit production weighting
- AI defending its allies.
Some of these features may become available at the Yaml in future builds, but I will look at those when they are more developed.
If I can make this work, I might take a look at building that logic in C# in OpenRA engine itself.
From what I see currently, it is not yet possible to query the terrain layer (including the overlay layer) using a direct Lua function.
It is also not yet possible to use Lua to fire superweapons (which is one of the reasons I used a Lua/Yaml hybrid in http://resource.openra.net/maps/19901/)
However, I have not yet investigated exposed C# values/functions can be queried on the Lua.
string TerrainType(CPos cell) gets the terrain type at a given location, was thinking of flipping the args and getting it to output a list of coords that have a given terrain type. :)
If TerrainType is as what you describe, it would be easy to populate in a local Lua table by iterating through all the cells in the map once. Then you can use a function to give table[terraintype] as CPos().