Support numeric variables for lenience

[blkerby]

Currently we have an assortment of helpers to express spike suit leniency, based on the damage source per attempt: e.g., spikes, thorns, and Samus Eater. Randomizers (and other tools) have to override these individually. This grows more complicated with slopespark, since each attempt takes an enemy hit, and it would be messy to have to define helper for each type of enemy.

A way to solve this is to extend the schema to be able to reference a numeric variable in spikeHits, enemyDamage, and similar logical requirements. In other words, where we are currently limited to expressing a constant, e.g.

{"spikeHits": 2}

We would like to be able to reference a leniency-dependent variable, e.g.

{"spikeHits": "n_spikeSuitLenience"}

Some proposed details:

• Use the prefix "n_" (for "numeric"), since it is a new type of entity in the schema.
• We'll have a new file "numerics.json" (similar to helpers.json) to declare the numeric variables and assign default values for them.
• We'll want to define some simple arithmetic operators, for example addition and multiplication. Then we could define "n_spikeSuitAttempts" as {"add": ["n_spikeSuitLenience", 1]}. Likewise we may want to be able to mulitiply heat frames by a lenience value.

[osse101]

Big fan of being able to describe stacked leniencies with math objects.
Is the idea to write {enemyDamage: {enemy: X, type: contact, hits: n_slopeSparkLenience}}? That's clean. My initial reading was {add[enemyDamage{enemy:X, type:contact, hits:1}}, n_slopesparklenience]}.

numerics sound like they would replace some of the helper leniencies that are just numbers of damage?

The other problem still is deciding what total amount of energy or patience is desired when you are already in insane difficulty.

[blkerby]

Yeah presumably we could define "n_slopeSparkAttempts" as {"add": ["n_slopeSparkLenience", 1]} in the numerics.json so then you could just refer to it as "n_slopeSparkAttempts" in the strats. Or we could just skip the "n_slopeSparkLenience" and just define "n_slopeSparkAttempts" as the base variable to get overridden by the randomizer. Then we wouldn't need to add 1 here. Though I imagine there would still be other places where you'd want to do math.

[kjbranch]

Added in #2646 , #2678
Still a lot of things need to be migrated. Should this issue remain open?