Page 1 of 1

LuaRules & LuaWidgets API

Posted: 04 Oct 2009, 19:54
by AF
As quoted by hoijui:
hoijui wrote:It would be good to have an AI dedicated Lua coder around, that could do stuff like this. i would have some wishes too :D

about the AI<->Lua communication:
i already proposed in an other thread (can not find it anymore):

Code: Select all

AICallback {
   int sendMsgToLua(string/int receiver, string topic, string[] strParams, float[] fltParams, int[] intParams);
}
this is for AIs, and on the lua side, there would be a corresponding sendMsgToAI() method.
take it appart :D it is meant as a start for discussion.
I would support such an implementation, and in my opinion this warrants an engine release. This is hyper critical, and I'm sure there is nobody in this forum who would disagree with me on that.

Re: LuaRules & LuaWidgets API

Posted: 04 Oct 2009, 20:02
by Kloot
How many times does this topic have to be repeated? Native AI libs can *already* communicate with mod-side Lua gadgets (LuaRules), and have been able to do so for literally *years*. Seriously, what is the problem?

Re: LuaRules & LuaWidgets API

Posted: 04 Oct 2009, 20:06
by AF
I was under the impression we had it too until hoijui said otherwise, I was under the impression we had the callback trepan implemented and hoijui had copied it over =/

Re: LuaRules & LuaWidgets API

Posted: 04 Oct 2009, 20:09
by AF
[19:13:31] <[]AF> kloot says we do infact have a lua callout and have done for years
[19:13:46] <[ARP]hoijui> ahh yeah :D
[19:13:58] <[ARP]hoijui> it is a command now, not a function in the callback :D
[19:14:12] <[ARP]hoijui> thats why i did nto find it.. though.. it is obvious that this is a command
[19:14:25] <[ARP]hoijui> in the legacy callback, it is a function
[19:14:34] <[ARP]hoijui> CallLuaRules
[19:14:43] <[ARP]hoijui> it is more limited i would say
[19:15:02] <[]AF> agreed
[19:15:17] <[]AF> but it does mean I can continue with what i wanted todo without waiting for a spring release
I still support the much shinier nicer version hoijui suggested

Re: LuaRules & LuaWidgets API

Posted: 04 Oct 2009, 20:12
by Kloot
It (the CallLuaRules callout) is still there in the legacy C++ callback.

edit: ah, I see where the confusion stems from now. The C interface layer implements everything as a command (structures whose fields you have to fill and read back), so you wouldn't find it in the usual place.

Re: LuaRules & LuaWidgets API

Posted: 04 Oct 2009, 20:26
by hoijui
woops :D
i always checked the callback, but it is a command (in the C interface), which perfectly makes sense of course.

in the legacy interface, it looks like:

Code: Select all

	// NOTES:
	// 1. 'data' can be setup to NULL to skip passing in a string
	// 2. if inSize is less than 0, the data size is calculated using strlen()
	// 3. the return data is subject to lua garbage collection,
	//    copy it if you wish to continue using it
	virtual const char* CallLuaRules(const char* data, int inSize = -1, int* outSize = NULL) = 0;
in the C interface:

Code: Select all

struct SCallLuaRulesCommand {
	/// Can be setup to NULL to skip passing in a string
	const char* data;
	/// If this is less than 0, the data size is calculated using strlen()
	int inSize;
	int* outSize;
	/// this is subject to lua garbage collection, copy it if you wish to continue using it
	const char* ret_outData;
}; // COMMAND_CALL_LUA_RULES
AF just told me that this is enough for him, for now.

But it looks rather limited to me.
What if we have a method like the one i suggested, plus an additional out parameter.
Some thing i am not sure about:
Can we only communicate to gadgets with this function, or to widgets too?
Can Gadgets/Widgets send messages to AIs? (could be usefull for special events not directly supported by spring, eg: WeatherChangedEvent)

Re: LuaRules & LuaWidgets API

Posted: 04 Oct 2009, 20:34
by AF
I suppose taking the example of the grid overlay widget, we would do something along the lines of the following for a 2x2 grid using this api, 2,2,4,4,4,4 and then at the lua end it'd be separated out into an array via commas?

What would this look like on the lua side?

Re: LuaRules & LuaWidgets API

Posted: 04 Oct 2009, 23:19
by Kloot
Can we only communicate to gadgets with this function, or to widgets too?
Gadgets only, but they can relay the data further.
Can Gadgets/Widgets send messages to AIs?
Nope, AI's have to poll CallLuaRules to get information from them.
What would this look like on the lua side?

Code: Select all

function gadget:AICallIn(str)
    t = {}
    for m in str:gmatch("[0-9]*") do
        if (m ~= "") then
            t[#t + 1] = tonumber(m)
        end
    end

    -- etc
end

Re: LuaRules & LuaWidgets API

Posted: 04 Oct 2009, 23:49
by AF
Nifty, couldn't we format a lua table complete with lua syntax at the AI end and send that string through?

Re: LuaRules & LuaWidgets API

Posted: 05 Oct 2009, 00:22
by Kloot
Yes, if you like:

Code: Select all

-- eg. CallLuaRules("t = {[1] = 3, [2] = 2, [3] = 1}", ...);
function gadget:AICallIn(str)
    f, err = loadstring(str)
    if (f) then
        f(); print(t[1], t[2], t[3])
    else
        print(err)
    end
end

Re: LuaRules & LuaWidgets API

Posted: 05 Oct 2009, 10:14
by hoijui
nice, thank you Kloot!

now ...
what would you think about a more extensive system?
Possible pros:
  • no need for polling
  • possibly performance improvements? (eg, no need to convert numbers to strings and back)
  • possible use-case improvements (dont know how to describe it well in short):
    If an event/message has an ID/topic, it is easier for mod-/AI-devs to work
    with the system, as they can just run a mod with an AI, and log the messages
    the mod/AI receives, and analyze the topics & number of parameters, wich
    would be a system common to all mods/AIs, instead of having to know the way of
    how data is packed by a specific mod/AI
in the already proposed method, we could add a flag for the receiver: gadgets,widgets,both
this would eliminate the need for the mod to be modified in a situation like AFs:
eg, the AI comes with a custom widget that shows data on the map.