More Generic Ways to Implement Quality Values in Prototypes

[Dweaver]

In cases like "quality_values" in "CustomTooltipField"s, or "crafting_speed_quality_modifier" in "CraftingMachinePrototype", quality values are implemented as a dictionary keyed by the name of a QualityPrototype. For example, if I want a special crafting machine whose speed = 1 * quality.level, the straightforward implementation would be to write:

Code: Select all

crafting_speed_quality_modifier = { ["uncommon"] = 2, ["rare"] = 3, ["epic"] = 4, ["legendary"] = 6 }

However, this implementation wouldn't support modded quality levels. If hypothetical user Markus64 adds 17 new quality levels above legendary, my special crafting machine would have no idea, and would scale using whatever the default values were.

I can counter this by instead implementing those quality values in data-final-fixes, with code looking something like:

Code: Select all

for k, v in pairs(data.raw.quality) do
	kwality_values[k] = v.level
end

However, this has the following issues:
1) The quality values now have to be implemented distant from the rest of the prototype, which feels messy.
2) If hypothetical user Markus64 (who I don't know exists) is a psychopath who added their qualities in data-final-fixes (I'm sure they had their reasons), my mod may or may not notice depending on how mod load order works out. The possibility just gives me some unpleasant background anxiety.

I think it would save a lot of headache if I had some way to define quality values according to quality level, rather than prototype name.

My simplest, hackiest idea for doing this would be to have QualityID interpreted as referring to level if the string is formatted a particular way, or matches some reserves keyword(s). So, for example:

Code: Select all

crafting_speed_quality_modifier = {
	["Xx_scale-with-level_xX"] = "1 + L",  -- a MathExpression where L = QualityPrototype.level, generically works even for Markus64's 17 new qualities
	["####2"] = 17,  	-- arbitrary override of level 2, that works even for hypothetical "ralphs-secret-rare"
	["legendary"] = 6	-- stays constant even if someone mods legendary's level to something else.  I assume this kind of case is why quality values were implemented as a dictionary in the first place.
 }

That's just an example, I'm not hoping for any particular implementation. I just like playing with quality, and wish doing so was less of a headache.

[Shemp]

+1, having a separate "quality_expression" field with a MathExpression as a fallback feels quite natural to me.