Page 1 of 1

AI whitelists, a trivial solution

Posted: 26 Apr 2017, 14:27
by AF
I would like to note the following things:

- When a native AI doesn't support a game, it shouldn't attempt to play it and say so. It also shouldn't crash
- LuaAIs are gadgets and have full control over event handling

With those 2 things in mind, lets remember that LuaAIs have to figure out which teams they belong to on their own.

So if you're playing a game that none of the native AIs support, you have a LuaAI, and you know the native AI will not do anything if loaded....

Load the LuaAI instead!!

For example: ... .lua#L4100

If that loop had an extra clause that checked for AAI and loaded CAI instead if it was true, then that would solve almost all the issues game devs have with AAI.

No whitelists necessary

Re: AI whitelists, a trivial solution

Posted: 26 Apr 2017, 16:53
by Google_Frog
That solution is bad UI. If players have two options, AAI and CAI, then they would rightly report a bug when both options result in the same outcome. The lobby would be incorrectly presenting too many options.

The fix also strikes me as a bit of a hack. If overriding AIs with LuaAIs is an accepted solution then I predict there will be no standards. AI whitelists will be spread throughout gadgets instead of standardized to a particular file. What if someone wants to develop a new native AI or try to add compatibility for a previously blocked AI? People who know what they are doing should be able to circumvent the whitelist otherwise no new AI will be written. Such an option could be implemented with a modoption but it would be much better as a lobby setting.

Personally, this isn't a high priority since I already did this: ... cklist.lua

Re: AI whitelists, a trivial solution

Posted: 27 Apr 2017, 16:27
by AF
If an AI has done nothing with its units 20 seconds into the game I'd say its a safe assumption it doesn't support the game, having a hardcoded list of AIs shouldn't be necessary. Eitherway the end result is a superior experience to the current one.

As a sidenote, AIInfo.lua could contain a list of games the AI indicates it supports, I updated Shards AIInfo.lua with such a list

Personally, this isn't a high priority since I already did this: ... cklist.lua
I'm concerned that Shard was added, yet I don't recall ever being told that Shard + ZK had stopped working. There is a ZK config for Shard, can you expand on that?

Re: AI whitelists, a trivial solution

Posted: 30 Apr 2017, 16:58
by code_man
This thread got me on an idea.

How about having native ais be wrapped around per lua ais?
What i mean is having a native ai be loaded (and if needed unloaded) by a gadget.

I have no idea how or what happens when an ai crashes, for certain it should not affect the game, perhaps it could also be possible to catch errors and maybe even save and restore ai states somehow.

Another idea i had but never got around to do was to have a gadget that just kills teams that control an unsupported ai, but whats your excuse for not coming up with this. :regret:

Re: AI whitelists, a trivial solution

Posted: 01 May 2017, 19:10
by AF
The problem with wrapping native AIs in Lua is that it's not something that's easy to do, lua is a scripted language running in a VM, all manner of chaos could happen just trying to build that.

Killing AI players who do nothing before a set time is also another option

Re: AI whitelists, a trivial solution

Posted: 03 May 2017, 08:30
by Anarchid
I think that loading a LuaAI instead of a malfing native AI will be misleading, will cause bugs to be reported to the native AI repository which are actually the LuaAI bugs, will cause performance misattribution ('this ai plays well' while really it just resigns) etc.

Killing off any AI which does not explicitly support the game (or empirically issues no orders within 20s) sounds like the best approach.

Best of all, this does not have to be an engine thing. A game's LuaRule can check if the AI starting unit has had any orders issued to it during the grace period, and if not, then kill it.