Lua AI Solution n#2
Moderators: hoijui, Moderators
Lua AI Solution n#2
http://www.darkstars.co.uk/2008/lua-ais ... -generics/
Re: Lua AI Solution n#2
This solution sounds good, too.
Are this list generalized or custom lists which a mod setup?
This list would be very long in both size. Attributes and the amount of units.
And would require more work for mod developer.
Are this list generalized or custom lists which a mod setup?
This list would be very long in both size. Attributes and the amount of units.
And would require more work for mod developer.
Re: Lua AI Solution n#2
It would be the gadget developer who did the grunt work here for the lists. These would probably be nabbed by other content developers as usual.
I also think you vastly underestimate the amount of time and effort it would require to actually build this. Think for a moment, an AI that needs to learn what each individual command does and how to use it from scratch by trial and error.
I also think you vastly underestimate the amount of time and effort it would require to actually build this. Think for a moment, an AI that needs to learn what each individual command does and how to use it from scratch by trial and error.
Re: Lua AI Solution n#2
Yeah, would require much work.AF wrote:It would be the gadget developer who did the grunt work here for the lists. These would probably be nabbed by other content developers as usual.
I also think you vastly underestimate the amount of time and effort it would require to actually build this. Think for a moment, an AI that needs to learn what each individual command does and how to use it from scratch by trial and error.
A question is do the AI developer want to support each mod if it's total different from TA mods (like THIS or Fibre)?
Or only some things like special events or attribute changing of a unit?
Re: Lua AI Solution n#2
I think that's something each developer is going to have to decide for themselves, and we may well see some AIs that use bits of both.
But either way content developers no longer have the luxuries of relying on AI developers to do all their work for them, its just not possible unless the AI devs take an active role in content creation, which most of us don't have the time for as it is.
solution n#1 gives quicker results and is the fastest and easiest way to implement hard AIs, but it requires some thought as the lua end of the divide needs to interface with the gadgets and perform lots of small bits of AI logic, small indeed, and not very complex, but pieces of a jigsaw piece nonetheless.
A listing as needed for solution #2 would be tedious to create, but I get the feeling that these sorts of things might be needed anyway at a basic level for certain things, such as morph commands or resources just so that hardcoded stuff has a chance to actually use it.
But either way content developers no longer have the luxuries of relying on AI developers to do all their work for them, its just not possible unless the AI devs take an active role in content creation, which most of us don't have the time for as it is.
solution n#1 gives quicker results and is the fastest and easiest way to implement hard AIs, but it requires some thought as the lua end of the divide needs to interface with the gadgets and perform lots of small bits of AI logic, small indeed, and not very complex, but pieces of a jigsaw piece nonetheless.
A listing as needed for solution #2 would be tedious to create, but I get the feeling that these sorts of things might be needed anyway at a basic level for certain things, such as morph commands or resources just so that hardcoded stuff has a chance to actually use it.
Re: Lua AI Solution n#2
I was wondering how likely it would be that I could get Lua-x.x.dll out of the main build (spring.exe) and loaded dynamically.
See I would like to use Java to talk to Lua Widgets. I have a DLL that loads a JVM upon a lua script request "require "luajavaloader"" so lua can talk to Java, but it uses a jar that depends on the lua DLL and that DLL needs to be the same as the one used by spring. Since the lua is built into spring.exe Java can't load it and thus can't call into spring.exe with JNI.
Technically I could create a custom build for this, but I would prefer everyone have Java to Lua access.
See I would like to use Java to talk to Lua Widgets. I have a DLL that loads a JVM upon a lua script request "require "luajavaloader"" so lua can talk to Java, but it uses a jar that depends on the lua DLL and that DLL needs to be the same as the one used by spring. Since the lua is built into spring.exe Java can't load it and thus can't call into spring.exe with JNI.
Technically I could create a custom build for this, but I would prefer everyone have Java to Lua access.
Re: Lua AI Solution n#2
I think your thought processes have tripped themselves up somewhere.
Also there are no JNI bindings for lua in spring. Even if there were and there was a lua.dll, you would not be calling lua in spring you would be calling your own copy of lua. 2 totally separate instances of lua.
Also there are no JNI bindings for lua in spring. Even if there were and there was a lua.dll, you would not be calling lua in spring you would be calling your own copy of lua. 2 totally separate instances of lua.
Re: Lua AI Solution n#2
Lua is mainly a binding language on top of c. As such the communication is from Java to c and then to Lua, or from Lua to c to Java. The JNI is only between Java and c and c and Java.
I have done this:
See, I can call the c program lua.exe with a script that loads a JVM that allows Java and Lua to communicate through c code. The binding tool is called LuaJava. Thus only one instance of a c program that runs Lua and can load a JVM.
What I want to do:
So for Spring.exe that loads lua scripts can load a JVM that allows Java to talk to Lua, but LuaJava needs jni access to the same Lua c binaries that the game used.
I might be a little nutty, but it is possible I promise. Just think of Lua as only a c DLL that tags each luastate with an id. Each LuaState is basically a singleton that any language can access.
That's what make Lua cool.
Summary
Your correct that we only want one lua instance for it to work, but in short I should be able to talk to that instance since it is just a c library.
Your question now is probably:
1. Why was the dll embedded into Spring to begin with?
Probably someone was to lazy to use the DLL.
2. Why not just talk to the C/C++ code directly without Lua?
a. I want to leverage the existing and future Lua Scripts with Java.
b. I wanted java to work with both JAI and LUA for custom AI's and Lua Scripts at the same time. So AI and Helpers at the same time.
I have done this:
See, I can call the c program lua.exe with a script that loads a JVM that allows Java and Lua to communicate through c code. The binding tool is called LuaJava. Thus only one instance of a c program that runs Lua and can load a JVM.
What I want to do:
So for Spring.exe that loads lua scripts can load a JVM that allows Java to talk to Lua, but LuaJava needs jni access to the same Lua c binaries that the game used.
I might be a little nutty, but it is possible I promise. Just think of Lua as only a c DLL that tags each luastate with an id. Each LuaState is basically a singleton that any language can access.
That's what make Lua cool.
Summary
Your correct that we only want one lua instance for it to work, but in short I should be able to talk to that instance since it is just a c library.
Your question now is probably:
1. Why was the dll embedded into Spring to begin with?
Probably someone was to lazy to use the DLL.
2. Why not just talk to the C/C++ code directly without Lua?
a. I want to leverage the existing and future Lua Scripts with Java.
b. I wanted java to work with both JAI and LUA for custom AI's and Lua Scripts at the same time. So AI and Helpers at the same time.
Last edited by tberthel on 01 Jul 2008, 23:44, edited 1 time in total.
Re: Lua AI Solution n#2
I really dont think you understand what your doing.
To illustrate why I shall make the following thing clear:
dll != instance
for example say I have a class called MyClass:
MyClass a;
MyClass b;
By my reasoning:
a != b
By your reasoning
a == b
Its similar to how programs and dlls work. Launching spring.exe creates an 'instance' of spring.exe not a 'reference' to spring.exe, spring.exe is not the process, spring.exe is just the executable used to instantiate it.
Lets say we have lua.dll in our spring folder.
If we launch spring and spring loads lua.dll we will have an instance of the lua.dll library in memory.
If we then launch your java app, and it loads lua.dll we will then have a second instance of the lua library in memory.
The spring lua instance != the java lua instance. Declaring a variable in java lua does not mean it will be accesible in spring lua, theyre sort of like parallel universes.
Also what you are trying to do seems totally pointless. You would be better off trying to figure out the lua API in spring.
Either way there is no lua.exe or lua.dll, its compiled into spring.
To illustrate why I shall make the following thing clear:
dll != instance
for example say I have a class called MyClass:
MyClass a;
MyClass b;
By my reasoning:
a != b
By your reasoning
a == b
Its similar to how programs and dlls work. Launching spring.exe creates an 'instance' of spring.exe not a 'reference' to spring.exe, spring.exe is not the process, spring.exe is just the executable used to instantiate it.
Lets say we have lua.dll in our spring folder.
If we launch spring and spring loads lua.dll we will have an instance of the lua.dll library in memory.
If we then launch your java app, and it loads lua.dll we will then have a second instance of the lua library in memory.
The spring lua instance != the java lua instance. Declaring a variable in java lua does not mean it will be accesible in spring lua, theyre sort of like parallel universes.
Also what you are trying to do seems totally pointless. You would be better off trying to figure out the lua API in spring.
Either way there is no lua.exe or lua.dll, its compiled into spring.
Re: Lua AI Solution n#2
Yes you can use the same instance as I already have before. JNI can talk to an instance both ways. I.E. the original instance of Lua/C can create and talk to a JVM.
See Lua passes the Lua state (a Lua instance) to Java. So any instance of Lua can create a JVM to talk to just as you would with C code.
Yes, I know you probably have been given the idea that Java must create the instance of Lua and that is not correct. Lua a single instance can also create a JVM and thus still be the same instance of lua. Heck Lua/C can create many Java instances to talk too.
Simplification:
Currently:
What I can already do:
Lua.exe
Lua.dll
LuaJava.dll
Jvm.dll
What we can have now:
Spring.exe
Jvm.dll for JAI
No Lua.dll since clash with existing lua embedded in spring.exe
So No LuaJava since it needs Lua.dll
What I want:
Spring.exe
Lua.dll
LuaJava.dll
Jvm.dll
Hmm. Yes that is right no java.exe just a dll. Well, now you probably realize my nutty smartness.
What your probably thinking:
Spring.exe
Lua.exe
Java.exe
and 3 sets of the same dll
Yes this would require IPC which is still possible just slow as hell. This is not what I want otherwise I would not need some one to pull lua dll out. I could just use JSON, REST, SOAP, XML-RPC or other for that. Slow is no. Lol I can see it now distributed clustered AIs. Hmm maybe it's not a bad idea after all.
I am nutty for a reason, but I am also smarter than the average scientist and Bill Gates.
See Lua passes the Lua state (a Lua instance) to Java. So any instance of Lua can create a JVM to talk to just as you would with C code.
Yes, I know you probably have been given the idea that Java must create the instance of Lua and that is not correct. Lua a single instance can also create a JVM and thus still be the same instance of lua. Heck Lua/C can create many Java instances to talk too.
Simplification:
Currently:
What I can already do:
Lua.exe
Lua.dll
LuaJava.dll
Jvm.dll
What we can have now:
Spring.exe
Jvm.dll for JAI
No Lua.dll since clash with existing lua embedded in spring.exe
So No LuaJava since it needs Lua.dll
What I want:
Spring.exe
Lua.dll
LuaJava.dll
Jvm.dll
Hmm. Yes that is right no java.exe just a dll. Well, now you probably realize my nutty smartness.
What your probably thinking:
Spring.exe
Lua.exe
Java.exe
and 3 sets of the same dll
Yes this would require IPC which is still possible just slow as hell. This is not what I want otherwise I would not need some one to pull lua dll out. I could just use JSON, REST, SOAP, XML-RPC or other for that. Slow is no. Lol I can see it now distributed clustered AIs. Hmm maybe it's not a bad idea after all.
I am nutty for a reason, but I am also smarter than the average scientist and Bill Gates.
Last edited by tberthel on 02 Jul 2008, 00:25, edited 1 time in total.
Re: Lua AI Solution n#2
If I had repo access I might be tempted to do it myself. Heck I still can do it. It just wouldn't be available to others.
Re: Lua AI Solution n#2
For one the lua virtual machine in spring was modified by trepan, several performance related changes and desync prevention measures.
And I have written JNI code myself, and I have looked into lua virtual machines too, although I have never gone and put that into production in any of my projects yet. Either way what your saying doesn't make much sense. Either your not articulating yourself correctly or your leaving something out....
As I understand it, you would have to take the Lua environment pointer and hand it to a lua runtime in C in the JNI code, and then provide JNI interfaces for java to communicate with that particular Lua instance.
This would require you at the very least modify the lua.dll your providing with both JNI interfaces and the modifications trepan made.
Then there's the problem of what happens if the scripts attempt to make use of the spring APIs while their environment is being ran by the Java end? Java doesn't have access to all the spring internals.
What your describing once you filter out the grammar issues would also introduce a huge raft of issues to the AI community here because there would be the Java AI way of doing things and it wouldn't be available to the other AIs. A standardized way fo doing this would become impossible.
I think you need to describe what your talking about better, and I don't appreciate being dismissed out of hand as someone who knows nothing.
And I have written JNI code myself, and I have looked into lua virtual machines too, although I have never gone and put that into production in any of my projects yet. Either way what your saying doesn't make much sense. Either your not articulating yourself correctly or your leaving something out....
As I understand it, you would have to take the Lua environment pointer and hand it to a lua runtime in C in the JNI code, and then provide JNI interfaces for java to communicate with that particular Lua instance.
This would require you at the very least modify the lua.dll your providing with both JNI interfaces and the modifications trepan made.
Then there's the problem of what happens if the scripts attempt to make use of the spring APIs while their environment is being ran by the Java end? Java doesn't have access to all the spring internals.
What your describing once you filter out the grammar issues would also introduce a huge raft of issues to the AI community here because there would be the Java AI way of doing things and it wouldn't be available to the other AIs. A standardized way fo doing this would become impossible.
I think you need to describe what your talking about better, and I don't appreciate being dismissed out of hand as someone who knows nothing.
Re: Lua AI Solution n#2
Spring.exe loads dlls that are all shared within the Spring.exe process. Is it that hard to understand.And I have written JNI code myself, and I have looked into lua virtual machines too, although I have never gone and put that into production in any of my projects yet. Either way what your saying doesn't make much sense. Either your not articulating yourself correctly or your leaving something out....
Yep. That is how it works.As I understand it, you would have to take the Lua environment pointer and hand it to a lua runtime in C in the JNI code, and then provide JNI interfaces for java to communicate with that particular Lua instance.
No. No change to the original lua.dll is required. While lua does not need a change I would supply a custom LuaJava and LuaJavaLoader dll. This is because LuaJava did not support Lua to Java without a fix. It only supplied Java to Lua. In fact I may be the only one that has done a Lua to Java load on windows successfully.This would require you at the very least modify the lua.dll your providing with both JNI interfaces and the modifications trepan made.
Why would the JVM need direct access to spring when Lua already has that. However JAI could do that for the AI apis and others could be exposed as needed, but I don't want that. BTW, if JAI is opened correctly I will just add my stuff to that project.Then there's the problem of what happens if the scripts attempt to make use of the spring APIs while their environment is being ran by the Java end? Java doesn't have access to all the spring internals.
Actually the standard should now and always be the C/C++ api.What your describing once you filter out the grammar issues would also introduce a huge raft of issues to the AI community here because there would be the Java AI way of doing things and it wouldn't be available to the other AIs. A standardized way fo doing this would become impossible.
Any language also linked into Lua would also have access to the Java AIs and Helpers I thinks the bindings have over a dozen languages now. So the current API should just be exposed to more languages. Two 2 current AIs that are supposed to support Java either are old or don't work yet and also don't provided Helpers Scripts as Lua does.
So I am not asking for coding changes just building changes.
Actually you are an accomplished developer. I just have a more years experience than you developing between Java, C/C++, and Lua. So I won't dismiss you ever. Anyways, your kind of cute when your angryI think you need to describe what your talking about better, and I don't appreciate being dismissed out of hand as someone who knows nothing.
Re: Lua AI Solution n#2
Example Lua to Java:
require "luajavaloader"
-- This loads jvm and sets luastate
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
function widget:GetInfo()
return {
name = "LuaJava Events",
desc = "Send Events to Java with LuaJava",
author = "Travis Berthelot",
date = "July 1, 2008",
license = "AllBinary",
layer = 0,
enabled = true -- loaded by default?
}
end
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
function widget:UnitCreated(unitId, unitDefID, unitTeam)
springUnitEventHandler = luajava.newInstance(
"org.allbinary.spring.ai.global.SpringUnitEventHandler");
springUnitEventHandler.onUnitCreated(unitId);
end
function widget:UnitGiven(unitID, unitDefID, unitTeam)
widget:UnitCreated(unitID, unitDefID, unitTeam)
end
--------------------------------------------------------------------------------
require "luajavaloader"
-- This loads jvm and sets luastate
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
function widget:GetInfo()
return {
name = "LuaJava Events",
desc = "Send Events to Java with LuaJava",
author = "Travis Berthelot",
date = "July 1, 2008",
license = "AllBinary",
layer = 0,
enabled = true -- loaded by default?
}
end
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
function widget:UnitCreated(unitId, unitDefID, unitTeam)
springUnitEventHandler = luajava.newInstance(
"org.allbinary.spring.ai.global.SpringUnitEventHandler");
springUnitEventHandler.onUnitCreated(unitId);
end
function widget:UnitGiven(unitID, unitDefID, unitTeam)
widget:UnitCreated(unitID, unitDefID, unitTeam)
end
--------------------------------------------------------------------------------
Re: Lua AI Solution n#2
The problem is the C API does not provide Lua state pointers at the moment.
Also the lua state pointer iirc is just a description of the environment, not an implementation of it. Think of it this way:
We have 2 people and one sheet of paper. One person is called Spring, and the other person is called luajava, and they both have pens and pencils. The piece of paper has questions on it, and to answer a question one must know the answers to the questions before it.
luajava knows lua and java languages. Spring knows lua and springAPI languages. They take turns to answer the questions.
but some of the questions are written in luajava, and some are written in springAPI.
Its luajavas turn to answer a question, and its a springAPI question. Luajava hasnt a clue how to execute the instructions and makes a stab in the dark guess NULL!!!!
SpringAPI sees an if statement based on the previous question, but luajava didnt answer properly which one should it answer with?
Suffice to say the whole thing starts to fall apart.
Same piece of paper, 2 different lua environments.
There's also the problem of other AIs not having built in lua environments, and if they did they would have similar problems if they tried to directly use the lua state pointers. This whole thing might work perfectly under other situations but in this context extra work is necessary.
I think it would be better to take what trepan has devised and figure out a method of using it.
Also the lua state pointer iirc is just a description of the environment, not an implementation of it. Think of it this way:
We have 2 people and one sheet of paper. One person is called Spring, and the other person is called luajava, and they both have pens and pencils. The piece of paper has questions on it, and to answer a question one must know the answers to the questions before it.
luajava knows lua and java languages. Spring knows lua and springAPI languages. They take turns to answer the questions.
but some of the questions are written in luajava, and some are written in springAPI.
Its luajavas turn to answer a question, and its a springAPI question. Luajava hasnt a clue how to execute the instructions and makes a stab in the dark guess NULL!!!!
SpringAPI sees an if statement based on the previous question, but luajava didnt answer properly which one should it answer with?
Suffice to say the whole thing starts to fall apart.
Same piece of paper, 2 different lua environments.
There's also the problem of other AIs not having built in lua environments, and if they did they would have similar problems if they tried to directly use the lua state pointers. This whole thing might work perfectly under other situations but in this context extra work is necessary.
I think it would be better to take what trepan has devised and figure out a method of using it.
Re: Lua AI Solution n#2
Like I said before several times, I have already done that with a luajavaloader.dllThe problem is the C API does not provide Lua state pointers at the moment.
I don't know what your little story is about since only one lua instance would exist. I only want one lua instance or environment.
What problem. One LuaState Ptr for all AIs and Helpers. How would that cause problems?There's also the problem of other AIs not having built in lua environments, and if they did they would have similar problems if they tried to directly use the lua state pointers. This whole thing might work perfectly under other situations but in this context extra work is necessary.
I think it would be better to take what trepan has devised and figure out a method of using it.
BTW the build file states that the shared libraries should be broken out so it looks as if other ppl are going to do what I need anyways.
I will stop wasting my time to convince you and just build it that way myself. I want it that way so I have have Helpers and AIs in Java.
I only write in dynamic and/or non portable languages if I must. So I will write my Helpers and AIs in Java even if it means I use a custom build.
Re: Lua AI Solution n#2
Firstly there's already a Java AI effort and even a Java port of RAI, if the whole point of this is to allow java AIs then your repeating work.
Secondly, there are no Lua pointers in the C++ interface, and no sign of them so far in the planned C interface.
But really, why your doing this I have no idea. Why you chose to post about it in this thread even I'm not clear of.
Secondly, there are no Lua pointers in the C++ interface, and no sign of them so far in the planned C interface.
But really, why your doing this I have no idea. Why you chose to post about it in this thread even I'm not clear of.
Re: Lua AI Solution n#2
Indeed. The Lua state (VM program stack, etc) is not directly exposed
to current C++ AI's for a reason, and for Java/ $OTHER_LANGUAGE AI's
the CallLuaRules() callback can just be wrapped anyway. Bypassing the
interface (if that's the point) would be redundant at best.
to current C++ AI's for a reason, and for Java/ $OTHER_LANGUAGE AI's
the CallLuaRules() callback can just be wrapped anyway. Bypassing the
interface (if that's the point) would be redundant at best.
Re: Lua AI Solution n#2
JAI can't use the Lua scripts and is AI not for helpers, and is not done and very buggy.
Re: Lua AI Solution n#2
Where is the Java port RAI? Can it talk to Lua? If so then good. If now how does that make helper scripts available for Java.