Remove AIs

[CarRepairer]

Please remove the packaged AIs from Spring. They serve no purpose and have provided new users nothing but confusion.

[smoth]

[zwzsg]

Five years ago, I was pleading for the milder solution of letting game hide them. But it was argued it was not fair for AI dev to forbids them to debug AI and other non sense. Good luck with your request!

[Anarchid]

Gone are days of earthly fires.
Gone are days of man empires.

Spring is no longer the BA engine, and even *TA games contain proverbial intercourse metric weight units of game-altering gadgets.

The probability that any given AI will work with any given game is below 50%.

Ax them.

[Silentwings]

Don't remove them. Some people do still play; I think KAI is the most popular one. Not to mention that NullAIs are invaluable for testing spawn gadgetry.

Proper solution is here: http://springrts.com/mantis/view.php?id=2923

[gajop]

And how will non-Lua AI devs distribute their AI then?

[Silentwings]

Imo what is really needed here (i.e. in another thread) is some discussion on how writing future AIs is going to be possible.

As far as I can see the "least resistance" path is to gradually let the generic dll AIs die, through lack of maintainers and incomprehensibly complicated engine code (see http://springrts.com/phpbb/viewtopic.ph ... 33#p556230) - then wait for each game to develop its own lua based system.

It looks like anything else is going to require someone with a lot of spare time and energy. Unfortunately that's bad news since functioning C++ AI stuff does generate a share of interest from capable C++ coders & uni students with projects.

[zoggop]

er, mostly i play co-op against bots in BA. removing all native AIs would make this impossible (BA has no Lua AI). also, the hundreds of hours of work on my Shard config for BA would be rendered totally pointless (though i suppose that was always true in a larger sense).

edit: but yeah, the native AI development model is a pain, and many of them are currently useless or nearly so because of lack of maintenance. the only thing that i don't like about Lua AIs is that the game has to be modified to add an AI. unless the AI is cheating, an AI is like a player, no?

[zwzsg]

Proper solution is here: http://springrts.com/mantis/view.php?id=2923

I agree. A ValidAIs.lua inside the mod archive, implemented in the same way as Validmaps.lua, is the way to go.

For AI devs, and advanced users, an option hidden deep in the settings to disregard that and show all AI could be added.

Any lobby (that is able to run Lua and get files from archives) could start implementing ValidAIs.lua support right now, without the need for engine.

And CarRepairer is weblobby dev.

[Silentwings]

the hundreds of hours of work on my Shard config for BA would be rendered totally pointless (though i suppose that was always true in a larger sense).

Not at all, actually I'm kind of embarrased I've never tried it, but I've no idea where to get it + how to! (PM me with details?)

[zwzsg]

the only thing that i don't like about Lua AIs is that the game has to be modified to add an AI.

You can make a small mod that contains your LuaAI and "depends" on the game. And most game maintainer would be too happy to have a working AI to not add it in their releases. Coordinating updates would still be a bit painful until you get rights to the mod repository though.

unless the AI is cheating, an AI is like a player, no?

Unlike external AI, Lua AI are cheating by default, as they are a gadget. Being inside or outside the game doesn't really change that. It's up to the Lua AI writer to not abuse gadget power.

For exemple, I let KP Lua AI have full sight because the advantage isn't very visible. And I use Create/Destroy Unit only to let KP Lua AI easily change factions.

Some games, such as S44, have added an extra layer between gadgets and Lua AI to remove the cheatingness of Lua AIs.

[Funkencool]

Off topic: wouldn't a widget AI be feasable and basically have the same level of interaction as a player (no cheating)?

On topic: I very often use KAIK for testing, it would be a shame to see it go. I would understand if that was the decision, but the validAIs solution sounds much better. On that note, couldn't this also just be applied to the lobby (only allows user to select valid AIs)?

Edit: Had I followed the link earlier I probably would have noticed lobbies were the proposed solution

[Silentwings]

wouldn't a widget AI be feasable and basically have the same level of interaction as a player (no cheating)?

Yes - although how feasible it is depends on your relative love/hate of c++/lua.

validAIs solution sounds much better ... couldn't this also just be applied to the lobby

Yes.

[zwzsg]

Off topic: wouldn't a widget AI be feasable and basically have the same level of interaction as a player (no cheating)?

An AI as a widget isn't an AI, but an autopilot cheat.

Widgets are more about enhancing the user interface. AIs are more about playing the game with the human interface disabled.

I suppose a new, widget-like environment, for Lua AI, could be added in the engine, but it would require works, ever maintenance, cause bugs, add complexity, for no benefits.

If you really need one, as I said earlier, some games have implemented it game-side.

I would say that Lua AI being gadget, and cheating, is actually good:

The goal of having AI that act exactly as human is unrealistic. Most of the Lua AI implemented so far are spawners (think "chicken"), which are completly cheating, as they spawn units for free at the players door. Yet they provide more enthralling player experience than AIs attempting to emulate humans.

On that note, couldn't this also just be applied to the lobby (only allows user to select valid AIs)?

Yes, as I said earlier, lobbies can prolly start implementing ValidAIs without engine support.

Ideally, ValidAIs should be implemented at the unitsync library level, but if it was implemented by all lobbies (and the hardcoded Spring menu you get when you start Spring.exe with no script), it would look the same to users.

[gajop]

Again, I feel it's totally irrelevant what language the community considers best atm, whether it's C++, Lua or whatever, there is no sense in disabling an existing functionality in favour of no tangible benefit.

Once we have an alternative to the existing setting, I will accept that AIs should be compiled independently of the engine, but until we have that, we would just be axing a pretty important functionality for the AI devs.

When I think about it, this sounds rather similar to the lobby module being removed from Spring without an existing Lua Socket solution being developed... It's a step back.

[zwzsg]

Once we have an alternative to the existing setting, I will accept that AIs should be compiled independently of the engine, but until we have that, we would just be axing a pretty important functionality for the AI devs.

What are you talking about? I thought AI could already be compiled independently of the engine. Just they need recompiling when the interface change. They're compiled and packaged with the engine only as a convenience for players who might need them and engine dev who wants to know bug in compilation or interface asap. But I'm fairly certain that AI devs do not have to wait for new engine release each time they modify one line in their AI source.

The tangible benefit would be: avoid losing all the newbs that quit Spring after failing to run a single player game.

[malric]

there is no sense in disabling an existing functionality in favour of no tangible benefit.

I think the request is about not packaging all the AI-s with all the games, which leads to big confusions when some AI-s do not work with some games.

I think every game should pack it's own (tested) AI that works with that game...

[Google_Frog]

Games should be responsible for packaging the AIs that they want to use.

[SinbadEV]

Are AIs currently packaged with the engine because the AIs need to be re-compiled to match the engine version?

[Silentwings]

Games should be responsible for packaging the AIs that they want to use.

Imo, except in the special case of lua-AIs, that's no solution because the vast majority of games made for Spring never reach/want the stage of packaging themselves independently of Spring (and games that do package themselves can already do this anyway).