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.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):this is for AIs, and on the lua side, there would be a corresponding sendMsgToAI() method.Code: Select all
AICallback { int sendMsgToLua(string/int receiver, string topic, string[] strParams, float[] fltParams, int[] intParams); }
take it appart :D it is meant as a start for discussion.
LuaRules & LuaWidgets API
Moderators: hoijui, Moderators
LuaRules & LuaWidgets API
As quoted by hoijui:
Re: LuaRules & LuaWidgets API
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
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
I still support the much shinier nicer version hoijui suggested[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
Re: LuaRules & LuaWidgets API
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.
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
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:
in the C interface:
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)
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;
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
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
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?
What would this look like on the lua side?
Re: LuaRules & LuaWidgets API
Gadgets only, but they can relay the data further.Can we only communicate to gadgets with this function, or to widgets too?
Nope, AI's have to poll CallLuaRules to get information from them.Can Gadgets/Widgets send messages to AIs?
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
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
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
nice, thank you Kloot!
now ...
what would you think about a more extensive system?
Possible pros:
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.
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
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.