Description
Certain bots and scripts - especially memebots - require certain mutators, state setting, or rendering inorder to work properly. In this issue I propose that we add an additional field to the bot/script's config that lets the framework (and GUI) know that the listed mutators, state setting, or rendering are expected by the bot. Additionally, the match config should have a setting to automatically turn on any required match settings, which is true by default.
Required match settings
A good name for this new config field would be required_match_settings. The value of this field should be a comma seperated list of match settings. The strings rendering and state setting makes the bot require rendering and state setting. Required mutators are speficied using the mutators name, a colon, and then the value.
Example:
required_match_settings = rendering, state setting, boost strength: 2x, ball weight: heavy
means that bot/script requires rendering and state setting to be active and that mutator Boos Strength is set to 2x and Ball Weight is set to heavy.
The names of mutators and their values follow this https://github.com/RLBot/RLBot/wiki/Config-File-Documentation#mutator-configuration, but with lower letters (or is that inconsistent? It is also confusing with Pascal Case)
Multiple values
The above defines how a bot/script can require a specific mutator setting, but what if multiple values for a mutator is okay? E.g. both Boost Strength must be either 2x or 10x? I am open to suggestions here, but I find that the best solution is the following;
If multiple values for a mutator are allowed, a python-like list of values must be given. E.g.:
required_match_settings = boost strength: [2x, 10x]
Incompatible mutators
What if a bot/script allows a mutator to be any value except one? In this case it would be much more efficient to declare what the bot is not compatible with. I see three options here. In all proposed options below, it is of course not valid to both require and disallow a certain mutator value.
Option 1) Too bad, you must list all compatible instead
This option is to not add anything special to disallow mutators. Instead the config must list all the allowed mutator values, if it really must disallow others.
Option 2) A incompatible_match_settings field
In this option we add the dual to the required_match_settings field, where the developer can list match settings that the bot does not work with. E.g.:
required_match_settings = state setting
incompatible_match_settings = boost strength: 1x
Option 3) Negated listing
In this option we allow the user to negate the mutators value(s) by putting a ! in front of it in the required_match_settings field. E.g.
required_match_settings = boost strength: !1x
This seamlessly extends to multiple values following the python-like list proposed above:
required_match_settings = boost strength: ![1x, 1.5x]
Automatic match setting requirement resolution
Given that bots/scripts can declare which match settings they require, the framework should also listen to them. Hence, I propose that we add the field to the match config called listen_to_bot_requirements (unless we find something better). If listen_to_bot_requirements is true, the framework will override the match settings where a bot/script require something specific before starting the given match. An exception is thrown if the bots/scripts have incompatible required settings.
The GUI
The long term goal of this proposal is that the GUI will also be aware of the bots/scripts required match settings. This will allow us to prompt the user, that certain settings and mutators will be changed, when they add a bot/script that requires them. E.g. the user adds Sniper to a team, but state setting is disabled. Then a popup window says "Sniper requires: state setting. Do want to change these settings and proceed?" with an "ok" and "cancel" button. The GUI should also say "X requires match settings incompatible with Y" whenever the users attempts to include X but Y is already in the match.