OpenRA Resource Center

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().