Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recommended maps, AIs and engines hints [tracking bug] #817

Open
specing opened this issue Jan 12, 2018 · 27 comments
Open

Recommended maps, AIs and engines hints [tracking bug] #817

specing opened this issue Jan 12, 2018 · 27 comments

Comments

@specing
Copy link
Contributor

@specing specing commented Jan 12, 2018

from abma in channel:

[{
    game = "Balanced Annihilation",
    engine = "spring 104.0",
    engine-dev = "spring 104.0.1-473-g112e966 develop",
    rapid = "ba:stable",
    rapid-dev = "ba:test",
    maps = [
        { "name": "Delta Siege Dry", "springname": "DeltaSiegeDry"}
    ]
}]

How much flexibility is required?
What I'd like:

  • for each game:
    • for each map:
      • for each version:
        • give a list (possibly with ranges) of game versions it is recommended with (green in choice box)
        • give a list (possibly with ranges) of game versions it is not recommended with (red in choice box)
    • for each engine:
      • for each version:
        • give a list (possibly with ranges) of game versions it is recommended with (green in choice box)
        • give a list (possibly with ranges) of game versions it is not recommended with (red in choice box)
    • for each AI
      • for each version (engine version in the case of engine AIs)
        • give a list (possibly with ranges) of game versions it is recommended with (green in choice box)
        • give a list (possibly with ranges) of game versions it is not recommended with (red in choice box)

Each game is supposed to maintain its own file listing the above

{
   version = 1,
   maps = [{
       name = "Village Crossing",
       versions = [{
           v = "all",
           r = yes
        }]
     },{
       name = "Some map with a bad version"
       versions = [{
           v = "v3bad",
           b = yes
       },{
           v = "all",
           r = y
       }]
     }]
  engines = ...
}
@springraaar

This comment has been minimized.

Copy link

@springraaar springraaar commented Feb 17, 2018

just use modinfo.lua

local modinfo = {
name='Metal Factions',
shortName='metal_factions',
version='v0.990',
game='',
shortGame='',
mutator= 'Official',
description='Metal Factions',
url='www.metalfactions.pt',
modtype=1,
recommendedEnginesStrict=1, -- hide non-recommended engine versions?
recommendedAIsStrict=1, -- hide non-recommended AI versions?
recommendedMapsStrict=0, -- hide non-recommended map versions?
recommendedEngines = {
"104.0",
"104*"
},
recommendedAIs = {
"MFAI*",
"RAI*"
} ,
recommendedMaps = { -- empty list: assume all maps are accepted
}
}

return modinfo


empty list : allow everything with no warnings

filled list but with strict=0 : show all, but split between recommended/unsupported or show a warning on unsupported items

filled list but with strict=1 : show recommended items only

matching is done by string comparison ignoring case. Using * as wildcard.

@specing

This comment has been minimized.

Copy link
Contributor Author

@specing specing commented Feb 18, 2018

As stated in channel:

  1. SL does not read modinfo.lua and would either need to load archive itself or unitsync be changed to export this info. I don't like either option.
  2. It does not make it possible to update recommended lists after the game is released for all previous releases.

I am however wondering if it would be best to just lua-ify it, have:
iscompat (game, gamever, map, mapver) -> {good, bad, unknown}
iscompat (game, gamever, AI, AIver) -> {good, bad, unknown}
iscompat (game, gamever, engine, enginever) -> {good, bad, unknown}
iscompat (game, gamever, engine, enginever, map, mapver, AI, AIver) -> {good, bad, unknown}
the last one would be called after the whole triple is selected (as there are cases where a compatible AI does not work on a compatible map with a compatible engine).

Then most of the issues with the data format and pattern matching above would be gone.

@abma

This comment has been minimized.

Copy link
Member

@abma abma commented Mar 6, 2018

please no executable code, it makes it difficult to use in other projects / is a security nightmare.

IMHO it should be data only.

@specing

This comment has been minimized.

Copy link
Contributor Author

@specing specing commented Mar 6, 2018

SL already is a security nightmare, I don't see a few bits of lua changing this.

@specing

This comment has been minimized.

Copy link
Contributor Author

@specing specing commented Mar 6, 2018

and

  1. There is nothing stopping you from validating this code after it is submitted (and making SL download it securely);
  2. I don't see a good way to encode the mass of possible combinations.
@abma

This comment has been minimized.

Copy link
Member

@abma abma commented Mar 6, 2018

IMHO the ai list should be a whitelist.

only add game / map / ai which are know to work.

for the "perfect" solution chobby should be used.

@specing

This comment has been minimized.

Copy link
Contributor Author

@specing specing commented Mar 7, 2018

That is the theory. In practice a working official AI might not work on all maps and even if it does, it might not work with all supported engine versions. Furthermore, the game/map/engine triple might get extended soon to a state where game is a list. Good luck making a static data format that is even slightly future-proof, easy to write and small in size.

Chobby is as I've said already, broken by design.

@abma

This comment has been minimized.

Copy link
Member

@abma abma commented Mar 7, 2018

KISS!!!

when there is really no way of filtering: add a new attribute in the json file which contains the lua code / regex / whatever.

ATM i really don't see this requirement.

@abma

This comment has been minimized.

Copy link
Member

@abma abma commented Mar 7, 2018

IMHO an ai should work with all maps compatible to a game else its "incompatible" to the game

@abma

This comment has been minimized.

Copy link
Member

@abma abma commented Mar 7, 2018

IMHO an ai should work with all maps compatible to a game else its "incompatible" to the game

also a game still can override / replace the ai from script.txt.

-> no code needed, static json is enough

@specing

This comment has been minimized.

Copy link
Contributor Author

@specing specing commented Mar 7, 2018

when there is really no way of filtering: add a new attribute in the json file which contains the lua code / regex / whatever.

So then we'd have JSON AND Lua?
It should work, yes. But what if it does not work? We've tested many more maps in multiplayer than with a particular bot.

@abma

This comment has been minimized.

Copy link
Member

@abma abma commented Mar 7, 2018

no, lua should be avoided: it should be only used when we hit some problem which we can't solve with json.

i still don't see a reason why lua code is needed: we want/ need a static list.

@springraaar

This comment has been minimized.

Copy link

@springraaar springraaar commented Mar 9, 2018

i've suggested it before.

There could be configuration properties to define if the lists provided are strict or not, like this:

recommendedEnginesStrict=1, -- hide non-recommended engine versions?
recommendedAIsStrict=1, -- hide non-recommended AI versions?
recommendedMapsStrict=0, -- hide non-recommended map versions?

(the concept applies regardless of whether it's lua, json or whatever)

@anmeldekram

This comment has been minimized.

Copy link

@anmeldekram anmeldekram commented Apr 2, 2018

Each game is supposed to maintain its own file listing the above

Why would games do that?

Let's look at existing "solutions":

  1. chobby: games do not include any information about AIs at all. Instead that data is in the lobby.

  2. springweblobby: config is also in lobby, but hardcoded.

  3. spring is an engine! game-installers already include only compatible AIs and maps, no need for config files.

@specing

This comment has been minimized.

Copy link
Contributor Author

@specing specing commented Apr 2, 2018

How are us lobby devs supposed to know which maps, AIs and engines are recommended for game X version Y?

You are missing the point, this bug is not about game installers at all.

@anmeldekram

This comment has been minimized.

Copy link

@anmeldekram anmeldekram commented Apr 3, 2018

How are us lobby devs supposed to know which maps, AIs and engines are recommended for game X version Y?

I assume that in the cases of chobby and springweblobby the game devs and lobby devs talked to each other. Another option that has been used is that game devs create their own fork of the lobby.

So again: Why should a game maintain such a new file that is only used by springlobby? Unlikely they would do that, keeping in mind that they already have created their own solutions to the AI/maps problem.

If your proposed way is meant to become a spring-wide standard then this thread should not be hidden on springlobby-repo. It would belong in a place where the devs of every lobby and game notice it.

@anmeldekram

This comment has been minimized.

Copy link

@anmeldekram anmeldekram commented Apr 3, 2018

Also should not existing standard be used instead of inventing something new?
For maps there is already a engine-wide standard: validmaps.lua

(no serious game uses validmaps.lua because TASClient, the only lobby that implemented it, was discontinued shortly after)

@specing

This comment has been minimized.

Copy link
Contributor Author

@specing specing commented Apr 3, 2018

I assume that in the cases of chobby and springweblobby the game devs and lobby devs talked to each other.

With my way they would not depend on any talks. It would be documented how to do this and would require no involvement from lobby devs whatsoever.

Another option that has been used is that game devs create their own fork of the lobby.

Yeah right, like they don't have better things to do than maintain their own private forks.

So again: Why should a game maintain such a new file that is only used by springlobby?

I'm not patenting this method or placing any restrictions on its use. They will use it unless they want players to crash and then blame the game as broken.

Unlikely they would do that, keeping in mind that they already have created their own solutions to the AI/maps problem

Have they? I don't see any solutions to this.

If your proposed way is meant to become a spring-wide standard then this thread should not be hidden on springlobby-repo. It would belong in a place where the devs of every lobby and game notice it.

Springlobby is the official client. What other place would you propose?

Also should not existing standard be used instead of inventing something new? For maps there is already a engine-wide standard: validmaps.lua

Existing "standard" (who is using it?) is inedequate, does not cover engines and cannot be retroactively updated.

It is a shame that nobody wanted to pick up work on TASClient.

@anmeldekram

This comment has been minimized.

Copy link

@anmeldekram anmeldekram commented Apr 3, 2018

To see existing solutions you should try/look at chobby and springweblobby like I mentioned. Some links to relevant files:
https://github.com/ZeroK-RTS/Chobby/blob/master/LuaMenu/configs/gameConfig/zk/aiBlacklist.lua
https://github.com/ZeroK-RTS/Chobby/blob/master/LuaMenu/configs/gameConfig/zk/mainConfig.lua

springweblobby/swl-website@66a6be3#diff-11696436c3dac039cfeffd240a99d8f7
etc
Or look how www.zero-k.info handles maps, look at what the plans of other games are.
(Sadly none off those ways are a true standard, but for their needs that is not needed. Appearently private forks are not problematic for game devs either because lobby devs help with the forks)

I did not know that springlobby was the official client. I always saw springlobby as one of several equal lobbyclients that can connect to the spring server.

What other place would you propose?

Spring forum might be a place where all lobby and game devs are registered. Or discord with the inter-server bridges.

To prevent this suggestion from being dead at birth it should not be a springlobby-only feature. Games will not maintain multiple files to stay compatible with several lobbies. Especially since games have already figured out their own ways or are currently doing so.

Without agreements between games and lobbies to use the same standards, you will get chaotic situations like this:

Two players are in the same battleroom. Player-A is prevented from adding bad AIs to the game. However Player-B uses a different lobby that assumes a different valid-AI-file in the game-archive and so is not prevented from adding bad crashing AIs.

@abma

This comment has been minimized.

Copy link
Member

@abma abma commented Apr 3, 2018

@anmeldekram: please stop polluting issues in this tracker with non-constructive comments. if you can do it better please send a pull request or discuss in the springrts.com forum.

@anmeldekram

This comment has been minimized.

Copy link

@anmeldekram anmeldekram commented Apr 3, 2018

Pointing out that https://springrts.com/wiki/Validmaps.lua & other ways already exist is non-constructive? You are planning a new springlobby-only standard: Ok, by then.

@abma

This comment has been minimized.

Copy link
Member

@abma abma commented Apr 3, 2018

validmaps.lua is known: it has several drawbacks, i.e. that updating it requires a new release to be made for the game. map/engine/game/ai usually are released independent from each other so updating recommended maps/ai/engines hints should be independent, too.

having few / no dependencies is IMHO very important in this case.

see #220

@anmeldekram

This comment has been minimized.

Copy link

@anmeldekram anmeldekram commented Apr 3, 2018

Why is releasing a new game version problematic?
For game devs it is quick and easy. For players the required download of such update is very small. In some cases a game might become compatible with new AIs/maps/engines by updates in the gamefiles, requiring new release anyway.

map/engine/game/ai usually are released independent from each other

They are also released independent from lobby.

Chobby is a lobby that already uses configs kept in the lobby.
It would make sense to use the same files, as to not create extra work for games to maintain compatibility with different lobbies.

see #220

wrong link? that one contains nothing new but a link back to this issue.

@springraaar

This comment has been minimized.

Copy link

@springraaar springraaar commented Apr 6, 2018

validmaps.lua is known: it has several drawbacks, i.e. that updating it requires a new release to be made for the game. map/engine/game/ai usually are released independent from each other so updating recommended maps/ai/engines hints should be independent, too.

This is only a problem if the lists are strict and have no wildcards, as i've stated before there could be options to define whether they are strict or not.

If your proposed way is meant to become a spring-wide standard then this thread should not be hidden on springlobby-repo. It would belong in a place where the devs of every lobby and game notice it.

I agree that there should be a spring-wide standard that future engine versions and lobbies would comply to (even running the spring binary directly and selecting the game,etc. through its UI). But even if it's a SL specific thing I wouldn't mind maintaining a json file either on the game package or some website.

The clock is ticking, we need something that works. On metal factions new players often pick the AIs that won't work despite the explicit note for MFAI on the website and on the greeting message on the battle rooms.

@silentwings

This comment has been minimized.

Copy link
Contributor

@silentwings silentwings commented Apr 8, 2018

Adding new files/standards parsed solely by SL will be ignored by 99% of devs.

The issue should first be addressed on the engine/game design side (-> should AIs be developed within games or should they be agnostic; when/if should old/unmaintained/non-lua AI interfaces be deprecated/removed). Inventing lobby-side sticking plasters and placing them over gaping wounds is likely to create a mess without solving the problem.

Why is releasing a new game version problematic? For game devs it is quick and easy.

This claim is often incorrect, see recent history.

@anmeldekram

This comment has been minimized.

Copy link

@anmeldekram anmeldekram commented Apr 9, 2018

Why is releasing a new game version problematic? For game devs it is quick and easy.

This claim is often incorrect, see recent history.

I found nothing on https://github.com/spring/RapidTools/issues , your objection is too cryptic for me.

@springraaar

This comment has been minimized.

Copy link

@springraaar springraaar commented Aug 8, 2018

Adding new files/standards parsed solely by SL will be ignored by 99% of devs.

I've been told 90% of players use springlobby. In that case, it can set the standards and other lobby developers will probably adopt them eventually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.