LuaAI information

[jK]

Whole chili uses classes and a lot of my newer Lua code, too.
So yes Lua can have classes (more similar with js ones and not c++ ones).

[knorke]

I had a look at S44's AI and it seems it needs quite a lot of stuff that I did not understand to restrict AI to its team/data. Would it be possible to reuse that/how would it be done? It seems cleaner but as I probally can not figure it out on my own I might just go with the teamData[teamID] idea, KP seems to use that too.

[Tobi]

In C.R.A.I.G., approximately here the call-ins are dispatched to different teams and to some global handlers (that run at most once, regardless of how many AIs are in the game).

Each team is a closure as returned by CreateTeam (note: the function spans the entire file!) in team.lua. That is, CreateTeam returns a table with public methods, and the instance variables of the team are private because they live in the closure. That is one of the ways to do OOP in Lua.

[Google_Frog]

Aren't LuaAIs simply an AI definition in LuaAI.lua so that people can add the AIs in the lobby to create a team that can be controlled by a gadget? CAI (zk luaAI) is just a normal gadget that uses Spring.GetTeamLuaAI to detect and handle teams which have been set to use CAI in the startscript. LuaAI can do anything a gadget can do, there is no anti cheating. It can give orders to any team, movectrl, spawn units, change resources... anything gadgets can do. This is fine, there should not be enforced anti-cheating as a simple gadget implementation has the greatest flexibility.

[SpliFF]

I'm still wondering what the technical definition of a 'team leader' is and how it relates to players and physical PCs?

[Tobi]

A player is equivalent with a spring client/instance. So for AI teams the teamleader field simply instructs Spring to run the AI on the PC of that player.

(For completeness: the team that is controlled by the player is given in the "team" field of player.)

See also: https://github.com/spring/spring/blob/m ... Format.txt

[hoijui]

additional note: drawing on the map can only be done by (human) players, not by teams or AIs. so when an AI on a purely AI controlled team wants to draw, the engine actually draws stuff as team-leader. this is only a workaround hack of course.

[SpliFF]

Thinks for clarifying the team leader thing.

Based on the information in this thread it looks like my plan for my AI is acheivable, but I'd like confirmation.

I currently have a widget that provides a "support AI" framework. That is, you run it as a player and it can control your idle units. It's basically a small widget stub with a lot of "framework" include files containing AI functions for transporting, pathfinding, loading plans etc. The include files are all under "LuaUI/Widgets/Metalstorm/"

What I want to do is use the same widget code to provide an "opponent AI (LuaAI)". It sounds like that's quite achievable by creating a LuaAI stub that include()'s the majority of the AI widget files from its unsynced part with a few callin/callout hooks specific to the LuaAI version.

I had originally thought of just communicating with the widget directly but I assume the widget would then be constrained to only seeing units on the team leaders' team instead of units on its own team.

I suppose the main challenge now is to handle the case of multiple AI teams. I'll try to use C.R.A.I.G as a reference looking closely at the closure approach. My widget already uses the local vars MY_TEAM and MS (a table) for most of it's functions and data storage so I only really need to ensure these are unique to each AI team.

[knorke]

LuaAI can do anything a gadget can do, there is no anti cheating. It can give orders to any team, movectrl, spawn units, change resources... anything gadgets can do. This is fine, there should not be enforced anti-cheating as a simple gadget implementation has the greatest flexibility.

The problem is that while it gives freedom to the AI maker it also requires the AI writer to make a framework before actually starting on the AI:

I suppose the main challenge now is to handle the case of multiple AI teams.

and that should imo not be the "job" of the the AI/AI writer but of some AI interface. Do native AIs have to care about this too?

...widget...

What do you use widgets for in the AI? What if the player turns of the widget? Unsynched code can be in gadget too.

[SpliFF]

I'm not going to use a widget for LuaAI, I'm just going to share 98% of the code between unsynced LuaAI and the support widget. That way the two are independent (provided you don't have versioning issues with the shared code files).

[knorke]

still dont understand what you use the widget part for.
Is it so that players can (for example) edit config files for the AI in their local wigets folder without having to unpack,edit,pack the game?

[SpliFF]

The widget is a support AI, it helps a player.

The LuaAI is an enemy AI, it fights the player.

They do NOT communicate with each other at all. They do however load a lot of functions from the same files and therefore work the same way internally. The idea is if I improve the pathfinder both types of AI benefit immediately and I don't have to maintain two sets of code that are 99% identical.

Instead I have two stubs that load the same framework but handle callins slightly differently and hide any other differences between LuaAI and widgets from the framework code.

I did consider the LuaAI talking to a widget originally but realised it would have many issues including accessing full unit data for any team the player running the widget didn't control. I'd basically have to keep passing unit data across to the widget which is very inefficient. The unsynced part of a gadget doesn't have these issues, it just needs some tricks to isolate the teams and that's a problem C.R.A.I.G has already solved.

[AF]

Native AIs do not have to worry about teams, well they do, but every single nativeAI has a piece of code that manages this for them that's near identical.