Lua <-> AI Generalised message standard proposal

[slind]

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, messages or errors vectors from the LuaParser object

Example:

Code: Select all

	string testVar ="{replies = {{returned=\"success\"},{returned=\"failure\",}}}";

	LuaParser testParser(testVar);

	for(int i =0;i < testParser.replies.size();i++)
	{
		cout<< i<<" Reply Returned value is: " << testParser.replies[i] <<endl;
	}
	for(int i =0;i < testParser.messages.size();i++)
	{
		cout<< i<<" mesage is: " << testParser.messages[i] <<endl;
	}
	for(int i =0;i < testParser.errors.size();i++)
	{
		cout<< i<<" Error is: " << testParser.errors[i] <<endl;
	}

[AF]

I was hoping for discussion on that.

Return messages are of the same format as those sent to lua, I merely chose returned as the key value pair because it was the first thing that popped into my mind for that particular example, not because thats how messages are sent back as a single value.

e..g. say we sent a message to the gadgets asking for the locations of 'mystery prize' spots within a certain radius of a location, we could get a response like this:

Code: Select all

{
    replies = {
        {
            spotsfound=true,
            spots= {
                {5,60,7},
                {20,9001,2}
            }
        }
    }
}

The only thing distinguishing it from a message sent from the AI to lua, is that we ommitted the message variable from the table, because the AI should already know this, after all it was the AI that sent the message, why should it need telling in the reply

If we merely returned a string then we could end up encapsulating this whole spec inside that string again leading to lots of wasteful processing and various competing standards at varying layers to think of

[AF]

hmmm if your going to write a parser I think a DOM type OO structure would be more appropriate given what I've seen of your code and my clarification.

[slind]

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 could end up encapsulating this whole spec inside that string again leading to lots of wasteful processing and various competing standards at varying layers to think of

I was kind of thinking that this is what was going to happen anyways. Regardless of any constraints we place on the system, or how deep we parse, the parser is never going to know what the data in the string means. It is going to have to leave it in a string, both the key and the data are going to have to be left as strings.

Now we could use a Map instead of a Vector to store the key/value, which is fine by me, but the return value (and key) is going to be left as a string.

Once the return value gets passed back to the AI it is going to have to parse it itself based upon the message that it sent.

[EDIT:] I realise this sounds like I am saying this is the only way, I am not. This is a possible way to do it. If you would like a more DOM way to do it then we could have Results, messages, etc also be parsed as strings and mapped to their held values. Regardless, the parser doesn't know anything about the data still.

The parser is going to do the following:
Break up the return message into three sections:

results
messages
errors

Results will be the same size as the messages array that was passed to lua. Results[0] will correspond to whatever the AI sent Lua in the 0th position.
Messages will be arbitrary size.
Errors will be arbitrary size.

Results, Messages and Errors will be maps keyed off of strings that lua sends. Either we can make it so that people will use map iterators and the map variables directly or we write functions that return key/value pairs.

What to do with the strings will be the responsibility of the AI.

[AF]

Indeed this spec covers how to send messages, not what messages should actually contain ( aside from one or two special cases we haven't defined yet such as startup and errors).

The old TDF Parsers did a good job of doing the same job, and they supported nested structures too.

Something like this:

Code: Select all

LuaDataParser* table = new LuaDataParser(luastring);
LuaTable* t = table->getTable("messages")->getTable(0);
std::string* message = t->getString("message");

Type conversion need only occur upon request. Data/key values can be stored in string form, and tables can be held in another data structure in the LuaTable class. LuaDataParser will inherit from LuaTable and have additions for being the root.

Arguably LuaTable itself can act as the parser taking a table string as its constructor argument and passing the strings of child tables to new instances internally.