Consider more flexible queries

[ScottJDaley]

Instead of strict commands and syntax, allow for more natural queries.

Some examples:

• ada iron rod: Get information about the iron rod item.
• ada iron rod recipes: List all recipes for making iron rods.
• ada recipes for iron rods: List all recipes for making iron rods.
• ada recipes using iron rods: List all recipes that require iron rods.
• ada produce 60 iron rods: Minimize resource input to produce exactly 60 iron rods.
• ada maximize power from 240 oil: Maximize power generation from 240 crude oil assuming no other power generation (prompting for byproduct).
• ada produce 60 iron rods minimizing space: Minimize combine building footprint while producing exactly 60 iron rods, regardless of resource inputs.
• ada iron rod recipe: Get information about the recipe called "Iron Rod".
• ada manufacturer: Get information about the manufacturer building.
• ada manufacturer recipes: List all recipes in a manufacturer.

[ScottJDaley]

The query parsing would need new logic to interpret these examples.

• The produce <value> <item> expression is equivalent <item> = <value>
• The from <value> <item> expression is equivalent to `:input = '. Or negative value if we remove separate input and output variables again.
• Spaces no longer delineate variables and keywords. Everything between keywords will be interpreted as a variable expression.
• Attempt to match variable expressions to human-readable names, ignoring case. All match again variable parts between dashes.
• Don't do automatic substring matching. Only match variable parts between dashes. For example iron would match item:iron-ore because the it matches the iron part. That means something like ir would not match item:iron-ore. If this is desired, regex will still be supported.
• Allow objective at the end, e.g. ... minimizing space.
• The keyword recipe is different than recipes. The former will attempt to find a recipe that of that name. If the recipe expression is an item, the default recipe will be shown. The recipes keyword is used to get a list.
• The <expr> recipes expression is equivalent to recipes for <expr>. The <expr> here can be an item or building.

[ScottJDaley]

New idea:

Assume that outputs should be maximized and inputs (and constraints) should be minimized. Always keep the syntax order the same. Use a symbol such as ? to indicate what you want the optimizer to optimize for.

Some examples:

produce ? power from 240 crude oil

produce ? power and _ plastic from 240 crude oil

produce 60 iron plate

produce 60 iron plate with ? space

produce 60 iron plate from ? weighted resouces

produce 60 iron plate from ? resources without alternate recipes

produce 60 iron plate without refineries

produce ? power from 60 crude oil with _ fuel generators

produce 60 modular frames from ? resources and 30 iron rods

Formal query syntax:

          <query_syntax> ::= <output_keyword> <outputs>
                             [<input_keyword> <inputs>]
                             [<constraint_keyword> <constraints>]
                             [<inv_constraint_keyword> <inv_constraints>]

        <output_keyword> ::= "produce" | "make" | "create" | "output"
         <input_keyword> ::= "from" | "input"
    <constraint_keyword> ::= "with" | "using"
<inv_constraint_keyword> ::= "without" | "excluding"
           <and_keyword> ::= "and" | "+"
       <inv_and_keyword> ::= "and" | "or"
               <outputs> ::= <value> <output> [<and_keyword> <outputs>]
                <inputs> ::= <value> <input> [and <inputs>]
           <constraints> ::= <value> <constraint> [<and_keyword> <constraints>]
       <inv_constraints> ::= <constraint> [<inv_and_keyword> <inv_constraints>]
                <output> ::= <item_expr> | "power"
                 <input> ::= <item_expr> | <resource_expr> | "power" | ["unweighted"] "resources"
                             | "weighted resources"
            <constraint> ::= <recipe_expr> | <building_expr> | "space"
                             | "alternate recipes" | "byproducts"
                 <value> ::=  ["only"] <value_expr> |  "no"
            <value_expr> ::= <number> | <any_value> | <target>
                <number> ::= "[0-9]+"
             <any_value> ::= "any" | "_"
                <target> ::= "?" | ""

[ScottJDaley]

Some notes about the above syntax:

• The inverse constraints (inv_constraints) are only there to make the query more natural, but the same thing can be accomplished with regular constraints. For example ... with 0 alternate recipes and 0 fuel generators is equivalent to ... without alternate recipes or fuel generators
• If a building is specified in a constraint with a value greater than 0, all other buildings of that type are turned off.
• Byproduct handling still need to be figured out. One option is to try and find a solution without byproducts. If none exists, automatically find one with byproducts. This can also be explicitly controlled using the byproducts keyword in a constraint.
• The only keyword can be used in front of a <value_expr> to indicate that all other entities of the same type should be disabled. For example, produce ? iron plate from only 60 iron ore will turn off all other resource inputs. The command produce only power from 60 crude oil would fail because there must be a byproduct.

[ScottJDaley]

More details in https://github.com/ScottJDaley/ada/blob/master/query_syntax.md