View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
---|---|---|---|---|---|---|---|---|---|
0002923 | Spring engine | General | public | 2012-01-18 15:15 | 2017-04-26 14:06 | ||||
Reporter | user744 | ||||||||
Assigned To | abma | ||||||||
Priority | normal | Severity | feature | Reproducibility | N/A | ||||
Status | closed | Resolution | suspended | ||||||
Product Version | |||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0002923: ValidAIs.lua so lobbies can only show compatible AIs | ||||||||
Description | As 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. | ||||||||
Tags | No tags attached. | ||||||||
Checked infolog.txt for Errors | |||||||||
Attached Files |
|
Relationships | |||||||||||
|
Notes | |
abma (administrator) 2012-07-20 22:03 Last edited: 2012-07-20 22:16 |
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. |
abma (administrator) 2012-07-20 22:08 |
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...?! |
2012-07-20 23:37 |
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 |
AF (reporter) 2012-07-24 12:08 |
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 |
abma (administrator) 2014-04-09 02:05 Last edited: 2014-04-09 02:10 |
*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) |
zwzsg (reporter) 2014-04-13 18:28 |
For the syntax and behavior, I suggest: Same as http://springrts.com/wiki/Validmaps.lua Consistency is always good! |
2016-10-03 11:48 |
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. |
AF (reporter) 2016-10-03 18:51 |
+1 |
abma (administrator) 2016-10-04 15:28 |
> This has now basically happend. where? i don't see a validAIs.lua in BA nor the ZK repository. |
2016-10-04 15:48 Last edited: 2016-10-04 15:58 |
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. |
Forboding Angel (reporter) 2016-10-11 05:28 |
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. |
raaar (reporter) 2016-10-22 04:35 |
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). |
Forboding Angel (reporter) 2016-10-23 00:50 |
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. |
raaar (reporter) 2016-10-25 06:17 |
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) |
Forboding Angel (reporter) 2016-10-25 06:54 |
"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. |
ThinkSome (reporter) 2017-04-18 01:01 |
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. |
AF (reporter) 2017-04-18 03:12 |
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 |
ThinkSome (reporter) 2017-04-18 18:05 |
Then what other way is there to exclude problematic AIs other than customising a lobby client? |
AF (reporter) 2017-04-18 18:11 |
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 |
ThinkSome (reporter) 2017-04-18 19:19 |
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" |
ThinkSome (reporter) 2017-04-22 01:46 |
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. |
AF (reporter) 2017-04-22 12:46 |
- 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 |
raaar (reporter) 2017-04-22 16:28 |
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. |
ThinkSome (reporter) 2017-04-23 16:02 |
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). |
AF (reporter) 2017-04-23 19:59 |
> 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 |
Anarchid (reporter) 2017-04-25 12:41 |
> 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. |
Forboding Angel (reporter) 2017-04-25 13:35 |
> 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. |
Anarchid (reporter) 2017-04-25 14:40 |
> 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. |
AF (reporter) 2017-04-25 15:37 |
> 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 |
AF (reporter) 2017-04-25 15:45 |
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 |
ThinkSome (reporter) 2017-04-25 18:07 |
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. |
ThinkSome (reporter) 2017-04-25 18:09 |
> 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. |
raaar (reporter) 2017-04-25 18:09 |
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 |
AF (reporter) 2017-04-25 18:20 |
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 |
AF (reporter) 2017-04-25 18:30 |
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. |
AF (reporter) 2017-04-25 18:31 |
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 |
ThinkSome (reporter) 2017-04-25 21:29 |
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? |
Anarchid (reporter) 2017-04-25 22:03 |
> 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. |
AF (reporter) 2017-04-25 23:55 |
> 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? |
Forboding Angel (reporter) 2017-04-25 23:56 |
> 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. |
Forboding Angel (reporter) 2017-04-26 00:08 |
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. |
Forboding Angel (reporter) 2017-04-26 00:12 |
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. |
Anarchid (reporter) 2017-04-26 12:38 |
> 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. |
Anarchid (reporter) 2017-04-26 12:41 |
> 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. |
AF (reporter) 2017-04-26 13:17 |
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? |
Anarchid (reporter) 2017-04-26 13:57 |
> 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. |
abma (administrator) 2017-04-26 14:01 |
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 |
Issue History | |||
Date Modified | Username | Field | Change |
---|---|---|---|
2012-01-18 15:15 |
|
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 |
|
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 |
|
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 |
|
Note Added: 0016741 | |
2016-10-04 15:53 |
|
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 |