Zero-K Menu Unit Selector

[knorke]

wiki callin list is incomplete, I think its not listed there.
/fake edit oh you found it :)
http://springrts.com/wiki/The_Talking_Changelog says

- Added the AICallIn() LuaRules unsynced call-in (for CallLuaRules())

but from some other threads that come up when searching for "AICallIn" it seems it seems like its also a synced call-in?
will take experimenting i guess.

So:
1) Lua receiving from AI: gadget:AICallIn(datastr)
2) Lua sending to AI:
3) AI receiving from Lua :
4) AI sending to Lua:

1 down, 3 to go.

Then in Lua synced gadget land you can proceed to use the SendToUnsynced command to forward it to the unsynced code land

Wouldnt just acting/responding from synced code work as good for most things?

[slind]

So:
1) Lua receiving from AI: gadget:AICallIn(datastr)

Lua can respond to the AI through this function with a serialized string of whatever it wants to send.

2) Lua sending to AI:
3) AI receiving from Lua :
4) AI sending to Lua:

As far as I know, these do not exist. The only communication method that exists is from AI to Lua. However...

If you want to think about it in a slightly different way, every action the synced Lua gadgets perform get translated into engine events that get passed to the AI through the AI's normal event handler.

The reason the AI needs to talk to Lua is so that the AI can control the Lua environment as if it were a human. The AI should be the one driving the communication.

There needs to be a standard way for the AI to ask Lua if there is anything it needs to do for a game. Communication would be like this:

AI-> Lua : "Hey Lua. Anything I need to do this frame?"
Lua->AI: "Yeah. We have a dialogue box, 4 options, named 'Unit Select'."
AI->Lua: "Pick number 3."
Lua->AI: "Okie-dokie"

[knorke]

If you want to think about it in a slightly different way, every action the synced Lua gadgets perform get translated into engine events that get passed to the AI through the AI's normal event handler.

Hm, not every Lua action gets passed to the AI.
ie in Spring Tanks (http://springrts.com/wiki/Spring_Tanks) there is a score table that counts how often a players captured the enemy flag. For an AI that score table is atm not visible but at game end the winner is decided by that score table.
There simply is no engine event for "flag has been scored" and so it does not get passed to the AI. The AI could only do something like track location of the flags and depending on how near the flags are to the score bases it could make some guesses or something.

In other games there is a "king of the hill" where players try to hold an area for a certain amount of time to win. If controll of the area changes, no engine event is raised because it is a pure Lua thing.
There are lots more things like this.

The reason the AI needs to talk to Lua is so that the AI can control the Lua environment as if it were a human.

Imo it is more abstract and not just about allowing the AI to click dialogue boxes.
ie afaik AI interfaces have something like isBuildSiteValid(x,z) and then the engine responds with "you can/can not build there."
But for some games, it would not work. For example evolutionRTS has this system were you can build certain things only around powerplants: http://www.evolutionrts.info/game-manual/#Power
So the game would need to provide a new isBuildSiteValid(x,z) that takes in account the power requirement.
---------------------
But that is details, what would be really nice to know is how 2) 3) 4) work.
Hopefully some engine/AI dev can shed some light on that

Here is an Lua side message recieving, that is now pretty clear:
unit_morph.lua of zeroK:

Code: Select all

http://www.google.com/codesearch/p?hl=de#_IaQsP4Z6YI/trunk/mods/zk/LuaRules/Gadgets/unit_morph.lua&q=AICallin%20package:http://zero-k\.googlecode\.com&sa=N&cd=2&ct=rc

unit_morph.lua of Conflict Terra: (appearently older version)

Code: Select all

http://www.google.com/codesearch/p?hl=de#5IW79w8JrCo/games/CT/LuaRules/Gadgets/unit_morph.lua&q=AICallin%20package:http://conflictterra\.googlecode\.com&sa=N&cd=1&ct=rc

it has this Spring.SendMessage(data) maybe that is for responding?

(links get fucked, so I put them in code-tags to allow copy&paste)

Code: Select all

    if message[1] == "Shard" or true then-- Because other AI shall be allowed to send such morph command without having to pretend to be Shard

lol. Such things should be avoided of course...

Also quickly looked through the source of some AIs
(http://springrts.com/wiki/AI:Skirmish:List) ie BKPAI but I found nothing that seemed to send custom messages to Lua.

[AF]

Ai calls an API method passing in string A

Gagdets recieve a call in with strign A as a parameter.

Gadget does stuff

Gadget may return a string value

AI API call returns, a return value may be returned ( as specified by gadget ) in string form. Check for null/empty or error values.

That is AI <-> lua communication in spring.

As a sidenote, one can issue a command to a unit that has no meaningful command value, and let lua use that to retrieve data, but it has the same dynamic as the above, and would require more effort, and would only let you pass integers or floats, and would not allow you to return a value.

[knorke]

so like this?

Code: Select all

gadget:AICallin (datastr)
  return "answer"
end

return value of AICallin is only way for Lua->AI?

1) Lua receiving from AI: gadget:AICallIn(datastr)
2) Lua sending to AI: return value of gadget:AICallIn(datastr)
3) AI receiving from Lua :
4) AI sending to Lua:

[AF]

Code: Select all

std::string CSpringGame::SendToContent(std::string data){
	SCallLuaRulesCommand c;
	c.data = data.c_str();
	c.inSize = -1;
	callback->GetEngine()->HandleCommand(callback->GetTeamId(),-1,COMMAND_CALL_LUA_RULES,&c);
	return c.ret_outData;
}

IGame* game = returnmeaCSpringGame(); // function doesn't really exist
std::string value = game->SendToContent("hello");

Code: Select all

gadget:AICallin (datastr)
    if datastr == "hello" then
        -- do magic custom gameplay hand waving command
        return "world"
    end
end

That is AI <-> lua communication at its most basic.

[slind]

so like this?
1) Lua receiving from AI: gadget:AICallIn(datastr)
2) Lua sending to AI: return value of gadget:AICallIn(datastr)
3) AI receiving from Lua :
4) AI sending to Lua:

If you want to think about it like this then all four of them exist already.

1) Lua receiving from AI: gadget:AICallIn(datastr)
2) Lua sending to AI: return value of gadget:AICallIn(datastr)
3) AI receiving from Lua : return value from COMMAND_CALL_LUA_RULES
4) AI sending to Lua: COMMAND_CALL_LUA_RULES

[knorke]

from line 98 function Close(commPicked) of
http://code.google.com/p/zero-k/source/ ... lector.lua
it seems that for AI com chosing zeroK just needs something like

Code: Select all

--message in the form of "selectCommander|commanderName"
gadget:AICallIn(datastr)
  s = explode (datastr, "|")
  if (s[1] == "selectCommander") then
     Spring.SendLuaRulesMsg ("faction:" .. s[2])
  end
end

[AF]

I would rather we started the semantic of passing a lua table before we end up with APIs we can't undo, using loadstring or some variation

Messages taking the form of an identifier, using said message table in a dictionary format. This would also allow us to pass functions to be executed from the AI for extra flexibility.

Whereas if don't standardise we're going to be stuck with code on each side of the divide checking the format and type of message handed over the divide, and problems when 2 gadgets use differing styles.

[slind]

This is a tricky problem. On the one hand we don't want to over complicate anything or reinvent the wheel if we don't have to. On the other hand the functionality that exists currently doesn't provide for an easy solution.

As I see it, two solutions exist:

1) Modify the engine to provide additional Lua<->C++ interaction.

2) Stipulate a string based dictionary format that both Lua and C++ must implement.


Option #2 could be implemented without modifying the engine through coding a custom serializer/deserialzer for both Lua and C++.

Option #1 could be implemented through exposing an additional custom class that is managed by the engine through exposing a C++ class to the Lua environment. This class would allow the AI and Lua to interact directly.

Option #1 would require modification of the engine anytime additional functionality is required for any project.

Option #2 would allow the specification to be expanded by any individual project.

Option #2 would simply be a specification that would be difficult to enforce.

Option #1 would force compliance to the API.


Are there other options available? Arguments either way? This is what I have for now.

Why I am not suggesting the passing of Tables: It would require modification of the engine AND the data would still have to be passed to the AI as a dictionary string.

If you don't know what a dictionary string is, take a look at benoding.

[hoijui]

using tables would not require engine changes.
you just pass the table around as string, basically.

what is planned (though nobody is really working on that these days), is a way for AI<=>unsynced-Lua communication. this would allow AIs to be bundled with widgets, and so they could work with any mod, without requiring modification to it. very simply said, the interface would be about like the current AI<=>synced-Lua one is now: one command callable by AI, one call-in in Lua.

embedding any kind of higher level API then passing pure data in the engine is not an option.

[AF]

serialise table
send over API
deserialize table
do work
serialize return result table
send back as return value
deserialize table on AI end

All doable at the moment in Shard using pure native lua APIs as documented at the official lua website

[slind]

serializing and deserializing the table is non-trivial...

It is equivalent to what I stated in option #2.

what is planned (though nobody is really working on that these days), is a way for AI<=>unsynced-Lua communication.

Can already happen through the use of a Synced gadget.

[hoijui]

slind... guess what, i know that. read the whole post; your comment makes no sense.

[AF]

serializing and deserializing the table is non-trivial...

It is equivalent to what I stated in option #2.

what is planned (though nobody is really working on that these days), is a way for AI<=>unsynced-Lua communication.

Can already happen through the use of a Synced gadget.

AI <-> lua coms is already costly, and it will be even costlier with the giant if branches encessary to implement the various menagerie of code to interpret the messages and responses on either side of the divide.

Lets use a standard mechanism, and keep API comm chatter to the precise minimum. At most we should be able to engineer for a maximum of 2 maybe 3 calls across the divide by an AI:

• Retrieve events, data and messages that lua has for us and collect data needed for the next frame
• Send events messages and commands, and receive anything more lua gadgets have for us
• Any unavoidable requests as a result of the above.

Sure there will be momentary trips across the divide that increase this, but the idea of taking a single command and sending it as an individual API call is obscenely wasteful.

The refusal to accept lua tables and lua structures also removes a number of possibilities and vastly increases the potential complexity involved without resorting to another data format and reintroducing all the problems originally argued against.

[slind]

slind... guess what, i know that. read the whole post; your comment makes no sense.

Sorry to have offended you.

The refusal to accept lua tables and lua structures also removes a number of possibilities and vastly increases the potential complexity involved without resorting to another data format and reintroducing all the problems originally argued against.

I don't understand what you are trying to say. I haven't argued for or against using lua tables or structures as the data type to be serialized. My question/statement is how to serialize the data we do want to send, be it tables or otherwise. Without modification to the engine we do not have access to the Lua_state in C++ land which eliminates our ability to work with the Lua stack, this means that whatever data structure we do use must be serialized in Lua land before it is passed across the engine to the AI.

to engineer for a maximum of 2 maybe 3 calls across the divide by an AI

I agree.

All doable at the moment in Shard using pure native lua APIs as documented at the official lua website

You have already written table serialization/serialization in C++ and Lua?

[hoijui]

slind... guess what, i know that. read the whole post; your comment makes no sense.

Sorry to have offended you.

you still don't get it. the thing is, that having to modify (each) game is a big obstacle in practice, therefore direct AI<=>widget communication would be important to have. of course this does not make away with any problems, but at least with the ones where AI needs no communication with synced stuff.

[AF]

Eitherway we're going to end up with a an AI utility gadget of some sort with standardisation to facilitate AI lua comms.

lua can do serialisation perfectly fine without C++ involvement. At least were Shard is concerned. Reading the responses that get returned shouldn't be too much of an issue since there'll be no executable code ( unless indicated ).

[slind]

lua can do serialisation perfectly fine without C++ involvement. At least were Shard is concerned.

How does lua do its serialization? I can't find any built in commands that do serialization.

Reading the responses that get returned shouldn't be too much of an issue since there'll be no executable code ( unless indicated ).

On which side?

you still don't get it.

I understand what you intend now. I thought you didn't understand that Unsynced Lua could communicate with Synced Lua and vice versa and that the AI could therefore communicate with Unsynced Lua.

For this reason, it is possible to supply an *AI Synced Gadget* which would provide AI<->Widget communication without requiring modification to the engine. Due to the fact that games must adhere to a set of stipulated rules if they want to use the generalised AI support then a game would have to include the provided gadget.

therefore direct AI<=>widget communication

Which is a separate problem from possible communication. Regardless, I apologise for appearing to be overly ignorant of the situation.

[jK]

slind... guess what, i know that. read the whole post; your comment makes no sense.

Sorry to have offended you.

you still don't get it. the thing is, that having to modify (each) game is a big obstacle in practice, therefore direct AI<=>widget communication would be important to have. of course this does not make away with any problems, but at least with the ones where AI needs no communication with synced stuff.

A good existing solution for that are the LuaRulesParams. AIs already got a limited interface to them, but can't receive the values of string indexed ones.
Widgets don't need any communication with AIs at all, widgets run locally on all clients while the AI is just running on one client totally independent of the rest -> as it would be an additional client connected to the host. Such things would be only important if there would be something similar as synced AIs e.g. as chickens, capture the flag, ... (but atm those things are done via Lua).