Why The New Interface?

[DJ]

it would be easy to have cmake build a MetalSpotFinderAlgorithm.dll, if that is all you want.

LUA can already call dlls I believe, everything that is needed is there.

Before I ask stupid questions is there a discussion on exactly what techniques in Lua are causing the issues for AI's at the moment?

[DJ]

Quote:
Sure placing mexes is easy if you have a spot finding algorithm, pick an unclaimed mex and build. Or is it? Lets try to improve that. What if tis cheaper to build a metal maker? etc.
That is precisely the kind of problem game designers should be handling, not AI developers. We need fast core algorithms for the difficult problems, but we should be responsible for how that information is handled.

would that not be very slow / complicated if done in Lua? Even NTai/ AAI don't have path finders. That is precisely the kind of problem that AI developers like...

[Argh]

what techniques in Lua are causing the issues for AI's at the moment?

Well, let me give some examples from P.U.R.E.:

1. Custom commands. AIs simply don't see them, cannot be told to use them, period.

2. Custom resources, or economic models that go outside the OTA box. Ditto.

3. Cannot handle "unusual" situations correctly. For example, the Resistance side in P.U.R.E. spawns three units at game start, and none of them can build a "mine". No AI can even figure out how to start playing it, because they're all designed so narrowly for the OTA case.

These are just a few typical examples, I could get into specifics but basically you can see what huge gulfs exist between what's possible game-design-wise, and what AIs are actually capable of handling correctly.

would that not be very slow / complicated if done in Lua?

Well, no. The way I see it, you'd use Lua to:

1. Figure out that you need Metal. Simple math.

2. Call to an AI DLL, asking it for the nearest available metal spot (probably during game start, Lua also needs to call that DLL and ask it to make its initial map).

3. Give an order to the nearest builder, telling it to build a Mine next, at the location returned by the AI DLL. If we want to check for nearby enemies, etc., we can do it now, in Lua.

Nothing complicated, Lua-wise. The difficult part is, obviously, the metal-map part.

[DJ]

sorry to be thick but can you give me an example of a few custom commands? I'm trying to get a handle on this whole thing because i'm sure it shouldn't be as difficult as all this.

For custom resources do you mean resources that need to be built on a specific area of the map? If so how are they defined (by position and type).

Cannot handle "unusual" situations correctly. For example, the Resistance side in P.U.R.E. spawns three units at game start, and none of them can build a "mine". No AI can even figure out how to start playing it, because they're all designed so narrowly for the OTA case.

AF did start to try and address this sort of problem with his config based AI. A model i still think has legs even if the implementation never really matched the quality of the idea.

[AF]

To make it possible for Lua<->AI communication to occur, you just need a new callout for Lua (Spring.LuaToAI, or whatever), with something like these parameters: DLL name, arg1, arg2, arg3 ... etc., where it is expected that one knows the required arguments and their values for a valid argument (i.e., it's documented with the AI DLL).

There's nothing fundamentally terrifying about this- Lua's just a way to communicate with Spring. Spring can already pass information to-->from AI DLLs, so I would not think that this represents a fundamentally difficult problem, except that obviously AIs would need to be designed to expect incoming messages and to act (or not) accordingly.

There is no documentation of sufficient explanation to actually explain how it works. Assumed knowledge is rampant.

However this does pose an issue. If I have 10 NTais, they would all use NTai.dll, how would I distinguish messages? Would lua have to apss a team number? hmmmm, if you can provide an example that would be most helpful. Once we know the mechanism by which to send messages, things should quickly mvoe fromt here.

You see we are in a much bigger predicament than you ever realized. We, constrained by the old interface and the problematic build environment and the long winded complicated chain needed to actually build a working binary, ended up with a near dead AI community here.

Whatsmore you misunderstand the focus of AI development here. AIs in the spring community do not add support for lua simply because none of us know how, and those who do have not told anyone else.

This couple with the huge strain of actually developing for those we currently do support results in a gigantic motivational drain, and a lot of stress. This is why AIs like KAI and NTai and AAI are no longer being driven by competitive development. It is harder to develop for the sake fo develop now than it was to develop in competition with other developers when it first started. There is little to no payoff for doing anything, and it is not enjoyable.

Its nothing to do with our priorities in AI development, its to do with whether we develop at all, and what we are capable of doing. We didn't choose to abandon lua mechanics, we simply did not have the tools to embrace it, and when we were finally given them, there was no explanation, just an obscure function in the API that made little sense.

If trepan had included a small hello world style example when he made his svn commit, we would likely already have full P.U.R.E AI support by now for the last 6 months from multiple AIs.

[Argh]

sorry to be thick but can you give me an example of a few custom commands? I'm trying to get a handle on this whole thing because i'm sure it shouldn't be as difficult as all this.

Sure thing. One simple example is the Resistance Biketank unit in P.U.R.E.- it can drop a mine one time (and one time only) by passing a command to Lua via the UI command interface (i.e., it uses a standard "button", not a custom UI element).

AIs can't currently be told that such things exist, let alone be programmed for when to use them

For custom resources do you mean resources that need to be built on a specific area of the map? If so how are they defined (by position and type).

No, I'm talking about third, fourth, etc. resources, resource systems that do not use any Spring code at all (all done in Lua alone), etc.

Heck, in P.U.R.E., even without a third resource and just good old Metal and Energy, AIs cannot play Resistance, even if I give them units, because they cannot be told that capturing certain objects is the main way that Resistance grows its economy.

AF did start to try and address this sort of problem with his config based AI. A model i still think has legs even if the implementation never really matched the quality of the idea.

Yes, I agree, he gave it a go, and it 'works', as he puts it. However, since that time... the fundamental model for how games are being designed for Spring has changed, and I no longer think that this model is flexible enough to accommodate what can be done, frankly. It'd just have to have endless cases, basically, and would probably become an unmanageable, unmaintainable mess.

There is no documentation of sufficient explanation to actually explain how it works. Assumed knowledge is rampant.

However this does pose an issue. If I have 10 NTais, they would all use NTai.dll, how would I distinguish messages? Would lua have to apss a team number? hmmmm, if you can provide an example that would be most helpful. Once we know the mechanism by which to send messages, things should quickly mvoe fromt here.

Yes, it would have to pass a team number, I would assume that's usually going to be the first argument.

If trepan had included a small hello world style example when he made his svn commit, we would likely already have full P.U.R.E AI support by now for the last 6 months from multiple AIs.

Hello world for ... what? What do you want to know how to do, exactly? What's the giant mystery?

[hoijui]

what you want, Arg, is already possible with LUA (eg, the chicken AI) and it is best done by Game devs, as it is simple and they know their game.
so why do you want us to shift to that?
it is possible already, it is best done by game devs, it needs no AI devs, ... ???
it seems, the only thing you need are some AI specific algorithms compiled into shared libraries

and again: why do you think my view is absolutely wrong, and yours (the content dev view) is absolutely right?

Moreover, I think that for those of you looking at your papers or presentations in the future... what's going to be more impressive to a future employer- demonstrating that you made an AI that plays one particular game well, or demonstrating that you've constructed a framework that could be redirected to many game designs? If I was an employer, I'd be a lot more interested in the latter, because of what it says about how you think strategically- solving today's problem whilst developing technology that can be used for tomorrow's.

the thing is, that your solution/idea will result in AIs that are only capable of playing one game, whereas the current solution lets AI support multiple games; dynamically. it just does not work because of lack of LUA support in the interface.

Well, obviously this is my POV as a game designer. I have nothing against AI research, per se, I simply think that if it is not addressing the practical needs of players and game designers, then it's not actually interesting, and moreover the research value is a lot greater if you can show that it actually solved a real need.

this is wrong. you are just describing AI research from a game designers point of view.
I agree, that if you apply for a job at a games company, what they most care about may be how many users were attracted to spring because of your work. But this is of minor interest in terms of AI research.

An idea:
We could have an AlgorithmInterface.
A simple C interface, that will be given the same callback like Skirmish AIs, optionally. this could be wrapped in different languages aswell, and could be called directly by the engine, from LUA or from skirmish AIs.
I didn't put any though into it, but it seems like this is what you want Arg, no?

[DJ]

Quote:
sorry to be thick but can you give me an example of a few custom commands? I'm trying to get a handle on this whole thing because i'm sure it shouldn't be as difficult as all this.
Sure thing. One simple example is the Resistance Biketank unit in P.U.R.E.- it can drop a mine one time (and one time only) by passing a command to Lua via the UI command interface (i.e., it uses a standard "button", not a custom UI element).

ignoring the fact that laying mines intelligently would require some serious thought we need to find a way to let an AI know that this item can be built and I assume that that when its built using lua it is simply spawned so we'd need to find a way for the AI to let lua know the decision to build it had been made. If this communication already exists (all be it in an undocumented state) its not a giant leap to get this to work in a config based AI. However for a generic AI to work there has to be a level of abstraction available that is a balance between writing huge amounts of AI code to cover every eventuality and not restricting the flexibility of what can be achieved.

In very loose terms lua could simply notify the ai at the start with a variety of additional build options. Those build options would have to fall within categories or types the AI is familiar with (mines for instance would require special code to be useful) however a lua based icbm launcher could potentially inform an AI that it has a weapon of that type available and for relatively little code the ai could use that nuke in the manner it normally does (save for the fact it would call lua to launch it).

I guess it boils down to whether having types in this way would stifle what you could achieve, the ai developers would then have to decide which types the supported.

No, I'm talking about third, fourth, etc. resources, resource systems that do not use any Spring code at all (all done in Lua alone), etc.

extra resources that don't involve map positions shouldn't be that hard at all, however again there would have to be an interface for notifying the AI of the different resources. I assume the engine knows nothing about those additional resources so again an additional interface would be required.


Looking at this i think that to do the AI job properly (read "smart" ai's) we either need an additional interface for AI comms to lua with a level of abstraction not just a callAI(endless args) method. Or the AI interface would be modified to try to hide this complexity from the AI using it.

To get something to work you could just ask for a metalspot.dll or whatever you need and i'm sure one of us will be able to create one you can then call in lua.

[Argh]

Looking at this i think that to do the AI job properly (read "smart" ai's) we either need an additional interface for AI comms to lua with a level of abstraction not just a callAI(endless args) method. Or the AI interface would be modified to try to hide this complexity from the AI using it.

Well, the way I was thinking... Lua would serve as go-between for different DLLs.

Basically, I see a concept of an AI that is a sum that's greater than the parts. You don't need to use a one-language, size-fits-all approach, at that point, you just need some basic methods for binding it together with Lua serving as the "glue".

This is how DoW AIs work, btw. DoW's engine contains functions to do certain things that Lua would be very inefficient for, or that require a lot of direct access to engine-side information. But Lua does the basic decision-making logic.

Moreover, this feeds perfectly into Hoijui's POV. AI developers could concentrate on the kinds of problems they actually want to solve, instead of spending a lot of their time writing boring code to actually make things happen and run the circus.

it seems, the only thing you need are some AI specific algorithms compiled into shared libraries

Pretty much, yes, and a method to communicate with them. That's the whole point I've been trying to drive home here- with Lua to serve as a binding agent, it's no longer necessary for an AI developer to make all of the parts of their AI. They could make one new algorithm to do a particular task, and plug it into an existing framework.

Game developers would pick and choose which DLLs they actually need, to get the job done, instead of the current approach, where either the AI works, or it doesn't, and that's all there is to it, and we game developers have absolutely no input that we can make, besides whining and then being told that we should learn yet-another programming language, study your specialty, which is rather arcane stuff, and do it ourselves from the ground up.

Considering how many languages and sub-languages and weird things I have to know, just to function as a game developer, that's a bit unrealistic, frankly.

[imbaczek]

Game developers would pick and choose which DLLs they actually need, to get the job done, instead of the current approach, where either the AI works, or it doesn't, and that's all there is to it, and we game developers have absolutely no input that we can make, besides whining and then being told that we should learn yet-another programming language, study your specialty, which is rather arcane stuff, and do it ourselves from the ground up.

That's rather optimistic. You see, writing a decent AI is hard (read "hard for a hacker", not "hard for a game designer and/or content creator or ordinary developer") if you've got the building blocks ready, and very hard otherwise. There's a reason AI is handled by separate developers in commercial games. Every game that has it's own mechanics implemented in Lua will require specific handling which the building blocks you want won't cover, which means you'll have to write them yourself or have somebody do it. Not much improvement from what we have today.

The way to go is to get somebody who knows what he's doing interested in writing a custom AI for your mod, be it PURE, SWIW or *A. There's no other way to have a believable AI, unless you count chickens as one, which you shouldn't and don't.

[AF]

But that inevitably takes AI architecture and puts it firmly in lua land under your control, something that is very important. This can impede development of more advanced behaviors by impeding the ability to cooperate different parts in a specific manner, they have to be designed for the lua end. All in all its a flexibility drain.

Its also a performance drain, I think while its perfectly possible to implement using the existing mechanisms, we shouldnt re-invent the AI interface to add yet another layer between AIs and the engine via lua gadgets.

Anything your expecting the end user to do your also expecting AIs to do. Keep that in mind. Maximum flexibiltiy and modularity is very important with regards to AI development, and while tis easy to start it gets harder and ahrder as performance of gameplay improves

[submarine]

You see, the AIs simply 'worked' for TA based games within a week or two of the first two AIs, JCAI and NTai, yet we somehow improved them and made them play better.

Sure placing mexes is easy if you have a spot finding algorithm, pick an unclaimed mex and build. Or is it? Lets try to improve that. What if tis cheaper to build a metal maker? What if the mex spot is in a contested zone and thus not worth the investment because there's a big army currently walking through it. What about enemy bases inbetween you and the spot? Should we ...

+1

Though AF and I usually disagree on a lot of issues, this time I really have to thank you, AF :)


Apart from that it is difficult or sometimes maybe even impossible to take some of the more advanced AAI algorithms, they simply wont work when being taken out of their "context" (dont know how to properly explain my thoughts in english )

[Argh]

There's no other way to have a believable AI, unless you count chickens as one, which you shouldn't and don't.

Point being, "don't". Seriously, it's not "smart"... but who cares?

But that inevitably takes AI architecture and puts it firmly in lua land under your control, something that is very important. This can impede development of more advanced behaviors by impeding the ability to cooperate different parts in a specific manner, they have to be designed for the lua end. All in all its a flexibility drain.

How is that a flexibility drain? Explain yourself a bit more, that seems like dodging the question entirely. Lua's speed is irrelevant, if it's not being used for the really processor-intensive tasks, and it's not that much slower than C++, as it's compiled at runtime. This isn't JavaScript.

The way I see this working is pretty straightforward:

1. AI developer develops method to determine best location to place a structure of a given size and type, given arguments.

2. Lua developer says, "hey, that seems like a useful function for my AI to use, I'll hook it into my existing framework and try it out, and if the results are good, I'll keep it".

Now all that needs to happen is that the DLL exists, that the callout can be performed from the Lua side, and that the arguments are documented. Voila, one of those nasty, expensive tasks that, as imbaczek puts it, is "hard for hackers" is available for non-hackers to plug in and use.

Currently, this kind of thing is utterly impossible. AIs might as well be black-box, are utterly inflexible, and cannot be made responsive by their designers without overhaul of large portions. This is good design? Well, sure, from a speed standpoint, I'm sure it is... but in the end, speed isn't everything.

So what I'm saying is, "make it possible, and design for it, and you will see a lot more AI development get done on the practical end, while encouraging people who want to build theoretical work". IOW, it's a marriage of everybody's self-interest. Instead of writing game-specific code, AI developers can write the stuff they're actually interested in.

As it is right now, I can't be bothered to bug an AI developer to customize an AI for P.U.R.E., and have no intention of doing so in the future- it's too different from an OTA mod for me to want the existing AIs cleaned up a bit, and yet those are the only ones extant, so it's a null for me to bother. This paradigm needs to shift, or pretty soon AI development will just be for theorists, and will have nothing to do with what the rest of us are doing around here, which is building kickass video games.

[imbaczek]

what I meant when I said "hard for hackers" is that writing AIs is hard if you've already got those magic DLLs. it's impossible to have silver bullet DLLs for AIs because each and every game will be so different that a DLL made for one game will be next to useless for another, just like it is now with AIs. there's a possibility that a _very_ generic library could work with all games with some skilled shoehorning, but the result will suck due to "if it works with everything, it sucks at everything".

if what you envision is something like the current widget system for AIs - that is, put some files like TAResourceAI.lua, BattleGroupAI.lua and MicroJeffiesAI.lua and it'll Just Work(tm), you're asking for something that hasn't been done yet. not only in spring, but at all, and for good reasons. (actually, those files could work, but changing TAResourceAI.lua to, let's say, StarcraftResourceAI.lua without heavily modifying logic elsewhere is pretty much impossible.)

[AF]

Argh, lua is compiled but not in the sense you think.

Lua is compiled into bytecode
C++ is compiled into machine code

Lua runs inside a virtual machine
C++ runs directly on the cpu.

There are also costs involved with lua<->c++ communication.

What's more these simple individual actions you say lua can do may seem fine standalone but they can be recombined into complex strategies that are greater than the sum of their parts. Coordination is very important, and its not a good idea to box algorithms in on their own based on context.

If you look back at the threads and cocnepts in these forums, and i shall use my own as an example, it would be impossible to implement anything in the NTAI-X thread, and the architecture required by Epic AI would be impossible to implement without fundamentally compromising the underlying concepts.

AI is not like other programs. It doesn't just 'work', the outcome is proportional to the effort you put in, and flexibility is a must. We should not force ourselves into moving code into lua unnecessarily.


Eitherway the AI developers here disagree with you based on prior experience and knowledge you do not have. We know better, and now we have a greater understanding of the lua issue and are nearing deployment of the new interface, we can begin to tackle issues we've been unable to manage beforehand.

Sure content developers can build small AIs, but they'll never be able to compete with the more refined AIs built here once they're adapted to the new game environment. Sure it will take some time to figure out how we're going to tackle the problem and adapt our code bases, remember we're not working from scratch here.

But what we would greatly appreciate is cooperation, and most importantly, information. We cannot support and anticipate lua mechanisms we do not understand, so you cannot build a new game mechanic and keep it under wraps and expect us to build support without providing a mechanism or interface for us.

To this end, we need to set out basic interfaces for common features. It might be best to start a thread amongst the content developers to decide how to export a common lua interface the AI can query using the messages in order to determine what resources there are, their quanities, and other generics, such as how much of it and how much can be stored, is it infinite, its name/identifier, is a high amount desirable or does it mean your loosing( IE do we want to get as much of this resource as possible or do we want as little as possible)? etc

Another useful interface would be whether a unit supports morphing into another unit, and the details of such. This should be standardized between all the content that uses this feature, and preferably so that they all use the same command



Oh and +1 to imbaczek

[hoijui]

Now all that needs to happen is that the DLL exists, that the callout can be performed from the Lua side, and that the arguments are documented. Voila, one of those nasty, expensive tasks that, as imbaczek puts it, is "hard for hackers" is available for non-hackers to plug in and use.

please! what imbaczek (and AF, satirik and me) said, is that it is very hard to code an AI. The AIs do use the same code for metal spot finding already, and they do, could or would exchange/share other modular parts aswell.
still, they all claim it to be difficult to write an AI, even doh they just had to do the little gluing together of algorithms, as you put it.
What we want, are intelligent AIs. You not, and we accept that. But please respect, that what AI devs want, is creating something that appears intelligent. You not, we yes, and some players want that too.

As it is right now, I can't be bothered to bug an AI developer to customize an AI for P.U.R.E., and have no intention of doing so in the future- it's too different from an OTA mod for me to want the existing AIs cleaned up a bit, and yet those are the only ones extant, so it's a null for me to bother. This paradigm needs to shift, or pretty soon AI development will just be for theorists, and will have nothing to do with what the rest of us are doing around here, which is building kickass video games.

If Skirmish AIs get access to LUA stuff of mods (which is what we want), then the only difference from a the way AIs work now and how you want it to be, is a different programming language. instead of LUA, it will be one of many others (possibly including LUA).
This is a problem though, that AIs have no access to LUA stuff, and seems not to be an easily solvable one. But for me, it is the way to go.

Not everyone wants just what you want; a simple AI that suffices for training newbs for thier first hour of spring. And your model (as i get it, you think so too) does not allow for more then that. Therefore, we need something that is quite like what we have now. This, in the other hand, is not negative for what you want. These two ways of doing an AI can co-exist, and already do so.

[hoijui]

To this end, we need to set out basic interfaces for common features. It might be best to start a thread amongst the content developers to decide how to export a common lua interface the AI can query using the messages ...

+1

[AF]

Actually, although all the major AIs use the algorithm created by krogothe/firenu/tournesol, none are the same.

KAI used a customized version that was integrated into a spot finding class.

NTai used one of the latest versions available with a handful of minor modifications and a wrapper class

AAI used a version of the algorithm that does not have the same API. I am not sure if submarine updated the algorithm as new versions came out, but it worked and the speed ups in the new versions were not absolutely necessary since by then all the major AIs used cache files for metal spots.

[Argh]

put some files like TAResourceAI.lua, BattleGroupAI.lua and MicroJeffiesAI.lua and it'll Just Work(tm), you're asking for something that hasn't been done yet. not only in spring, but at all, and for good reasons. (actually, those files could work, but changing TAResourceAI.lua to, let's say, StarcraftResourceAI.lua without heavily modifying logic elsewhere is pretty much impossible.)

Not exactly. Certain things shouldn't be managed by a core DLL:

1. Economy. Why make an AI to manage an economy, when that's relatively simple math, needs to run only every 10-15 seconds or so, and then results in just a few orders being issued? No point, unless you're trying to duplicate human levels of efficiency- and there we go right back to my main point, which is that AI developers are the least-likely to even know what my game is about, let alone what choices to make at what point. Moreover, any halfway-decent AI should just plain cheat, when it comes to resources. Again, I understand that you guys want to model human behavior, that's nice and all... but ultimately, it pigeonholes your designs too much to be useful. P.U.R.E. is not a waaaaaay out of the mainstream. It's straightforward and pretty close to OTA. Yet none of the current AIs can handle Resistance's economy, nor do I predict I'll see one that can before my first non-beta release. So, CHEAT, dammit. Some of us aren't willing to wait forever.

2. Unit micro. Again, this is behavior that shouldn't run often. It'd be nice to have a fast DLL that performed unit-tracking behaviors, and informed a Lua decision-maker when my Jeffy is close enough to enemies that it should begin dancing... but the actual dancing should be handled through Lua.

3. Battlegroups. It's not that big of a deal to set up a Wait with Lua, or to simply assign units being built to a bog-standard Group, then tell them to assemble, then wait a minute, then go somewhere.

4. Determining what a Unit's purpose is. Here's a big thing that annoys me about every AI except for NTAI. They don't allow game developers to specify what the unit does, and then proceed to do various stupid crap with them.

In short... your examples are things that Lua can and should be used for.

What Lua should not do, in my opinion, are things like this:

1. Terrain analysis. Where are the high and low spots? Where is the closest place I can build Unit X, Y or Z? Am I looking for a point that's in the "lee" of incoming enemy fire? Do I need to find a chokepoint? Etc.

2. Metal analysis. Where would be the most efficient place for Unit X to build a mine next?

3. Threat analysis. Where is the largest threat on the map?

4. Scouting analysis (for non-cheating AI). What areas are unknown, or need to be refreshed? A DLL could divide up the map into sectors, rate their scouting values, and then return a table of locations located in the sectors, so that Lua could be used to pull one out of a hat and send a scout there.

5. Traffic analysis. I need to send a group to location X,Y- what would be the optimal way to avoid current and projected traffic in this zone?

See what I'm getting at? There are a lot of serious crunchy things where I'd be the first one to say, "yeah, we need the fastest code we can get our hands on, to do that well". But... it doesn't have to be tightly interconnected to remain effective. Most of this stuff involves things that don't need to be updated often, and Lua could just ask it to return its current state when required.

The issue is that what's being done right now is doing lots of stuff that should not be done at the AI level, which means, among other things, lots of assumptions about game design and unit behavior that just plain don't work, once we're not talking about BA.

<shrugs>

I'll just have to sit down and prove that this can be done in Lua, then. You guys are entirely too pessimistic about what's possible, and how hard it is, and how useful it is.

Making a basic cheating AI with Lua is both practical and useful. I have most of it sketched out already, frankly.

Having one that can also interface with DLLs that could handle the complex tasks it needs to perform, such as efficient building placement, would result in an enormous gain, in terms of effectiveness, and would make less cheating necessary.

But meh, that's not necessary, and if it ever arrives, great, if not, oh well.

[imbaczek]

1. Economy. <snip>

as you've said, this requires AI that can reason about resources in the current mod, ie. writing a mod-specific AI. even cheating is not trivial, since the mod would have to at the very least provide means of giving a player resources on demand. /atm does this for energy and metal, but those two lost their privileged status a long time ago. not cheating is even harder: depending on what is required to get resources, AI has to plan ahead in completely different ways, e.g.
KP - get geos, as much and as soon as possible EXCEPT on super-small maps where a rush or rush protection has to be up first (see, no resources and it's already pretty complex!)
*A - pretty complex building of mexes, managing E while leaving enough resources to protect territorry
other mods - differently...

the point here is that economy makes half of the game, cheating it is a temporary solution and not even always possible (KP). the economy model affects the whole game - the planner has to identify tasks that the economy needs. language of implementation is just a tool here, this is a _very_ hard problem both in Lua and in C++ and in any other programming language you can imagine. Lua only has an advantage that you could swap those thousands of lines of code without recompiling.

2. Unit micro. Again, this is behavior that shouldn't run often. It'd be nice to have a fast DLL that performed unit-tracking behaviors, and informed a Lua decision-maker when my Jeffy is close enough to enemies that it should begin dancing... but the actual dancing should be handled through Lua.

3. Battlegroups. It's not that big of a deal to set up a Wait with Lua, or to simply assign units being built to a bog-standard Group, then tell them to assemble, then wait a minute, then go somewhere.

4. Determining what a Unit's purpose is. Here's a big thing that annoys me about every AI except for NTAI. They don't allow game developers to specify what the unit does, and then proceed to do various stupid crap with them.

this I partially agree with, except again, it's _not_ easy to define a generic micro and macro behaviour. you want to tell the AI that a jeffy should be used for raiding, great. every human will understand that, but a "raiding" behaviour may translate to many hundreds LOCs which, in turn, may or may not work for a slightly different unit in another mod and would require rewriting. battlegroups and simple micro should be generic enough to be doable (KAI and descendants).

don't have the time to reply to the rest, i can offer a summary of what my response would mean: details, details, details. for now, if you want to make life easier for AIs, you'll have to cheat for them in LuaRules - give them resources, more units, faster build speeds, etc.