QualityPrototype extended

[thesixthroc]

I appreciate that most of these entries are not capped at 1, because that would break the already working property for the Inverted Quality mod.

How is that? So far a QualityPrototype::level is uint32, which means a default_multiplier = `1 + 0.3 * level` was never able to go below value of 1: even if i would keep the limits for multipliers to be >= 1, it would still not be able to break anything because all the values are carefully set to keep backward compatibility. By allowing values to go down to 0.01 i am effectiely extending what is possible.

To correct myself, the problem only comes when the modifier affects something which cannot also be controlled by the entity's prototype fields. This is not the case for the extensions you list, they indeed just extend functionality.

For more details: Inverted Quality has Normal at level 5 but also wants Normal to work the same as it does in vanilla. Properties like `mining_drill_resource_drain_multiplier` cause a problem, because since it is capped at 1, it is not possible for levels to be worse than Normal while keeping Normal unchanged from vanilla (as one cannot compensate for its effect by nerfing all mining drill prototypes by 5 quality levels).

[boskid]

QualityPrototype.crafting_machine_extra_module_slots

Also possibly CraftingMachinePrototype.quality_affects_module_slots (this has some precedent; see CargoWagonPrototype.quality_affects_inventory_size and LabPrototype.uses_quality_drain_modifier)

Added QualityPrototype::beacon_module_slots_bonus.
Added BeaconPrototype::quality_affects_module_slots.
Added QualityPrototype::crafting_machine_module_slots_bonus.
Added CraftingMachinePrototype::quality_affects_module_slots.
Added QualityPrototype::mining_drill_module_slots_bonus.
Added MiningDrillPrototype::quality_affects_module_slots.
Added QualityPrototype::lab_module_slots_bonus.
Added LabPrototype::quality_affects_module_slots.

[Veden]

Would adding entity resistance multiplier one for flat values and one for percentages be possible and reasonable?

[boskid]

For Mining Drills (in particular, thematically non "mining" collectors, like the flower harvesting drone things from pY), a multiplier for mining_search_radius.

Given that mining radius affects area with square, i decided that multiplier would be a little too much and an additive bonus would be more suitable.

Added QualityPrototype::mining_drill_mining_radius_bonus.
Added MiningDrillPrototype::quality_affects_mining_radius.

[MrSmoothieHuman]

Actually, since mining drills just got their radius increased with an additive bonus, could beacons get one too?

[boskid]

Actually, since mining drills just got their radius increased with an additive bonus, could beacons get one too?

Added QualityPrototype::beacon_supply_area_distance_bonus.
Added BeaconPrototype::quality_affects_supply_area_distance.

[LuziferSenpai]

Would this also be here correct?

viewtopic.php?t=115984

[snouz]

Suggestion: add the ability for a quality to tint items / entity (combined with "draw sprite by default = false", it would give an alternative way to represent quality)

[MrSmoothieHuman]

im not sure if you are still looking for suggestions, but while i was mucking about with reactors i thought of one - maximum_temperature_quality_multiplier?
it'd mutlitplicatively increase the amount of heat a specific entity could have at one moment (if a building can hold 1000 degrees and has a quality mutlipler of 1.5x, it can hold 1500).
I'm not entirely sure how well it'd work in vanilla specifically? since you only get one tier of heat pipe (and i dont expect them to be effected by this, if it was implemented), but it'd be very nice as an option for modders

[braxbro]

im not sure if you are still looking for suggestions, but while i was mucking about with reactors i thought of one - maximum_temperature_quality_multiplier?
it'd mutlitplicatively increase the amount of heat a specific entity could have at one moment (if a building can hold 1000 degrees and has a quality mutlipler of 1.5x, it can hold 1500).
I'm not entirely sure how well it'd work in vanilla specifically? since you only get one tier of heat pipe (and i dont expect them to be effected by this, if it was implemented), but it'd be very nice as an option for modders

This is nice even in vanilla because it increases thermal capacity of reactors & allows for more storage as heat (which is the densest mode of storage in the game iirc) but yeah mods definitely could make good use of this

[braxbro]

Could we get a quality multiplier for a building’s ModuleReceiver base_effects and the ability to turn off the base speed scaling for said buildings?

A planet mod I have planned relies on some crafting machines’ production speeds lining up with the spoil time of planetary products. This essentially limits the amount of non-export resources available to 1 production cycle’s worth, pushing optimization of item lifetime and resource efficiency first and foremost. If these synced buildings were to scale with quality, I would want them to scale innate prod bonuses, not speed, to keep the feel consistent as the player advances on the planet.

[protocol_1903]

Could we get a quality multiplier for a building’s ModuleReceiver base_effects and the ability to turn off the base speed scaling for said buildings?

A planet mod I have planned relies on some crafting machines’ production speeds lining up with the spoil time of planetary products. This essentially limits the amount of non-export resources available to 1 production cycle’s worth, pushing optimization of item lifetime and resource efficiency first and foremost. If these synced buildings were to scale with quality, I would want them to scale innate prod bonuses, not speed, to keep the feel consistent as the player advances on the planet.

I'd recommend that as a crafting machine property, not a quality one, so that mods with very specifically tuned machines (or complex scripting with machines) don't need to interact with the mechanic

[Puzz1ebox]

Would it be possible to bake in support in next and next_probability for divergent behavior?

I will try to exemplify this the best I can.

Currently the quality mechanic and QualityPrototype behave in such a way as to allow convergent behavior.
You can create a QualityPrototypes untied to any other normal quality, that cannot be reached under any circumstances.
Additionally, you can tie an arbitrary number of other QualityPrototypes that are the next values of the initial QualityPrototype you created.
At the end of this new line of QualityPrototypes, you can establish convergent behavior by doing something like:

{
type = "quality",
name = "secondToLastQualityPrototype",
level = 3,
order = "b-a",
color = {214, 169, 32, 255},
next = "lastQualityPrototype",
next_probability = 0.5,
subgroup = "qualities",
icon = "some/icon/path/icon.png",
},
{
type = "quality",
name = "lastQualityPrototype",
level = 4,
next = "legendary",
order = "b-b",
color = {230, 11, 30, 255},
next_probability = 0.5,
subgroup = "qualities",
icon = "some/icon/path/icon.png",
},

You may also leave the value of next under the QualityPrototype "epic" as "legendary".
If you outline things in this way, you will create convergent behavior where two qualities of different lines can converge on the QualityPrototype "legendary".

To more get to my point, ideally it would be nice to have alternative values or inputs (or simply being able to define next1, next2, ... and next_probability1, next_probability2,...) such that we can create new lines of quality that can both converge and diverge from various defined QualityPrototype lines.

Personally, this would be useful to me in order to create "quality specializations" or lines that have uniquely strong areas of power versus general upgrades, with drawbacks or other tuning being made to design interesting gameplay.

Furthermore, I do think that it would be to some benefit to be able to define previous and previous_probability (to make mods that allow for worsening qualities beyond normal, such as during extremely high speed production operations), and by extension previous1, previous2, ... etc.

I did test if I was able to create circular qualities (another certainly fun idea), but I was stopped and greeted by this error:

Failed to load mods: Error while running setup for quality prototype "normal" (quality): Quality cycle detected: normal -> uncommon -> transitional -> rare -> epic -> legendary -> normal

Mods to be disabled:
• quality (2.0.55)

(transitional is a QualityPrototype I created for testing purposes)

I assume the above is intentional behavior.
That's it for the suggestion though.

[boskid]

Would it be possible to bake in support in next and next_probability for divergent behavior?

No. There will not be a divervent behavior, similarily as there are no loops right now and there are no convergent behavior right now. There are some places where game straight assumes the quality progression is linear.

--

I wont be accepting any more requests about the additions to quality prototype anymore (with the only possible exceptions being stuff that is already affected by quality if i get convinced it would make sense).

Overall quality design was to make it possible to have stronger(maybe even overpowered) machines at the cost of player deciding to throw significantly more resources at crafting it. One of the elements in this design is that there should be no need to define any extra parameters because trying to balance something that was supposed to be not balanced just creates pain proportional to the amount of qualities.

Most of the values that were added to the quality prototype are just to allow having a slower or toned down quality progression in case there are more qualities in which case having level being an integer was not possible to reduce overall bonus per level to less than 30%. Having any sorts of values be per-prototype seems to be creating a modding compatibility nightmares because doing an entity prototype copy before all modifiers are populated would cause the copy to be missing values in it, and doing a quality prototype copy requires visiting every entity to programmatically assign it some new modifiers following some undefined progression. The only exception i did for per-prototype values was with crafting machines as i did this in a form of an experiment to see what problems with mod compatibility would that create, and partially because those are the most important prototypes in the game and having them too overpowered has made some of the mods intentionally declare incompatible with quality to avoid degraded game progression.

Having mods define more qualities is reasonable. Having mods tone down the quality progression (either by reducing quality effects or reducing probability of rolling next quality) is reasonable. Having mods need to define each parameter for each quality is bad, it creates problems with mod compatibility and attempts at balancing something not intended to be balanced.