View topic - Interface Redesign



All times are UTC + 1 hour


Post new topic Reply to topic  [ 448 posts ]  Go to page Previous  1 ... 16, 17, 18, 19, 20, 21, 22, 23  Next
Author Message
 Post subject: Re: Interface Redesign
PostPosted: 04 Nov 2008, 11:57 
Spring Developer
User avatar

Joined: 22 Sep 2007, 08:51
Agons proposal for Bindings is integrated now.
it is also possible to specify AI options in script.txt now.
it works like this:
Code:
[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.


Top
 Offline Profile  
 
 Post subject: Re: Interface Redesign
PostPosted: 04 Nov 2008, 12:37 
AI Coder
User avatar

Joined: 14 Sep 2004, 10:32
Location: Cookieland
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.


Top
 Offline Profile  
 
 Post subject: Re: Interface Redesign
PostPosted: 04 Nov 2008, 12:49 
Spring Developer
User avatar

Joined: 22 Sep 2007, 08:51
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.


Top
 Offline Profile  
 
 Post subject: Re: Interface Redesign
PostPosted: 04 Nov 2008, 13:51 
Spring Developer
User avatar

Joined: 22 Sep 2007, 08:51
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:
#define EVENT_INIT 0
...
   switch (eventType) {
      case EVENT_INIT:
...

while this does not compile:
Code:
const int EVENT_INIT = 0;
...
   switch (eventType) {
      case EVENT_INIT:
...


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


Top
 Offline Profile  
 
 Post subject: Re: Interface Redesign
PostPosted: 04 Nov 2008, 16:30 
AI Coder
User avatar

Joined: 14 Sep 2004, 10:32
Location: Cookieland
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


Last edited by AF on 04 Nov 2008, 16:38, edited 1 time in total.

Top
 Offline Profile  
 
 Post subject: Re: Interface Redesign
PostPosted: 04 Nov 2008, 16:35 
Spring Developer

Joined: 24 Jun 2007, 07:34
Location: 50┬░ 56' N, 11┬░ 35' O
You could use enum instead of const int:
http://en.wikipedia.org/wiki/Switch_statement#C_.28const_int_illegal_in_switch.29


Top
 Offline Profile  
 
 Post subject: Re: Interface Redesign
PostPosted: 04 Nov 2008, 16:40 
Lobby Developer
User avatar

Joined: 25 Sep 2006, 12:56
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] .


Last edited by BrainDamage on 04 Nov 2008, 16:45, edited 2 times in total.

Top
 Offline Profile  
 
 Post subject: Re: Interface Redesign
PostPosted: 04 Nov 2008, 16:43 
AI Coder
User avatar

Joined: 14 Sep 2004, 10:32
Location: Cookieland
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.


Top
 Offline Profile  
 
 Post subject: Re: Interface Redesign
PostPosted: 04 Nov 2008, 17:11 
Spring Developer
User avatar

Joined: 22 Sep 2007, 08:51
Brain Damage wrote:
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

Brain Damage wrote:
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?)


Top
 Offline Profile  
 
 Post subject: Re: Interface Redesign
PostPosted: 04 Nov 2008, 17:51 
AI Coder
User avatar

Joined: 14 Sep 2004, 10:32
Location: Cookieland
Theyre implemented via lua gadgets iirc, Im not sure, look at kernel panic.


Top
 Offline Profile  
 
 Post subject: Re: Interface Redesign
PostPosted: 04 Nov 2008, 18:01 
Spring Developer
User avatar

Joined: 22 Sep 2007, 08:51
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}


Top
 Offline Profile  
 
 Post subject: Re: Interface Redesign
PostPosted: 04 Nov 2008, 18:20 
Lobby Developer
User avatar

Joined: 25 Sep 2006, 12:56
hoijui wrote:
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 )


Top
 Offline Profile  
 
 Post subject: Re: Interface Redesign
PostPosted: 05 Nov 2008, 11:36 
AI Coder
User avatar

Joined: 14 Sep 2004, 10:32
Location: Cookieland
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.


Top
 Offline Profile  
 
 Post subject: Re: Interface Redesign
PostPosted: 05 Nov 2008, 15:11 
Spring Developer

Joined: 01 Jun 2005, 10:36
Location: The Netherlands
Unitsync doesn't have APIs for non LUA AIs.

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


Top
 Offline Profile  
 
 Post subject: Re: Interface Redesign
PostPosted: 05 Nov 2008, 16:51 
AI Coder
User avatar

Joined: 14 Sep 2004, 10:32
Location: Cookieland
I believe it was the intention that such APIs be added


Top
 Offline Profile  
 
 Post subject: Re: Interface Redesign
PostPosted: 05 Nov 2008, 17:14 
Spring Developer
User avatar

Joined: 22 Sep 2007, 08:51
yes, i added them:
Code:
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:
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.


Top
 Offline Profile  
 
 Post subject: Re: Interface Redesign
PostPosted: 05 Nov 2008, 17:21 
AI Coder
User avatar

Joined: 14 Sep 2004, 10:32
Location: Cookieland
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.


Top
 Offline Profile  
 
 Post subject: Re: Interface Redesign
PostPosted: 05 Nov 2008, 18:05 
Spring Developer
User avatar

Joined: 22 Sep 2007, 08:51
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.


Top
 Offline Profile  
 
 Post subject: Re: Interface Redesign
PostPosted: 05 Nov 2008, 21:12 
AI Coder
User avatar

Joined: 14 Sep 2004, 10:32
Location: Cookieland
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.


Top
 Offline Profile  
 
 Post subject: Re: Interface Redesign
PostPosted: 05 Nov 2008, 22:19 
Spring Developer
User avatar

Joined: 22 Sep 2007, 08:51
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.


Top
 Offline Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 448 posts ]  Go to page Previous  1 ... 16, 17, 18, 19, 20, 21, 22, 23  Next

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group

Site layout created by Roflcopter et al.