- Security is a load of bullsh*t. There's nothing stopping someone from compiling their lua code with a standalone lua executable, and then loading it in via a widget. Just because so far nobody has bothered to do it and put it all in plain text, doesn't mean it cant be done.
It can't do much more than block Spring using an infinite loop or allocate infinite memory or so, whereas a native AI has full access to everything the user has access to, so it can wipe all your files, install trojans, etc.
Updates to the AI require a re-release of the entire game and a version bump
No reason a game would require a full re-release on an update to a Lua AI. The only real disadvantages here are:
- It's impossible to make an AI that, when installed, is only a single file. Not much native AIs have this property either, though (only KAIK?).
- It has a worse user experience when the AI is separate (Need to pick the AI mutator for the game to be able to add the AI...)
Bundling with an archive is anticompetitive
A half decent content developer packages his mod up in an installer, thus negating the advantage of bundling AIs in the archive
So both Lua AIs and native AIs are equally anticompetitive for half decent content developers. Additionally, when a native AI is bundled you need full re-release on an update to the native AI too. (except when it is self updating, but I've yet to see that implemented [in a safe and cross-platform way])
A third major advantage of Lua AIs is that they need no compiling and work on all platforms on which Spring works. This doesn't apply to native AIs.
I agree with the other points, although IMO adapting to custom game rules and implementing APIs and stuff other than those which apply to the target game(s) may be a waste of time if the goal is simply to make a reasonable AI in the shortest amount of time possible.