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.
AAI and spring.
Moderator: Moderators
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.
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.
That would be more useful output though, a config file usually is something the user is expected to make so it sounds confusing.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
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))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.)
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
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?KDR_11k wrote:That would be more useful output though, a config file usually is something the user is expected to make so it sounds confusing.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
I think users understand "is not supported" better then something like "file not found; not initialized" (or whatever the exact text is).
and update (= recompile aai) that harcoded list all the time a new mod version is released?rattle wrote:Yeah, just hardcode a small hint message which tells about what mods don't need a config on failure.
one of my main design goals was to keep the binaries free of any hardcoded information about specific game content like units/mods...
-
BrainDamage
- Lobby Developer
- Posts: 1164
- Joined: 25 Sep 2006, 13:56
+1Brain 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
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.
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.
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.
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.
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?
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?
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.Tobi wrote:That would need someone to make sure all systems/layers get that implemented, since it would need:Technically it isn't too hard, but there are lots of people involved, which makes it a pretty huge modification.
- 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.
The trends in AI development suggest 2 paths both contrary to your statement yokozar:
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.
- 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.
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.