AAI and spring.

AAI and spring.

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

Post Reply
User avatar
smoth
Posts: 22295
Joined: 13 Jan 2005, 00:46

AAI and spring.

Post by smoth » 09 Dec 2007, 16:45

Why is it included? will it be in the next version of spring? I get a lot of word from new players about how hard it is to play ai when 99.9999999999% it is aai. Could RAI be included instead? I find rai works pretty decent and will not kick out as many errors as AAI or Kai.

Having an ai that requires a config file is not very user friendly.
0 x

Tobi
Spring Developer
Posts: 4598
Joined: 01 Jun 2005, 11:36

Post by Tobi » 09 Dec 2007, 17:07

IMHO we should test each mod that is going to be included with the installer with each AI that is going to be included with the installer. (I did that previous releases too)

Except some major incompatibilities (like AAI/KAI on KP?) that should make stuff work. Maybe someone could patch AAI/KAI so that it gives better messages if it can not play a particular mod.
0 x

submarine
AI Developer
Posts: 804
Joined: 31 Jan 2005, 20:04

Post by submarine » 09 Dec 2007, 20:54

simply dont include a cfg file for the mod; aai will display a message (iirc every few seconds) that it has not been initialized and is not running.

i really dont want to hardcode "mod xy is not supported" -messages
0 x

imbaczek
Posts: 3629
Joined: 22 Aug 2006, 16:19

Post by imbaczek » 09 Dec 2007, 20:56

any chance of generating a simplistic default config if none exists? AAI just won't work if mods will release updates soon after next release, unless there's a separate AI updater (which would be cool to have.)
0 x

User avatar
KDR_11k
Game Developer
Posts: 8293
Joined: 25 Jun 2006, 08:44

Post by KDR_11k » 09 Dec 2007, 21:04

submarine wrote:simply dont include a cfg file for the mod; aai will display a message (iirc every few seconds) that it has not been initialized and is not running.

i really dont want to hardcode "mod xy is not supported" -messages
That would be more useful output though, a config file usually is something the user is expected to make so it sounds confusing.
0 x

User avatar
rattle
Damned Developer
Posts: 8278
Joined: 01 Jun 2006, 13:15

Post by rattle » 09 Dec 2007, 21:11

Yeah, just hardcode a small hint message which tells about what mods don't need a config on failure.
0 x

submarine
AI Developer
Posts: 804
Joined: 31 Jan 2005, 20:04

Post by submarine » 09 Dec 2007, 21:14

imbaczek wrote:any chance of generating a simplistic default config if none exists? AAI just won't work if mods will release updates soon after next release, unless there's a separate AI updater (which would be cool to have.)
yes, technically it wouldnt be any problem to use the default config (default values will be set in AAICfg and later overridden with values from the cfg file (if a certain value is specfied in the mod cfg))

the main reason i dont let aai play with these default values (they should be ok for most ota based mods): most ppl would never realize that a cfg file for the mod/its current version missing and thus suffer from a (much) weaker performance ( for example aai cannot play effectivly without knowing which unit are scouts ) of aai...

therefore players who want to use aai are forced to spend 5 minutes reading the documentation
0 x

Tobi
Spring Developer
Posts: 4598
Joined: 01 Jun 2005, 11:36

Post by Tobi » 09 Dec 2007, 21:16

KDR_11k wrote:
submarine wrote:simply dont include a cfg file for the mod; aai will display a message (iirc every few seconds) that it has not been initialized and is not running.

i really dont want to hardcode "mod xy is not supported" -messages
That would be more useful output though, a config file usually is something the user is expected to make so it sounds confusing.
submarine, maybe you could change it to output "mod xy is not supported" (+ some blahblah about config file) then if the config file is not present?

I think users understand "is not supported" better then something like "file not found; not initialized" (or whatever the exact text is).
0 x

submarine
AI Developer
Posts: 804
Joined: 31 Jan 2005, 20:04

Post by submarine » 09 Dec 2007, 21:16

rattle wrote:Yeah, just hardcode a small hint message which tells about what mods don't need a config on failure.
and update (= recompile aai) that harcoded list all the time a new mod version is released?

one of my main design goals was to keep the binaries free of any hardcoded information about specific game content like units/mods...
0 x

submarine
AI Developer
Posts: 804
Joined: 31 Jan 2005, 20:04

Post by submarine » 09 Dec 2007, 21:17

Tobi wrote:
submarine, maybe you could change it to output "mod xy is not supported" (+ some blahblah about config file) then if the config file is not present?
agreed, i'll do that
0 x

User avatar
BrainDamage
Lobby Developer
Posts: 1164
Joined: 25 Sep 2006, 13:56

Post by BrainDamage » 09 Dec 2007, 21:23

this is more of a feature request: how about an unitsync option to list AIs and return wich mods they are comaptible with?

that way users will stop trying to use AIs with mods they are not compatible with
0 x

YokoZar
Posts: 883
Joined: 15 Jul 2007, 22:02

Post by YokoZar » 10 Dec 2007, 01:16

Brain Damage wrote:this is more of a feature request: how about an unitsync option to list AIs and return wich mods they are comaptible with?

that way users will stop trying to use AIs with mods they are not compatible with
+1

The lobby interface should be able to hide AIs that will not work on the given mod. The user should never be presented with the option of using AAI on kernel panic if it won't work.
0 x

Tobi
Spring Developer
Posts: 4598
Joined: 01 Jun 2005, 11:36

Post by Tobi » 10 Dec 2007, 01:47

That would need someone to make sure all systems/layers get that implemented, since it would need:
  • AI API to query them which mods they support / whether they support a particular mod.
  • Code in unitsync to load AIs and query them with that interface. It should preferably not crash if an AI crashes or if DLL can not be loaded, but asking all that may be pretty much impossible, in particular handling segfaults. Best bet would be to write some code that makes sure an AI that segfaults once will be added to a blacklist, so unitsync (and hence the lobby the user uses) is not permanently broken.
  • Unitsync API to make that data available to lobbies
  • Lobby authors to use that API to enable/disable AIs depending on mod.
Technically it isn't too hard, but there are lots of people involved, which makes it a pretty huge modification.
0 x

User avatar
AF
AI Developer
Posts: 20667
Joined: 14 Sep 2004, 11:32

Post by AF » 10 Dec 2007, 02:43

An AI usually cant tell if it lacks support for a mod untill tis ingame with that mod, and event hen ti may attempt to play the mod unsuccesfulyl and nto realize.

The problem is a lot more complex than you'd think, and a set of algorithms and blacklisting won't work, because they let in too many false positives and negatives. For example that mods config may be updated allowing full support of a mod where only partial support was there before but the AI has already been flagged as not supporting that mod.

Instead I would suggest that the lobby itself handle this rather than unitsync or the AIs. It would be nice to have a method to retrieve AI names, and an extra method to retrieve some descriptive data such as an integer value for the version, a string value, and a description in plaintext and html.
0 x

submarine
AI Developer
Posts: 804
Joined: 31 Jan 2005, 20:04

Post by submarine » 10 Dec 2007, 09:17

AF wrote:An AI usually cant tell if it lacks support for a mod untill tis ingame with that mod, and event hen ti may attempt to play the mod unsuccesfulyl and nto realize.
+1
0 x

Tobi
Spring Developer
Posts: 4598
Joined: 01 Jun 2005, 11:36

Post by Tobi » 10 Dec 2007, 09:31

Earlier posts in this thread suggested otherwise.

AAI doesn't work without config file for the respective mod, NTAI (probably?) doesn't work without config file. The fact that an AI can find out that it has no config file when it is in game, means the same AI can also find out that it has no config file when it is not in game. Also note that it is possible for unitsync to map the mod archive into the VFS before querying the AI, meaning the AI could even read modinfo.tdf, which is probably one of the complications you speak about.

Also you need to reread my post regarding the blacklist: it would only be ment to keep unitsync working if an AI crashes in the functions called by unitsync to query which mods it supports. It is only an emergency mechanism to make sure a single bugged AI DLL can't break a users Spring install totally.

I don't see how it's easier for lobbies to handle this (at least not in a generic way), and a hardcoded (or config file) AI/mod matrix is easy no matter who implements it & where it is implemented, but to me it still seems like a waste of development time if all lobbies have to implement that themselves (ie. code duplication), while the list should in principle be the same for all lobbies. (It doesn't make sense for springlobby to support AAI on KP but for TASClient to not support AAI on KP.)

And yeah, I realize you'll never get it 100% perfect, but is that a reason to just discard it altogether?
0 x

YokoZar
Posts: 883
Joined: 15 Jul 2007, 22:02

Post by YokoZar » 10 Dec 2007, 11:42

Tobi wrote:That would need someone to make sure all systems/layers get that implemented, since it would need:
  • AI API to query them which mods they support / whether they support a particular mod.
  • Code in unitsync to load AIs and query them with that interface. It should preferably not crash if an AI crashes or if DLL can not be loaded, but asking all that may be pretty much impossible, in particular handling segfaults. Best bet would be to write some code that makes sure an AI that segfaults once will be added to a blacklist, so unitsync (and hence the lobby the user uses) is not permanently broken.
  • Unitsync API to make that data available to lobbies
  • Lobby authors to use that API to enable/disable AIs depending on mod.
Technically it isn't too hard, but there are lots of people involved, which makes it a pretty huge modification.
I like this idea, especially in the long run. There will never be a single AI that runs every mod optimally, and we will likely have some AIs designed for specific mods (or even campaign levels). So, sooner or later, this sort of functionality will be needed.
0 x

User avatar
AF
AI Developer
Posts: 20667
Joined: 14 Sep 2004, 11:32

Post by AF » 10 Dec 2007, 12:25

The trends in AI development suggest 2 paths both contrary to your statement yokozar:
  • Extendibility via configs and scripted languages. Modders and AI developers work together to provide maintain and use basic AI callbacks to allow the mod side to tell the AI side any extra information it needs and provide extra logic where the AI is lacking and no other mod needs it. Here youg et exactly what you asked for, but you the modder have to put in a small amount of work telling it first.
  • Universal mod support algorithms based around generic concepts. This does give the widest support, however due to its generic nature it has limits before you have a trade off between sleep/Real life and ingame performance. At which point the algorithms start to prefer certain game style, most likely general TA style economies. This style of AI is responsible for the poor AI perception of spring and is also the area most effort has gone into due to a lack of modder enthusiasm, and a refusal to accept responsibility for single player support in their mods.
By a lobby method I mean a database. For one simply saying true if theres a config and false if there isnt just wont work. Some configs play horrifically poor and are slapped together in a minute, say only the commander has been told what to build and the peewee is the only attacker, or that AAI config only has 1 of the 2 sides defined.

That random config may actually be a demo proving the AI can use the mod, not a playable version. There may even be multiple configs.


Sadly with AIs about 99% of the errors that actually occur are access violations/segfaults, usually relating to array usage or null pointer access. Any AI crashes outside of that usually don't happen untill the AI has been running for at least 10 minutes. For example if I introduce a bug with mutexes or boost::shared_ptr I wont see it take effect untill around the 15 minute mark, which is why all my tests are 20 mins minimum.

Which is why a note or two written by another user or a poll for a version of an AI is so much more appropriate, a message from the AI developer written after its release even.
0 x

Post Reply

Return to “Engine”