Spring RTS Engine

I am getting vague info in my research but it seems that spring makes it slightly more difficult to distribute (nonlua) AIs than it does for other content.

But this should not be solved by: include all AIs ever made in the engine, and then block them.

Would it not sound silly if I said include all widgets ever made in the engine and then block them? Games? Maps?

I repeat: the inclusion of these AIs has caused hundreds of players confusion and lost some players forever. It's bad for all of us.

Silentwings wrote:Some people do still play; I think KAI is the most popular one.

Would you like it if someone made a awesome AI called AAAAAI and stuck it in the engine. But it only works with EvolutionRTS because that's what it was designed for. Then what if 50 new potential players found BA, wanted some single player, tried it with AAAAAI (because it's first) and said your game is totally broken and left, never to return. But hey, I want to distribute AAAAAI so I think it should be in the engine.

[repeat above steps with A{n}I as desired]

How long should the list be of included AIs in the engine? How do they deem which ones are fit to be included? There is not a single AI that plays with all games, so why should any be included?

Would you like it if someone made a awesome AI called AAAAAI and stuck it in the engine. But... said your game is totally broken and left, never to return

No, if you'd bothered to read what I wrote you'd have come across

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

One can think about the topic what one wants, but having a linear name algo O(n) for the AAis is pretty cool.

But yeah, AIdevs have to add a "workswith" list to there AIs and stand to that.

I know about the whitelist, I specifically addressed it when I said:

CarRepairer wrote:But this should not be solved by: include all AIs ever made in the engine, and then block them.

Okay it sounds like I'm referring to a blacklist, so pretend I said:

CarRepairer wrote:But this should not be solved by: include all AIs ever made in the engine, and then block them all and then unblock the ones you want.

I still disagree with the "include all AIs and then whitelist in game" because:

• Inconsistent and unnecessary. Distributing AI should be like with other Spring content - separately from Spring.
• It's extra work and bloat to implement white lists in both games and clients.
• It's extra stuff in the engine that's meaningless for new game developers since the AIs won't even work with their projects.

If distributing AIs is difficult, then that should be addressed. If a user adds anything extra into their Spring install that they did not download from the website of the game they are playing, then it should be considered an implicit agreement that they do it at their own risk. If I download coolapp from coolapp.com and then get a plugin from mycoolplugsin.com and put it in coolapp's directory, that's on me.

ValidAIs.lua is a (ideally temporary) solution that works, without breaking anything for current users/devs - unless there is a sudden flood of so many new AIs that keeping track of them becomes unmanageable, which in current situation seems extremely unlikely.

So it's a perfectly good situation to last until, if ever
(1) Someone fixes the incomprenhensibly complicated layers of engine <-> AI interaction and people start writing new non-lua AIs again.
(2) Said someone invents an AI distribution system and it gets integrated into lobbies/games.
At that point I agree it makes perfect sense to decouple non-lua AIs from engine, but (2) takes time and (1) is nearly impossible.

Silentwings wrote:ValidAIs.lua is a (ideally temporary) solution that works, without breaking anything for current users/devs - unless there is a sudden flood of so many new AIs that keeping track of them becomes unmanageable, which in current situation seems extremely unlikely.

So it's a perfectly good situation to last until, if ever
(1) Someone fixes the incomprenhensibly complicated layers of engine <-> AI interaction and people start writing new non-lua AIs again.
(2) Said someone invents an AI distribution system and it gets integrated into lobbies/games.
At that point I agree it makes perfect sense to decouple non-lua AIs from engine, but (2) takes time and (1) is nearly impossible.

+9001

ValidAIs.lua is the sensible half-step that has been suggested since time immemorial and ergo is way overdue. The perfect solution? Perhaps not but a workable one that will solve the critical issue of broken AI's driving away new players.

Whitelisting is required in addition to electing to obtain an AI like any other Spring content. Otherwise the problem remains.

zwzsg wrote:What are you talking about? I

This:

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

Distributing the AI is what's hard, because you would need to figure out a way to compile it for different architectures.

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

Yes, but you still need to figure out how to distribute non Lua AIs that need to be compiled, and you should still allow for other people to create AIs for your game.

PS: In the end, I completely agree with the validais solution.

The mantis is from 2012..I added it here, not sure if that helps:
http://springrts.com/wiki/Project_propo ... lidAIs.lua

zwzsg wrote: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.

Actually that is interessting idea too. But I think in past was some problems when lobbies parsed files themself instead of getting them via unitsyc. It might be a solution but all lobbies adding that seems as unlikely as getting it engine-way.

As I understand the unitsync gives list of AIs to lobby. So if the unitsync obeys this validAIs.lua file then lobbies only gets the valid AIs in the first place. Which means lobby-side no change would be required at all..?

abma, on mantis wrote:lobbies have to implement it theirself, as its difficult to respect this file through unitsync.

I don't know why it's hard to put it in unitsync, but if abma says it....

i tried to put validais.lua support in unitsync, and i remember it was hard, though i also don't know why anymore.

the problem with distributing AIs like other spring content is, that it is not content but binaries. you could definitely forget about spring on debian, and probably many other linuxes, and i don't know about OS X. on windows it would probably not be a problem to put it in, but actually maybe a real problem, as BAD people could/would start doing BAD stuff with it.