2018-08-21 05:11 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002923Spring engineGeneralpublic2017-04-26 14:06
Reporteruser744 
Assigned Toabma 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionsuspended 
Product Version 
Target VersionFixed in Version 
Summary0002923: ValidAIs.lua so lobbies can only show compatible AIs
DescriptionAs discussed in this thread:
http://springrts.com/phpbb/viewtopic.php?f=21&t=19627
I would be nice to have some way for games to pass a list of compatible AIs to the lobbies, so the lobbies can adjust their "add bot" menu accordingly.
TagsNo tags attached.
Attached Files

-Relationships
related to 0003215resolvedabma Broken Shard included in Installer 
child of 0004360resolvedabma better singleplayer experience 
+Relationships

-Notes

~0009071

abma (administrator)

Last edited: 2012-07-20 22:16

View 3 revisions

hmm, my suggestion (changes in unitsync, that should reflect to the startscreen, too?!):

lua ais are always valid

when GetSkirmishAIInfoCount is called after addallarchives / addarchive (?) it lists only ai's in (if exists) validais.lua else all ai's

removeallarchives cleans this up.

~0009072

abma (administrator)

possible syntax for entries in a table:

"*RAI*"
"RAI 0*"
"RAI 0.601"

return [
"RAI *",
"KAIK *",
]

i would use full strings to keep it easy...?!

~0009073

user744

superpro would be if the file has a function that gets called with AI name.
Then you could make have whatever complex conditions you want, to only allow certain versions or AIs that include the modname or whatnot.

function AllowThisAI (name)
if (name=="RAI") then return true end
if (name=="KAIK") then return false end
if (some complex string operation) then return true
return false
end

~0009081

AF (reporter)

An option in settings to ignore validAIs.lua for testing/dev purposes would be useful.

Most of the arguing in the past has been over who can be trusted to maintain better, the AI devs or the game devs, and thus whose compatability list should take priority.

So, I've a solution!

I'd like to be able to set a validGames.lua in Shard which acts as the base default, which is then overridden by validAIs.lua. This way I can say I support BA without needing BA involvement, but, if say Beherith deems it unworthy, he can just modify validAIs to say Shard is incompatible.

That way I can add games as I support them, or indicate generic but playable support, but the game developer still has the final say.

+1 to knorkes suggestion but not 100% necessary

~0012994

abma (administrator)

Last edited: 2014-04-09 02:10

View 4 revisions

*bump*

af's suggestion sounds good, but is imo to complicated to implement.


imo for the start it would be good if spring honors validAIs.lua in the start menu. lobbies have to implement it theirself, as its difficult to respect this file through unitsync.

(also idk if jk has something wip related to the menu)

~0013012

zwzsg (reporter)

For the syntax and behavior, I suggest: Same as http://springrts.com/wiki/Validmaps.lua

Consistency is always good!

~0016733

user744

This can probally be closed because with the death of the multiple-games-spring-idea it is not relevant anymore.
One-game-installers do not need a validAIs.lua to limit their bots selection.

> lobbies have to implement it theirself

This has now basically happend.

~0016735

AF (reporter)

+1

~0016740

abma (administrator)

> This has now basically happend.

where? i don't see a validAIs.lua in BA nor the ZK repository.

~0016741

user744

Last edited: 2016-10-04 15:58

View 3 revisions

Games that want to be seperated from spring and distribute themselfs via other means do not need a validAIs.lua in their game repository. Those games never needed that.
Instead they just make the add-Bot menu in their lobby only show the AIs they need.
They already found a solution without validAIs.lua so the validAIs.lua is not nessecary anymore.

example:
https://github.com/ZeroK-RTS/Chobby/blob/master/LuaMenu/configs/gameConfig/zk/aiBlacklist.lua is a file in the lobby, not in the game.

similiar (i think):
https://github.com/springweblobby/swl-website/blob/749f43675bc487336a975d8f1434a1fcb715e8b8/lwidgets/GameBots.js#L179

The multiple others installers/lobbies those games use or had used also did not show the default-spring-AIs.
Or they simply do not include the unwanted AIs in their download.

For such games with their one-game-installers validAIs.lua was never relevant:
"They implemented it theirself."

validAIs.lua was only relevant for the old spring-system that wanted to allow to players to play several games.

~0016782

Forboding Angel (reporter)

I very much want this feature. At the moment I am relegated to stripping out the engine AIs from steam and portable builds. It's a bit of a pain, and it would be nice to have the ability to control it from the game itself.

~0016818

raaar (reporter)

Being able to whitelist AI for a game is a very nice feature.

What the lobbies should do is, when adding AIs for a game, show them separated into two categories : game-approved/recommended AIs and other AIs (with a warning that they may not work properly).

~0016822

Forboding Angel (reporter)

No, that is a terrible idea from an end user standpoint. Evo currently gets the most rts newbies of any game in spring. Most of them don't understand rts, have never played one, and when they do, a lot of them don't like the amount of effort it takes to play rts games. Those people I can't retain, however, the ones that like RTS stick around (spend some time in evo's discord channel for an example).

Anyway, my point is this... I have the unique first hand experience of dealing with rts newbies constantly. Some of the biggest complaints I've had are that RAI crashes or KAIK doesn't work or why does nullai do nothing? This is why I have stripped them out.

Compiled ais at this point are hobbies. There is no distribution system (seriously, if they were rapid-able the game could just depend upon them), and they make for an exceptionally poor user experience. It doesn't matter if you add text to the lobby stating that an AI doesn't work. Players _do not_ read.

ValidAIs.lua allows those compiled AI to still be bundled with the engine while not adversely effecting the games. This is a win for everyone.

~0016823

raaar (reporter)

Given the separation and the warning, which could be a simple sentence like

"AIs not officially supported by the game developers may not work properly"

the % of confused users should be very low.


lobbies could have an option to hide those other AIs (enabled by default)

This seems more a lobby issue than an engine issue.
(https://github.com/springlobby/springlobby/issues/755)

~0016824

Forboding Angel (reporter)

"the % of confused users should be very low."

When in actuality the % of confused newbies will be very high. Unless it is in game, players do not read, and even then, they still usually don't read.

The engine will have to standardize it in order for the lobbies to comply. It's stupid, but that's just the way it is.

~0017464

ThinkSome (reporter)

Bump.

Not only confused, Spring just crashes loading Spring:1944 with some of the included AIs.

The answer to this cannot be custom lobbies as making a custom lobby and installer is a waste of time that could be better spent on game content.

~0017465

AF (reporter)

ThinkSome, AIs shouldn't crash, the worst case scenario should be that the initial starting units do nothing. Please report those separately with infolog

Additionally, the comment regarding custom lobbies etc isn't relevant, as it assumes everyone can do everything. Those working on game content usually don't have the skill or interest to build lobbies and vice versa. That's why people volunteer and work on specific things, there are very few jack of all trades

~0017468

ThinkSome (reporter)

Then what other way is there to exclude problematic AIs other than customising a lobby client?

~0017469

AF (reporter)

I'm not sure you understood what I said.

It's something that would need to be done by people with the ability to customize lobbies, and most content authors do not have that ability. Those who do usually don't have the ability to work on game content.

Alternatively the engine could present different sets of AIs to the lobbies via unitsync, so the engine devs could build this logic without lobby involvement

~0017470

ThinkSome (reporter)

I'm would be in favor of that second approach, exposing a list and lobbies having a default-on switch "enforce game approved AI list"

~0017473

ThinkSome (reporter)

AAI crash on load (another reason in favor of validais.lua): https://springrts.com/mantis/view.php?id=5530

While we are at it, could a list of valid engines also be implemented?
Perhaps post-release updating might be wanted and it would be best to distribute this as a separate archive.

~0017476

AF (reporter)

- New ticket for new feature
 - AAI should never crash, see linked ticket for response
 - I think the main problem with validais.lua is that nobody is available to implement it. I'm not sure what would be involved implementing it myself

There are only a minimal number of native AIs built for the engine versions released in the last few years, the approach of asking the AI what it supports is the path of least resistance, they're distributed with the engine and spread across a handful of known repos.

The alternative is updating every game in existence, an unlikely feat. Older games wouldn't support AIs as their whitelists would be empty, newer games may be overzealous and refuse to update their lists when an AI adds support or fixes the bug preventing compatibility. When they do get updated, the older version will still blacklist the AI.

What's more there's little incentive for people to use the newer version of the game if the only thing that changed is a whitelist, and game creators are less likely to go through the release process as a result.

So my suggested plan of action:

 - Add a callback that asks an AI if it supports a game, that returns a true or a false, false by default
 - Make sure the existing AIs fail gracefully rather than doing a hard-crash
 - Make sure the lobbies don't cache the list of AIs and ask afresh every time they switch games

Again, the reason this hasn't been done isn't because people need persuading or lobbying, it's because nobody has stepped up to do it, and the pool of people who know how are very limited. It's not a 5 minute fix

~0017477

raaar (reporter)

This is a serious issue. People new into this often pick the wrong AI and get one which does nothing or worse, crashes.

The list of AIs which work for each game should be something defined by the game package, though.

I think games are the most consistently updated package.

~0017486

ThinkSome (reporter)

Yes raaar, and game devs should have the final say on what AIs they would support. It is even worse as AAI is the first AI in the list.

> newer games may be overzealous and refuse to update their lists when an AI adds support or fixes the bug preventing compatibility.

Try to ask game devs what they feel about your AI before you do a ton of work for nothing. Though I don't think it would be a problem in practice.

> What's more there's little incentive for people to use the newer version of the game if the only thing that changed is a whitelist, and game creators are less likely to go through the release process as a result.

With total lack of lobby moderation the former scenario is likely. Or yet another game moving to their own self-hosted lobby. As for the later: if you cooperate with the game devs, this should not be a problem (unless your AI sucks so much not to warrant a release).

~0017487

AF (reporter)

> Yes raaar, and game devs should have the final say on what AIs they would support. It is even worse as AAI is the first AI in the list.

AAI knows which games it supports already, why not ask it and only present it as an option when it says yes?

> Try to ask game devs what they feel about your AI before you do a ton of work for nothing. Though I don't think it would be a problem in practice.

I've done that in the past, repeatedly. As an AI developer I can confirm that is has been a problem in the past. Game developers don't always care about AI, they have other priorities.

Keep in mind too that when NTai first appeared, it barely supported 1 game. 2 weeks later it supported all games. That would not have been possible with a game based whitelist.

In those times i've tried to involve game developers, I've either met one of these scenarios:

 - Outright hostility, AA and BA were prime examples of this. As far as they were concerned my AI was supposed to support their game, why would they do any work. There were brief moments when NTai required a tag in the main archive, which was added in BA, otherwise any interest was from the playerbase, not the content devs
 - Indifference, some said they didn't care as they had multiplayer communities. Some didn't find AI interesting and just wanted to play with their friends, why would they add AI? Then there's the Smoth argument of "I got tonnes to do, come back in a year or two when it's all done", or the Starwars argument of "We're not giving you access"
 - Involvement, some game content developers took an active interest, Notably Forboding Angel. Azaremoth also expressed some interest

Of note, those AIs that content devs have expressed interest in our configurable, or have defined options. These AIs already know which games they support and which they don't. If any of them are mistaken, they're bundled with Spring and can be ammended trivially without re-releasing every game out there

~0017489

Anarchid (reporter)

> There are only a minimal number of native AIs built for the engine versions released in the last few years, the approach of asking the AI what it supports is the path of least resistance, they're distributed with the engine and spread across a handful of known repos.

This is not accurate. However, none of the new AI's are bundled with spring. Because bundling AI's with spring has been a horrible idea anyway.

That aside, i think asking the AI which games it supports rather than the game having the final say is the better solution here. Whitelisting means any developer trying to even start working on their AI for a specific game already will have to either ask permission, or run on a branch of said game with hacked ValidAIs.

AAI crashed last 10 times i ran it.

~0017491

Forboding Angel (reporter)

> The alternative is updating every game in existence, an unlikely feat. Older games wouldn't support AIs as their whitelists would be empty, newer games may be overzealous and refuse to update their lists when an AI adds support or fixes the bug preventing compatibility. When they do get updated, the older version will still blacklist the AI.

Older games use an old version of spring, therefore, no issue.

> What's more there's little incentive for people to use the newer version of the game if the only thing that changed is a whitelist, and game creators are less likely to go through the release process as a result.

What release process? git commit -am "VERSION${v10.72}"

That is the release process, come on...

> I think games are the most consistently updated package.

Definitely.

> Try to ask game devs what they feel about your AI before you do a ton of work for nothing. Though I don't think it would be a problem in practice.

If you're capable of building an AI, you are capable of checking out a git repo and editing the validAI files. Moreover, if your AI is decent, then the gamedev can be easily shown. This would absolutely not be an issue.

> Keep in mind too that when NTai first appeared, it barely supported 1 game. 2 weeks later it supported all games. That would not have been possible with a game based whitelist.

You use the word "Supported" very loosely. Supported does not mean "Does not crash instantly", supported means "can actually play this game somewhat competently". Moreover, this is incorrect. You are very good at cloning repos, and I surmise that you would also be good and editing validAI. You can't just theoretically make the AI not crash and then call the game "supported". So in your scenario, you would have had to test each game. Editing 1 line in a file for each game is not even a low barrier to entry.

> However, none of the new AI's are bundled with spring. Because bundling AI's with spring has been a horrible idea anyway.

Amen.

~0017494

Anarchid (reporter)

> If you're capable of building an AI, you are capable of checking out a git repo and editing the validAI files. Moreover, if your AI is decent, then the gamedev can be easily shown. This would absolutely not be an issue.

And then you're stuck instructing your would-be early adopters to git clone, or ask the dev permission (plus wait for their release cycle to complete!) for your first online 1v1.

There is simply no need for this level of obstruction.

~0017497

AF (reporter)

> If you're capable of building an AI, you are capable of checking out a git repo
> and editing the validAI files. Moreover, if your AI is decent, then the gamedev
> can be easily shown. This would absolutely not be an issue.

You may disagree on what a competent AI is, especially if the goals of the AI don't match what you believe an AI should do. For example, BA might want a competent AI, but the AIs goal might be to train people brand new to RTS, a tutorial AI that was never intended to win, or a research AI. Games could eliminate an AI that plays but isn't difficult enough.

Content devs would also need to bear the burden of testing these AIs to make sure they work with their game. Something they've not shown a huge amount of interest in. Content devs usually sacrifice AI support in favour of gameplay decisions then hope for AI to change after the fact, coordination is rare.

Also keep in mind that most games that have been written on this engine never had an AI, never pursued it, and never tried to gain support. For the longest time the only reason games had an AI was because people like myself built them and make concerted efforts to expand support, or build flexible systems to automatically support games.

> Keep in mind too that when NTai first appeared, it barely supported 1 game. 2 weeks later it supported all games. That would not have been possible with a game based whitelist.

NTai at many points had 100% support for all games, it wasn't until LuaRules started getting more advanced that this changed. With ValidAIs I'd need to either fork a game or ask the author for permission before building an AI.

The bar for building native AIs is already stupendously high.

As for the question of support, AAI knows which games it supports because those games have an AAI config. The lack of that config triggers a deliberate crash so that AAI won't run on a game it doesn't support. It's basically a crude ValidAI.lua implementation, the best that could be done at the time.

And no, an AI that does not crash is not an AI that supports a game. No AI should crash fullstop, crashing is not a sign that an AI does not support a game, it's a sign the AI is broken.

So lets list the native AIs everybodys bickering about:


 - AAI - knows which games it supports because there's a config file saying so
 - Shard - has the means to do so, if there's no subfolder for the game then there's no support
 - RAI - only supports OTA style games, would probably be enough to test if armcom or corcom units exist, suggestions welcome
 - E323AI - same as AAI, it even copied the config parser and the crash if not found trick
 - Hugh AI - same as RAI
 - CpptestAI, null, nullai, nulljavaai - support no games, they do nothing by definition

As such, adding a callback would be significantly easier, and would only need to be done once, rather than all the problems, diplomacy, people wrangling, disagreements, and problems that come from ValidAIs.lua

If at the end of all this it doesn't work, a game based AI whitelist is still an option, but we'd still be in a better place

~0017498

AF (reporter)

As a sidenote, Unitsyncs API provides mechanisms for fetching keys from AIInfo.lua, it may already be possible for a lobby to fetch a 'validgames` list from an AI this way with which to filter with

~0017500

ThinkSome (reporter)

AF does your AI support Spring:1944 and how far does it go on the scale from AAI(crash) to a human player?

I think that NullAI is good to have, but it should be renamed to DoNothingAI or something to make it clearer about what it does.

~0017501

ThinkSome (reporter)

> And then you're stuck instructing your would-be early adopters to git clone, or ask the dev permission (plus wait for their release cycle to complete!) for your first online 1v1.

This is one of the reasons for splitting the support mapping into a separate archive.

~0017502

raaar (reporter)

So...

AI makers want the AI files to decide which games are compatible

Game makers want the game to decide which AIs are compatible

however it's done, maybe it's best to have soft whitelists by default, meaning that the lobby would show the AIs separated in two categories instead of hiding the non-whitelisted AIs for each game

~0017503

AF (reporter)

I'd note it's a non-issue for most new AIs as they're LuaAIs, really this is all about the 6 native AIs that are mature and rarely change


> I think that NullAI is good to have, but it should be renamed to DoNothingAI or something to make it clearer about what it does.

I agree, That should be doable by modifying its AIInfo.lua, a simple change

> AF does your AI support Spring:1944 and how far does it go on the scale from AAI(crash) to a human player?

Shard has no support for Spring:1944 at the moment, and should do nothing. it has a subfolder that was created for various reasons a long time ago, which didn't change anything. But I now plan to delete it as it just has an empty task queue list and attacker list.

I'm fond of the idea of surrendering rather than doing nothing and intend to make Shard say as much then self destruct all units if no subfolder is found indicating support, I'm not sure when I'll get around to implementing that.

As for crashing, Shard should never crash the engine, and if it ever does, I'd like any and all information posted as a GitHub issue. i'm aware of 1 crash bug that was reported on the forums, which implied several things I couldn't confirm. Recent changes to Shard should either fix or reveal that problem, but I consider it an edge case. I'm a strong believer that AIs should fail gracefully. If I had a large chunk of available time I'd probably have Shard report its own bugs, but I haven't figured out how to do that yet for the mingw32 builds in the way I did for Visual Studio builds


As a sidenote, Abma changed AAIs behaviour so it doesn't deliberatley crash. Errors AI will need updating too as it has the same check

~0017504

AF (reporter)

S44 removed from Shard in:
https://github.com/tomjn/Shard/commit/c0e573672bc3b7a92840ac0fb8e681e5dc38b271

Other game folders checked and remain. I would also note that the result of a validais.lua is:

 - Somebody writes an empty list, and somebody else writes a list of the native AIs for BA
 - Everybody copies the list
 - Half the community then adds their LuaAI they forgot to add after releasing an update
 - The file never changes again

People like Forb will list only a single AI that comes bundled with the game anyway, and that will be the end of it

Alternatively, we could just list the TA style games in an array and return true if the game matches inside the AI. The results are the same but it's easier to build.

The idea that content devs need this and will actively use this control is silly as it only refers to 6 projects that are in mothball status that are in bugfix code freeze mode. AAI is never going to add or drop support for a game. it's already set in stone, we might as well use a chisel instead of carrying around copies of lists.

Most content devs will never even know what validais.lua contains, just that they were told to copy paste. From then on every game ever released will need to contain a copy of this file, adding another pointless step.

The AI based alternative is probably only going to be used in a single pull request by an AI dev who sets the initial list of games.

~0017505

AF (reporter)

Also note that a recommended list with 2 sections would require UI changes in the lobbies, this feature request is already a lot of work with minimal gain, and that'd require cooperation across multiple lobby projects and unitsync changes, making it a non-starter

~0017506

ThinkSome (reporter)

AF how much effort would it be to support Spring:1944? I.e. for the AI to capture flags, group units (infantry with armor), handle ammunition and stuff? I suppose this would be far from easy...

Ok, from what I see Shard seems to be a glorified list of orders. Is there any AI that would be told about the game economy (metal,energy,...) and then it would learn (with help), in which ways to reach equilibrium and a larger economy?

~0017507

Anarchid (reporter)

> AI makers want the AI files to decide which games are compatible
Did you just assume my role? :P

> however it's done, maybe it's best to have soft whitelists by default, meaning that the lobby would show the AIs separated in two categories instead of hiding the non-whitelisted AIs for each game
This sounds like a good option for the "game whitelists ai" scenario. It's not really necessary for the "ai lists supported games" scenario.

> how much effort would it be to support Spring:1944? I.e. for the AI to capture flags, group units (infantry with armor), handle ammunition and stuff? I suppose this would be far from easy...

This would not be easier in Shard than it would be in other native AI interfaces, but if you have game dev support it's not that complicated either. AI<-->LuaRules interactions have become *much* better than they were, and there are examples for most imaginable use cases (in ZK).

> Is there any AI that would be told about the game economy (metal,energy,...) and then it would learn (with help), in which ways to reach equilibrium and a larger economy?

No.

> Also note that a recommended list with 2 sections would require UI changes in the lobbies, this feature request is already a lot of work with minimal gain, and that'd require cooperation across multiple lobby projects and unitsync changes, making it a non-starter

Any kind of lobby support for the proposed filter has this problem.

~0017508

AF (reporter)

> This would not be easier in Shard than it would be in other native AI interfaces, but if you have game dev support it's not that complicated either. AI<-->LuaRules interactions have become *much* better than they were, and there are examples for most imaginable use cases (in ZK).

Of the native AIs Shard would be the easiest to make support, and it would be possible with the sent to content API, but it would be a better/easier investment to use Shard as a LuaAI in that event.

As for what would be involved, I have no idea, it's been a long time since I loaded up S44, I couldn't possibly comment

> Is there any AI that would be told about the game economy (metal,energy,...) and then it would learn (with help), in which ways to reach equilibrium and a larger economy?

Actually, KAIK focused on this and pathfinding as its primary advantage, it was afterall a degree thesis split between 3 people. Those algorithms could be adapted, the problem is that KAIK was written before the advent of lua rules, and has little configurability. The idea was that the AI didn't have to be configured, it'd figure it out itself. That falls apart when the game rules aren't codified and machine readable.

> Did you just assume my role? :P

Aren't you the florist who makes peewee models out of daffodils?

> Any kind of lobby support for the proposed filter has this problem.

Would this require autohost intervention too?

~0017509

Forboding Angel (reporter)

> People like Forb will list only a single AI that comes bundled with the game anyway, and that will be the end of it

That is absolutely right, because I have had NO END of troubles caused by native AIs being selectable in the lobby.

What you want is a solution that favors the tiny minority of AI developers, what I want is a solution that favors the players who actually play the games. At the end of the day, it is your AI, but it is _my_ game. You don't deal with the fallout from your AI, I do. For that reason, AI selection should be done by the game, and the game alone. If you want to test your AI, then fork the repo, change valid AIs, and have your testers clone the repo which is capable of being used online.

~0017510

Forboding Angel (reporter)

Additional note... Thankfully I have control over distribution and while I find it very irritating to have to do this, I WILL strip out native AI from the engine if I am forced to.

I have even had troubles with NullAI which is the most stupid name possible for a sandbox.

You, as the AI dev, should pick one game and make your AI work superbly with it. After you have done that, you can go to another game.

Start with ZK. It already has a LuaAI that works very well, but it has the most players. BA is another good candidate. Evo players would love a good AI (as would I) that plays the game well and actually understands the mechanics.

The problem that I see with AI devs is that devs such as yourself want a shotgun approach at an AI that somewhat plays every game, but plays none well. The shotgun approach is used to see what sticks.

Shard is little more than a spawner with queues when it comes right down to it. Sure, you can add functionality. The one in Evo goes and captures points. But at it's basis, it's still just a slightly smarter unit spawner.

~0017511

Forboding Angel (reporter)

And just to clarify, by unit spawner, I'm, not talking about the basis that it builds units and sends them out to die. I am referencing the fact that shard builds units in varied size groups depending on success of past attacks, but when those units are set to fight, they are literally given a fight order from one side of the map to the other. After that, there is little to no interaction with them again from the AI.

In fact, when they reach their end destination, shard commonly is completely unaware of their existence at that point.

~0017515

Anarchid (reporter)

> Aren't you the florist who makes peewee models out of daffodils?

I contain multitudes!

> That falls apart when the game rules aren't codified and machine readable.

It is now theoretically possible to fix this by having the AI machine-learn the meanings behind the various AI-visible Lua things, like RulesParams. What would be lacking is the ability to discover discover the list and syntax of commands that can be sent with CallRules, but with even a small bit of game developer collusion you could have a CallRules that returns you the list of valid CallRules.

> Would this require autohost intervention too?
I don't think the autohost really has any information about which specific native client AI lib does what.

So i think autohost enforcement is not only the worst possible approach, but an impossible one as well. That said, game devs with sufficient gamedevine power can already inflict whitelists by either shipping customized lobbies which omit unnecessary AI entries; or even shipping customized Spring distributives with an engine repackaged without the offending AIs.

~0017516

Anarchid (reporter)

> Start with ZK. It already has a LuaAI that works very well,

As well as three high-tier native AI's which you can measure against. One of which is shipped in the standard distro.

~0017517

AF (reporter)

I would note that Forboding has provided a classic example of hostile game developer.

For reference, here is Shard kicking Forbs ass at Evolution RTS on youtube https://www.youtube.com/watch?v=o5WB4PJE-14

Lets remember that the native AIs native parts are in stasis and have been for years, they're not active projects aside from Shard ( which itself moves at a slow pace ).

Seriously, the only people who touch AIs like AAI or NullAI are Abma or Kloot when somebody reports a bug, the last new features were added many many years ago.

Who exactly is going to start indicating support for EvoRTS in these AIs? You realise if they did they'd have to get it into the main spring repo in a Pull request? At the moment no AIs claim they support your game, even Shard support was removed ( mostly because you were hostile rather than cooperative so I offloaded it, no longer my problem )

It all boils down to you not trusting AI devs to manage this properly, but i am literally the only native AI dev left! And you know by now I wouldn't do this ( unless you were super hostile and I did it to spite you, your track record of simply asking nicely is... poor, it always escalates to outrage quickly with no room for compromise ). I've no interest in messing around with EvoRTS, if you want Shard working with it, go make a LuaAI version of it.

So again:

 - Shard knows which games it supports ( ZK, CA, CT, Kernel Panic, BA, The Cursed )
 - AAI knows which games it supports because game devs put a config file in their game, so you already have control over this
 - Errors AI is the same as AAI and reads the same configs

I for one would like to be able to say that my AI does not support EvoRTS, but I am tempted to add the cheat interface to Shard and have it spawn random units all over the players base in EvoRTS. Perhaps a minigame where Shard claims it's hacked all your units CPUs to trigger a self destruct, and you have to ctrl+a and cancel the command. I'm sure it'll get built faster than either proposed solution here, and it'll be difficult to fend off. How's that for a basic unit spawner?

~0017520

Anarchid (reporter)

> Lets remember that the native AIs native parts are in stasis and have been for years, they're not active projects aside from Shard ( which itself moves at a slow pace ).

This is incorrect. Since this is incorrect *again*, i guess i'll have to drop some links.

https://github.com/Anarchid/zkgbai
https://github.com/rlcevg/CircuitAI
https://github.com/DeinFreund/CSI
http://zero-k.info/Users/LobbyDetail/rust
https://github.com/spring/spring/commits/develop/AI/Interfaces

The interface has improved. There are active projects. There's a scene.

~0017521

abma (administrator)

please continue discussion in the forum, the bugtracker is really the wrong place for this:

https://springrts.com/phpbb/viewtopic.php?f=21&t=19627

thanks
+Notes

-Issue History
Date Modified Username Field Change
2012-01-18 15:15 user744 New Issue
2012-07-20 22:03 abma Note Added: 0009071
2012-07-20 22:08 abma Note Added: 0009072
2012-07-20 22:16 abma Relationship added related to 0003215
2012-07-20 22:16 abma Note Edited: 0009071 View Revisions
2012-07-20 22:16 abma Note Edited: 0009071 View Revisions
2012-07-20 23:37 user744 Note Added: 0009073
2012-07-24 12:08 AF Note Added: 0009081
2014-04-09 02:01 abma Priority normal => urgent
2014-04-09 02:05 abma Note Added: 0012994
2014-04-09 02:05 abma Note Edited: 0012994 View Revisions
2014-04-09 02:08 abma Note Edited: 0012994 View Revisions
2014-04-09 02:10 abma Note Edited: 0012994 View Revisions
2014-04-09 02:13 abma Relationship added child of 0004360
2014-04-13 18:28 zwzsg Note Added: 0013012
2015-08-19 20:34 abma Description Updated View Revisions
2016-10-03 11:48 user744 Note Added: 0016733
2016-10-03 18:51 AF Note Added: 0016735
2016-10-04 15:28 abma Note Added: 0016740
2016-10-04 15:48 user744 Note Added: 0016741
2016-10-04 15:53 user744 Note Edited: 0016741 View Revisions
2016-10-04 15:58 abma Note Edited: 0016741 View Revisions
2016-10-11 05:28 Forboding Angel Note Added: 0016782
2016-10-22 04:35 raaar Note Added: 0016818
2016-10-23 00:50 Forboding Angel Note Added: 0016822
2016-10-25 06:17 raaar Note Added: 0016823
2016-10-25 06:54 Forboding Angel Note Added: 0016824
2017-04-18 01:01 ThinkSome Note Added: 0017464
2017-04-18 03:12 AF Note Added: 0017465
2017-04-18 18:05 ThinkSome Note Added: 0017468
2017-04-18 18:11 AF Note Added: 0017469
2017-04-18 19:19 ThinkSome Note Added: 0017470
2017-04-22 01:46 ThinkSome Note Added: 0017473
2017-04-22 12:46 AF Note Added: 0017476
2017-04-22 16:28 raaar Note Added: 0017477
2017-04-23 16:02 ThinkSome Note Added: 0017486
2017-04-23 19:59 AF Note Added: 0017487
2017-04-25 12:41 Anarchid Note Added: 0017489
2017-04-25 13:35 Forboding Angel Note Added: 0017491
2017-04-25 14:40 Anarchid Note Added: 0017494
2017-04-25 15:37 AF Note Added: 0017497
2017-04-25 15:45 AF Note Added: 0017498
2017-04-25 18:07 ThinkSome Note Added: 0017500
2017-04-25 18:09 ThinkSome Note Added: 0017501
2017-04-25 18:09 raaar Note Added: 0017502
2017-04-25 18:20 AF Note Added: 0017503
2017-04-25 18:30 AF Note Added: 0017504
2017-04-25 18:31 AF Note Added: 0017505
2017-04-25 21:29 ThinkSome Note Added: 0017506
2017-04-25 22:03 Anarchid Note Added: 0017507
2017-04-25 23:55 AF Note Added: 0017508
2017-04-25 23:56 Forboding Angel Note Added: 0017509
2017-04-26 00:09 Forboding Angel Note Added: 0017510
2017-04-26 00:12 Forboding Angel Note Added: 0017511
2017-04-26 02:16 abma Priority urgent => normal
2017-04-26 12:38 Anarchid Note Added: 0017515
2017-04-26 12:41 Anarchid Note Added: 0017516
2017-04-26 13:17 AF Note Added: 0017517
2017-04-26 13:57 Anarchid Note Added: 0017520
2017-04-26 14:01 abma Assigned To => abma
2017-04-26 14:01 abma Status new => closed
2017-04-26 14:01 abma Resolution open => suspended
2017-04-26 14:01 abma Note Added: 0017521
2017-04-26 14:06 abma Summary ValidAIs.lua so games can whitelist AIs => ValidAIs.lua so lobbies can only show compatible AIs
+Issue History