ValidAIs.lua
Moderator: Moderators
Re: ValidAIs.lua
I'm for any plan that prevents an untested AI showing up for a mod. I propose we combine the two proposals:
In all cases below when I say AI, I mean AI + version, ie: KAIK 0.2; when I say mod, I mean mod + version, ie: BA 7.04
* If a mod whitelists AI it appears in menu
* If an AI whitelists a mod it shows up in menu
* All AIs show up all the time when user selects "Allow untested AIs" in SpringSettings
This should make everyone happy, it's the primary responsibility of an AI author to whitelist each mod they test, however modmakers can add AIs too, and users have the final say. This should be done for every AI/mod release (don't use wildcards) because although it means more work it simply isn't true that supporting an AI now means always supporting it.
The only issue I see with this is CA, because their releases are so frequent. However there is no quick fix; either an AI is tested, or it isn't. Nothing guarantees compatibility except testing.
In all cases below when I say AI, I mean AI + version, ie: KAIK 0.2; when I say mod, I mean mod + version, ie: BA 7.04
* If a mod whitelists AI it appears in menu
* If an AI whitelists a mod it shows up in menu
* All AIs show up all the time when user selects "Allow untested AIs" in SpringSettings
This should make everyone happy, it's the primary responsibility of an AI author to whitelist each mod they test, however modmakers can add AIs too, and users have the final say. This should be done for every AI/mod release (don't use wildcards) because although it means more work it simply isn't true that supporting an AI now means always supporting it.
The only issue I see with this is CA, because their releases are so frequent. However there is no quick fix; either an AI is tested, or it isn't. Nothing guarantees compatibility except testing.
Re: ValidAIs.lua
+1. the rest are details.SpliFF wrote:* If a mod whitelists AI it appears in menu
* If an AI whitelists a mod it shows up in menu
Re: ValidAIs.lua
ok.. thanks guys! good info from Pxtl and SpliFF there.
(i consider these two approaches the only valid ones so far)
i try to outline them again here:
Pxtl:
AI has a say through AIInfo.lua (white- and black-listing), but the mod has the last word through ValidAIs.lua: it can use the AIs suggestion directly, modify it in some cases, or totally ignore it, and just use its own white- and black-lists.
SpliFF:
AI and Mod both have the same power. if AI is white-listed in either of them, it is shown.
possible addition to SpliFF:
if black-listed in one and not white-listed in the other, it is not shown. if not listed at all in either of them -> to be decided.
in either proposal, the user has the last word, and can show invalid AIs though settings or a button.
i would rather have this controlled by the lobbies then through spring-settings, because it allows for more dynamic stuff. eg, if it is in the settings, the user would have to reload unitsync or trigger some reload button, because the lobby would not know that something changed.
well...
i guess it is obvious that AI devs would prefer SpliFFs method, and i guess mod devs Pxtls :D
soo.. what to do now?
edit: typo and correction indicated by SpliFF
(i consider these two approaches the only valid ones so far)
i try to outline them again here:
Pxtl:
AI has a say through AIInfo.lua (white- and black-listing), but the mod has the last word through ValidAIs.lua: it can use the AIs suggestion directly, modify it in some cases, or totally ignore it, and just use its own white- and black-lists.
SpliFF:
AI and Mod both have the same power. if AI is white-listed in either of them, it is shown.
possible addition to SpliFF:
if black-listed in one and not white-listed in the other, it is not shown. if not listed at all in either of them -> to be decided.
in either proposal, the user has the last word, and can show invalid AIs though settings or a button.
i would rather have this controlled by the lobbies then through spring-settings, because it allows for more dynamic stuff. eg, if it is in the settings, the user would have to reload unitsync or trigger some reload button, because the lobby would not know that something changed.
well...
i guess it is obvious that AI devs would prefer SpliFFs method, and i guess mod devs Pxtls :D
soo.. what to do now?
edit: typo and correction indicated by SpliFF
Last edited by hoijui on 27 Jan 2010, 12:35, edited 2 times in total.
Re: ValidAIs.lua
I wasn't really proposing a blacklist. My proposal is only a whitelist; blacklisted is everything not whitelisted so it's a fairly simple implementation. The problem with black&white is determining precedence and dealing with conflicts.
My proposal is basically a switch set by AI or Mod saying "This combination is tested and works". It presumes whoever adds that line actually tested it and isn't lying. Black & white doesn't really solve the dishonesty issue, it just makes it more complicated. I'm worried blacklists will be abused for political reasons (I hate this guy so I'm blacklisting his AI/mod).
If a mod or AI finds the other lied then simple solution is to bump your version and report the other author to Spring devs. If it's obvious the author really isn't testing then the devs can take action to exclude that mod/ai from the Spring installer or via some other means (like a hardcoded ban in lobby/server). I really don't think it would ever come to that.
My proposal is basically a switch set by AI or Mod saying "This combination is tested and works". It presumes whoever adds that line actually tested it and isn't lying. Black & white doesn't really solve the dishonesty issue, it just makes it more complicated. I'm worried blacklists will be abused for political reasons (I hate this guy so I'm blacklisting his AI/mod).
If a mod or AI finds the other lied then simple solution is to bump your version and report the other author to Spring devs. If it's obvious the author really isn't testing then the devs can take action to exclude that mod/ai from the Spring installer or via some other means (like a hardcoded ban in lobby/server). I really don't think it would ever come to that.
Re: ValidAIs.lua
Hoiju:
Don't use blacklists. Use only whitelists.
Every unknown (Mod+AI) pair is presumed not to work, unless specificied otherwise via Mod whitelist, AI whitelist, or lobby advanced secret button.
Don't use blacklists. Use only whitelists.
Every unknown (Mod+AI) pair is presumed not to work, unless specificied otherwise via Mod whitelist, AI whitelist, or lobby advanced secret button.
Re: ValidAIs.lua
AAI comes fairly close, so does NTAI. Both of them are able to crash gently as well atm, although the level of feedback to end-users leaves a lot to be desired.Of all the persons, I thought you would be the one most able to understand we need some pragmatism here. Sure, having AIs that work with everything would be best. But the reality is, there is zero Spring AI in existence that meets this requirement.
I don't think this is a really hard goal to meet, frankly. Building an AI that can play the game at a basic level (send stuff at players, build a base, ramp up difficulty over time / other factors) is really pretty trivial. I think that supporting games that make use of Spring's UI core functions up to stuff like THIS should be really easy; it's only when we're talking about something like Fibre that this gets (slightly) complex, just because of the funky way it was designed.
Re: ValidAIs.lua
That's why I think the mod should be able to implement whatever algorithm they like with the ValidAIs.Lua. If you want a whitelist, use a whitelist. If you want a blacklist, use a blacklist.zwzsg wrote:Hoiju:
Don't use blacklists. Use only whitelists.
Every unknown (Mod+AI) pair is presumed not to work, unless specificied otherwise via Mod whitelist, AI whitelist, or lobby advanced secret button.
Re: ValidAIs.lua
The only place all this "whitelist" stuff applies is to Lobbies. Which should not be the place end-users use as the environment to launch SP games anyhow, imo.
Zwswg's front end is the model for what the future for SP looks like, in terms of design concept, if not specific features. In fact, I suspect that once every major game has a front-end that's decent, people will only use the Lobbies to launch SP very rarely. I don't think zwswg's current code meets that standard, but it's mainly a small jump forward, not a giant leap.
It's like AppLauncher and P.U.R.E. now- there's no need for a whitelist, because nobody playing P.U.R.E. will ever see alternatives to what I know works. When solutions like that are ubiquitous, I suspect that Lobby developers will probably deprecate those features, instead of wasting time maintaining something that no longer sees much use, or just leave it frozen. IOW, I really suspect this whole discussion becomes moot at that point.
Zwswg's front end is the model for what the future for SP looks like, in terms of design concept, if not specific features. In fact, I suspect that once every major game has a front-end that's decent, people will only use the Lobbies to launch SP very rarely. I don't think zwswg's current code meets that standard, but it's mainly a small jump forward, not a giant leap.
It's like AppLauncher and P.U.R.E. now- there's no need for a whitelist, because nobody playing P.U.R.E. will ever see alternatives to what I know works. When solutions like that are ubiquitous, I suspect that Lobby developers will probably deprecate those features, instead of wasting time maintaining something that no longer sees much use, or just leave it frozen. IOW, I really suspect this whole discussion becomes moot at that point.
Re: ValidAIs.lua
If you post that, Alantai Firestar is gonna come after you and post the exact same sentence with the words "mod" and "AI" swapped.Pxtl wrote:That's why I think the mod should be able to implement whatever algorithm they like with the ValidAIs.Lua.
While ultimately I would welcome more versatile controls, I'd rather reach an agreement on something simple and see it implemented now.
Re: ValidAIs.lua
You have no right to this sentenceArgh wrote:I don't think zwswg's current code meets that standard, but it's mainly a small jump forward, not a giant leap.
Re: ValidAIs.lua
He obviously meant a small step for me, not for humanity. :D
Re: ValidAIs.lua
Exactly, Mr. Lewis. Looking forward to recent advances, sometime after you fix that parser bug.
Re: ValidAIs.lua
He obviouslsy meant Louis, the jazzman.Argh wrote:Exactly, Mr. Lewis.
Re: ValidAIs.lua
Obviously not, since that one neither steps nor jumps but pedals.
Re: ValidAIs.lua
It's really funny when you forget your own joke. Louis, indeed.
Seriously though... your frontend just needs a map browser that can handle an unlimited map / list and setup for arbitrary AIs / sides / start positions, and I think that's pretty much it.
Seriously though... your frontend just needs a map browser that can handle an unlimited map / list and setup for arbitrary AIs / sides / start positions, and I think that's pretty much it.
Re: ValidAIs.lua
But that joke was to be a secret between us!
- Wasted time recoding what already exists
- Repeat the same problem of being too confusing for newb.
And then it'll be heading toward being like a new TASClient or SpringLobby. Which mean:Argh wrote:Seriously though... your frontend just needs a map browser that can handle an unlimited list and setup for arbitrary AIs / sides / start positions,
- Wasted time recoding what already exists
- Repeat the same problem of being too confusing for newb.
Re: ValidAIs.lua
Yeah, I gotta agree. Think about what the "skirmish" screen includes in most other RTS games.
1) Map
2) #, factions, and difficulty of AI players
That's it.
1) Map
2) #, factions, and difficulty of AI players
That's it.
Re: ValidAIs.lua
I know, sorry, I didn't get much sleep last night, need to take a nap before I do anything more clever than tie my shoelaces, tbh.But that joke was to be a secret between us!
As for the serious stuff:
First off, I agree, in part- four-click gameplay (faction, map, #AI players, difficulty) is the ideal. I think a map browser's a must, though- players will, after messing with the stuff in an install, probably learn about jobjol, and they're going to want support for the new maps.
But you both have a point- past a certain level of complexity, it may be self-defeating. I think a map browser that can deal with people who've downloaded a few hundred maps and want to play SP on all of them is a good idea, though.
And I know that one-click get-started-now gameplay was a very nice part of using AppLauncher.
Re: ValidAIs.lua
But I can see your point: Having a fairly complete Single Player lobby coded entirely in Lua would mean that any game developper could customize it, without needing engine devs support. This would basically remove the need for any feature request concerning single player setup support:
- GUI too cluttered for a simplistic game? Just remove lines of codes.
- Game is human vs Gaia? Don't even mention AI and alliances.
- Need a new kind of filter? Just do it.
- Need support for team mod option? Just add your own buttons.
- Need custom icons for certain options? Just draw them yourself.
- Need to enforce particular no X and Y together rule? Just add your tests.
Which bring us about your initial point about my frontend not being leapy enough. It would need at least a map scanner able to extract the minimap of any maps, and I don't even know how would that be doable. Too bad minimap caching is implemented by the lobbies and not ArchiveCacheV7.lua!
- GUI too cluttered for a simplistic game? Just remove lines of codes.
- Game is human vs Gaia? Don't even mention AI and alliances.
- Need a new kind of filter? Just do it.
- Need support for team mod option? Just add your own buttons.
- Need custom icons for certain options? Just draw them yourself.
- Need to enforce particular no X and Y together rule? Just add your tests.
Which bring us about your initial point about my frontend not being leapy enough. It would need at least a map scanner able to extract the minimap of any maps, and I don't even know how would that be doable. Too bad minimap caching is implemented by the lobbies and not ArchiveCacheV7.lua!