Spring RTS Engine

I will double check my code on monday or tuesday and get back to you.

if your going to write a parser Whats the point in talking about it if you don't get it done? I think a DOM type OO structure If you want it to be as generic as you have written up then yes. Secretly I was hoping it was going to be much simpler then that. If we merely returned a string then we coul...

I have attached a basic Lua parser class for C++. Currently it only parses and error checks the replies section. I am still a little unsure of how you want to do the messages and the error section exactly. Steps to use: 1)Include the header file. 2)Create a LuaParser object 3)Access the replies, mes...

Now I am on board completely with what you are saying.

Maaan, lua is weird function gadget:UnitDamaged( unitID, unitDefID, unitTeam, damage, paralyzer, weaponID, attackerID, attackerDefID, attackerTeam ) for t in pairs(myTeam) do if (unitTeam == myTeam[t]) then local goto_x, goto_y, goto_z = Spring.GetUnitPosition (unitID) machTargetArea(myTeam[t], got...

Right. Sending to lua should be in lua. We agreed on that. We are talking about the return string. Correct? Writing an XML/JSON serializer in Lua for the return string is what I have been talking about. I don't know if an XML/JSON serializer is faster than a hand-rolled custom lua format serializer ...

I was a bit confused at first.

You are saying that Lua would return a Lua formatted string, unless the AI specifically asked for a certain type of return format.

So the XML/JSON thing could be optional. Right?

Afterall why write a parser when you can grab some code and have a readymade one thats been tested for you? You have a point, but I was under the impression that we wanted the Lua side to be as efficient and short as possible. As long as the code is vetted and efficiency tested prior to use on the ...

Does everyone else agree? Data would be the payload of a message, and 'message' would be the identifier telling us the kind of message, be it a command, an event, a request, a debugging message, or a purely informative notification. Yes Messagecount This is for debugging purposes Then make it optio...

Because then ID is not just an identifier, it's also a priority for ordering, whereas I'd like the order of messages to be the order, and the flexibility. But anyway, the messages sub table needn't be a dictionary type, or have numeric indices defined for your idea. No, but it makes it easier for c...

I completely disagree. My message format uses standard lua syntax, as such I don't need to follow the examples syntax, as long as it is syntactically correct in vanilla lua. Interesting. I hadn't noticed that. You could just use a loadstring() on it. What's more, this makes things much easier for n...

The first problem I notice is that your strings are denoted by double quotes, which prevents double quotes from being used without processing escape sequences which requires way more processing time then is actually necessary. A simpler(and more accurate) solution is to indicate the length of a mess...

AF wrote:I agree per message should be a dictionary but, we have to consider these need batching together too. We should also add values specifying the number of messages etc for debugging purposes.

A dictionary string has no limit to the number of messages per string.

slind, synced Lua can not be supplied by AIs without modifying the game. synced means, ti can directly alter the game state, so in other words, the game would be a different one. this means, that everyone would have to have that Lua, not just the AI host, and game devs would not want it... and prob...

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 c...

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 ...

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.

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 ...

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:AICa...

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 communicati...