You know, you could avoid this by creating an AI that uses video and audio input. [edit] no use for output

I had noted this in offtopic forum four years ago and never responded - viewtopic.php?f=10&t=16087

Of course some had no idea why anyone would do that. Because of complexity and how heavy on performance such an AI would be. Reason for doing so would not only be the topic of this thread, but also compatibility with other games. It also wouldn't be military grade AI, since game engines can have graphics added and removed. As can audio effects.

I'm not wondering that none of you have tried this, since those that have a full time job in relation to Artificial Intelligence would be those that take this up. Just that I think it might be productive for real world applications.

Or an opensource AI that simply exposed a TCP connection to a remote AI that may or may not be closed source

In this thread Senior AI makers discuss the making of AIs while the younglings dont listen, because busy of AI making.

t minuss roll =

split from "Official stance on how the engine's license affects AIs" since I do not understand what it has to do with that. Or with anything

Because he thought that if the AI would parse video & audio it wouldn't have to called from the engine. It'd still need link with the engine since it has to call the engine back, so that wouldn't work.

It's also hard to code and would probably require an extra strong PC just to do the computer vision part, never mind the actual in-game play.

The idea is just silly if your only goal is to subvert the licence requirement - just do what AF said (there's even a C# thread which has shown some progress in that direction).

However, applying CV on a game is interesting and it's something I wanted to do some time back (robot simulation with CV), just never had the time. The neat part about it is that you have easy access to generating free labeled data, so at least getting a lot of good training & test data is easy.

so yeah..
imo too silly to spam up the sticky thread sorry

I see, so the License would have no right to go further than the source of connection.

@PicassoCT
Yes, I have never made an AI before and I doubt about trying it. Especially not on one that relies on video and audio input, and gives orders with mouse and keyboard type actions.

So I was wrong. I indeed thought the problem came from using functions provided by Spring Engine, so using variables that human users get and send orders with would be a way to fix that.

@gajop
Yes it would have been silly to use this just to avoid license issues. But as I said it would have made it more compatible with other RTS games no matter the license.

Takes a great man, to admit wrongness on the interntubes. Greater then me, anyway. But you know what makes for a great AI? No AI.. just beestockbehaviourpattern with every unit... :D

It would require the engine to be relicensed as AGPL, at which point network connections count as linking, and all the lobbies using loopback would be required to be license compatible too

AGPL doesn't work that way; that'd mean visiting an AGPL'ed website would be forbidden with anything except an AGPL'ed browser

As far as I know AGPL is more like: you must provide the source code with any modifications you make that are visible to some users over a network, even if you didn't have to ship a binary to make it (your product) visible to those users.

(for those who never heard of AGPL: its intended for websites, where GPL fails because the user never needs to download a binary, so with GPL you don't need to offer him the source code either.)

I suppose in the case of spring AGPL would make it a license violation to host a spring game using a modified binary, without offering the other players the source code to your modifications. And it would make it a license violation to take Spring, heavily modify it, and then integrate it into one of those streamed-gaming services, without releasing the source code to your modifications. (Currently, with GPL, both are allowed.)

Probably doesn't matter much since a lot of stuff is run in synced.

Indeed.