Interface Redesign

[hoijui]

Agons proposal for Bindings is integrated now.
it is also possible to specify AI options in script.txt now.
it works like this:

Code: Select all

[TEAM0]
	{
		TeamLeader=x;   // player number that is the "leader"
		AllyTeam=number;
		RgbColor=red green blue;  // red green blue in range [0-1]
		Side=Arm/Core;  // other sides possible with user mods i suppose
		Handicap=0-100; // Percent bonus on all resources collected ?
		StartPosX=0;    // Use these in combination with StartPosType=3
		StartPosZ=0;    // range is in map coordinates as returned by unitsync (NOT like StartRectTop et al)
		LuaAI=name;     // name of the LUA AI that controlls this team
		[AI]            // [optional]Skirmish AI section
		{
			Name=RAI;     // name of the Skirmish AI that controlls this team
			              // (see spring.exe --list-skirmish-ais for possible values))
			Version=0.1;  // [optional] version of the Skirmish AI that controlls this team
			[OPTIONS]     // [optional] contains AI implementaition specific option values
			{
				difficultyLevel=1;
			}
		}
		// Either LuaAI is set, the [AI] section is defined or none of the two.
		// The TeamLeader field indicates which computer the a Skirmish AI will run on.
	}

as yo usee, the AI has now its own subsection under TEAM.
an other option would be to have the AI section outside of the TEAM section, directly under section GAME. As an AI is kind of an equivalent to a PLAYER, which is also directly under GAME, this would make sense.
please "vote" pro or contra that idea.

[AF]

I think we shouldnt introduce redundancy in our filenames by appending them with lots of things like ainame-skirmishai.dll since that sort of stuff can be specified in the lua file anyway, and arguably should so that flexibility is maximized.

[hoijui]

yeah, that is how it works right now (the name is specifyed in the lua file).
i take it you would prefer the second way? or even the first one?
of course they can be mixed, its jsut a question of what we will have as a default guideline somehow.

[hoijui]

about the planned move from #defines to const:

i found out (asked in a C chat), that C does not allow variables as labels for case in a switch statement. therefore, i have to stick to define (see example below).

this works:

Code: Select all

#define EVENT_INIT 0
...
   switch (eventType) {
      case EVENT_INIT:
...

while this does not compile:

Code: Select all

const int EVENT_INIT = 0;
...
   switch (eventType) {
      case EVENT_INIT:
...

Test Code:
http://rafb.net/p/ZXVpBf80.html

[AF]

Ive never been fond of switch case statements lol.

However I'm not sure this is really relevant though as this is not part of the binary interface, as such the choice between #define and integers is purely the AI developers choice in the end, just as the choice between if/else and switch case statements is.

And even if engine side you used variables, you could use #defines in the AI or implementation library and it wouldn't make a difference because those variables in the engine have constant unchanging values

[Auswaschbar]

You could use enum instead of const int:
http://en.wikipedia.org/wiki/Switch_sta ... _switch.29

[BrainDamage]

more like for logic, i'd say the [AI] is a section comparable to [PLAYER], then you assign a team to the [AI] as normal

oh btw, is the luaai / normal ai tag separation really that necessary? can't the type be inferred from the name or maybe by tag aitype=lua
EDIT: or maybe even another section comparable to [AI] and [PLAYER] such as [LUAAI] .

[AF]

Aha I've just noticed that, we sort of already agreed upon lua AIs and other AIs needing the same mechanism rather than separate tags for both consistency and flexibility earlier in the thread.

[hoijui]

more like for logic, i'd say the [AI] is a section comparable to [PLAYER], then you assign a team to the [AI] as normal

+1

oh btw, is the luaai / normal ai tag separation really that necessary? can't the type be inferred from the name or maybe by tag aitype=lua
EDIT: or maybe even another section comparable to [AI] and [PLAYER] such as [LUAAI] .

i just remember we didnt want ot have two things in one tag. we changed aispecifier=name#version to ainame=name and aiversion=version. i would prefer LuaAI to be its own tag (or even section, as you suggested).

AF, do you suggest specifying a LUA AI in the same sort of section like an AI? with name, version and OPTIONS?
i dont know how lua AIs work, with what they come (do they have options?)

[AF]

Theyre implemented via lua gadgets iirc, Im not sure, look at kernel panic.

[hoijui]

am using enums for AI event and command topics now.
thanks Auswaschbar

all i know about LUA As, is that the lobby specifies them with a single string, and i know where this string has to end up in the engine. I do not want to know more
you lobby devs just tell me how you want to specify it in the start script, and i'll do it then.

possible options mentioned so far:

• GAME//TEAM0//LuaAI={name}
• GAME//AI0//LuaAI={name}
• GAME//AI0//name=LuaAI:{name}
• GAME//AI0//type=LUA & GAME//AI0//name={name}
• GAME//AI0//isLua=true & GAME//AI0//name={name}
• GAME//LUAAI0//name={name}

[BrainDamage]

all i know about LUA As, is that the lobby specifies them with a single string, and i know where this string has to end up in the engine. I do not want to know more
you lobby devs just tell me how you want to specify it in the start script, and i'll do it then.

possible options mentioned so far:

• GAME//AI0//type=LUA & GAME//AI0//name={name}
• GAME//LUAAI0//name={name}

those 2 options are what I'd use, i don't care much of the 2 which is picked, but i personally slightly prefer the first syntax
EDIT: fixed (i wrote second instead of first )

wrt luaai: the mod creates a list of ais into a LuaAi.lua file in the mod package, unitsync parses the list and offers an interface for the lobby to list them and acquire their destrciption, perhaps such function could be merged with the new unitsync functions to list Ais, the only difference is that LuaAIs are strictly mod related.
the lobby writes the luaai name in the script, then a lua script in the mod will parse the script.txt, and access the info, once the luaai player(s) are found, it will put them into control of other lua scripts within the mod which implements an ai in lua (using LuaRules )

[AF]

I do not like any of those options because they all require special case code in the lobby.

Lua AIs should be encapsulated in the AI interface APIs of unitsync, and the lobby should not have to make special allowances for it. 1 way of specifying AIs and ONLY one way of specifying AIs. Not 2 ways depending on the type of AI.

The lobby deals with AIs, it shouldn't be juggling AIs around with if statements and various structures, it should just work in one generic flowing system with an easy to comprehend system for specifying them.

[Tobi]

Unitsync doesn't have APIs for non LUA AIs.

Or did you add, or plan to add, such APIs in your branch hoiju?

[AF]

I believe it was the intention that such APIs be added

[hoijui]

yes, i added them:

Code: Select all

Export(int) GetSkirmishAICount();

Export(struct SSAISpecifier) GetSkirmishAISpecifier(int index);

std::vector<InfoItem> ParseInfos(
		const std::string& fileName,
		const std::string& fileModes,
		const std::string& accessModes);
static void CheckInfoIndex(int infIndex);

Export(int) GetSkirmishAIInfoCount(int index);

Export(const char*) GetInfoKey(int index) ;
Export(const char*) GetInfoValue(int index);
Export(const char*) GetInfoDescription(int index);

Export(int) GetSkirmishAIOptionCount(int index);

AF:
for what you want, LuaAIs would need AIInfo.lua files under AI/Skirmish/
but as they are mod specific, i guess that is no option.
or we had to add LUA AI info in unitsync:

Code: Select all

Export(int) GetSkirmishAIInfoCount(int index);

first read from the skirmish lua files, then read from the mod...
but it would still not work, casue when specifying a Lua AI in the exact same way as a normal one, the engine would look for the specified name in the skirmish AI lua files, and not find it.

[AF]

I see no reason why we cannot make lua AIs add lua info files in the archive.

But I also dont see why we cant just implement a wrapper in unitsync around lua AIs so we don't need to do that either. It makes more sense to have special case code in just unitsync than to replicate that code in every single lobby bot tool and auto host in existence. Lets practice encapsulation here and pick 1 interface for 1 thing not 2 interfaces for 1 thing that requires extra code and complicates things more than it needs to.

[hoijui]

it are 2 things, not 1.
this is obvious, cause we need to have special case code somewhere.
i agree it would be better to have it in unitsync thne in hte lobbies, if you look at just the "once vs many times". but having it in unitsync is simply not enough. the engine would need to know too if it is a Lua AI or not. but if lobbies specify lua and skirmish AIs the same way, the engine would not know that.
the engine could compare the name with all the skirmish AI names, and if it is not found there, assume it is a lua AI, or compare the name with the available LUA AIs.

[AF]

As a lobby developer I'm blissfully ignorant of whether an AI is a lua gadget or a C library.

Now as I understand, unitsync is not stateless, and theres no reason that once AIs in lua are found that the fact theyre lua AIs should be discarded at all.

[hoijui]

is the lobby writing the start script directly or through unitsync?
i alwyas though the lobbies write the start script directly. if so, it makes no difference if unitsync knows wether the AI is Lua or not, as long as the lobby does not know it. it is hte engine that will have to know it in the end, not unitsync.