[2.0.14] Add more ways for quality to affect items

[redplasticstraw]

It's weird that only a specific few properties about a prototype are affected by quality. For example,

- Why am I not able to set roboport ranges to scale with quality?
- Why are beacon ranges not able to scale?
- Why can't train attributes scale with quality? (acceleration, top speed, cargo wagon sizes, etc.)

I understand why most of these aren't specifically in vanilla for the sake of balance, but there should still be some way for mod creators to add these to their items if they so desire.

[curiosity]

Quality is extremely hardcoded. The biggest letdown of Space Age, IMO.

[danbopes]

+1. I think mods should be able to customize qualities of existing items as well as custom buildables

[UberWaffe]

(I suspect the quality approach is too far down the line to change, but here it is anyway.)

How I would have liked the quality engine and lua to have worked:

TL;DR
More like next_upgrade. Separate prototype item / entity / recipe per quality level, instead of linear modifiers scattered all over the definitions.


Why
As much flexibility in the quality mechanic as in the 'base' mechanics. No additional coding needed to support new entity / item features.


Details
Instead of defining linear modifiers that apply per quality level, let a new prototype be defined per quality level for that item / entity / recipe.

For item, entity, equipment, etc prototypes:
Two fields ->

• "quality_level" :: uint32, which indicates what level of quality this prototype is for.
• "quality_group" :: string, which indicates what base item / entity / prototype this is a quality variant of.

So the various linear quality modifiers are no longer needed. It just uses the already existing prototype definitions.

For recipes:
Same two fields ->

• "quality_level" :: uint32, which indicates what level of quality this recipe is for.
• "quality_group" :: string, which indicates what base recipe this is a quality variant of.

For ItemIngredientPrototype (not fluids) in the recipe one new field:
"quality_level" :: uint32, which level must this ingredient be of for this recipe. By default matches the quality_level of the recipe.

For ItemProductPrototype of a recipe output, one new field:
"quality_level" :: uint32, what level of quality is the resulting item of. By default matches the quality_level of the recipe.

Restrictions / validation on prototypes:
quality_level cannot exceed the highest QualityPrototype level defined.
All the prototypes in a quality_group must be of the same type. (I.e. I cannot say that an electric furnace is the quality level 2 of a laser turret.)
Any other restrictions to avoid things that would obviously break things.

Include lua libraries in the quality package to facilitate this:
I.e. functions for : duplicating a prototype.
Applying the standard linear modifiers based on quality level.
Create recipe variants for each quality level.
etc.

This way, I could make walls that do not just have more health for higher levels, but have adjusted resistances.
Or a make legendary rocket silos require an epic rocket silo and legendary prometheum science packs in their recipe and then need only legendary fish as a resource to launch rockets.
Or legendary biters that revive as epic biters upon death.

[curiosity]

TL;DR
More like next_upgrade. Separate prototype item / entity / recipe per quality level, instead of linear modifiers scattered all over the definitions.

Yes. Very much this. It's the natural way to extend quality from the pre-existing system that would have integrated way more seamlessly with the existing mod code and have more potential for further development. It is how I assumed quality was going to be implemented, though maybe I should have known better. I don't know if it was simply overlooked or if there was some reason it didn't work out, or maybe it was too much effort for kovarex.

Though I do not agree with your proposed implementation. It should still be more like next_upgrade. Implicit quality levels.

[zanven]

Quality is extremely hardcoded. The biggest letdown of Space Age, IMO.

my hope like base game development, once the bug smashing is done these key game features start getting lua modding interfaces

[CyberWizard2261]

(I suspect the quality approach is too far down the line to change, but here it is anyway.)

How I would have liked the quality engine and lua to have worked:

TL;DR
More like next_upgrade. Separate prototype item / entity / recipe per quality level, instead of linear modifiers scattered all over the definitions.


Why
As much flexibility in the quality mechanic as in the 'base' mechanics. No additional coding needed to support new entity / item features.


Details
Instead of defining linear modifiers that apply per quality level, let a new prototype be defined per quality level for that item / entity / recipe.

For item, entity, equipment, etc prototypes:
Two fields ->

• "quality_level" :: uint32, which indicates what level of quality this prototype is for.
• "quality_group" :: string, which indicates what base item / entity / prototype this is a quality variant of.

So the various linear quality modifiers are no longer needed. It just uses the already existing prototype definitions.

For recipes:
Same two fields ->

• "quality_level" :: uint32, which indicates what level of quality this recipe is for.
• "quality_group" :: string, which indicates what base recipe this is a quality variant of.

For ItemIngredientPrototype (not fluids) in the recipe one new field:
"quality_level" :: uint32, which level must this ingredient be of for this recipe. By default matches the quality_level of the recipe.

For ItemProductPrototype of a recipe output, one new field:
"quality_level" :: uint32, what level of quality is the resulting item of. By default matches the quality_level of the recipe.

Restrictions / validation on prototypes:
quality_level cannot exceed the highest QualityPrototype level defined.
All the prototypes in a quality_group must be of the same type. (I.e. I cannot say that an electric furnace is the quality level 2 of a laser turret.)
Any other restrictions to avoid things that would obviously break things.

Include lua libraries in the quality package to facilitate this:
I.e. functions for : duplicating a prototype.
Applying the standard linear modifiers based on quality level.
Create recipe variants for each quality level.
etc.

This way, I could make walls that do not just have more health for higher levels, but have adjusted resistances.
Or a make legendary rocket silos require an epic rocket silo and legendary prometheum science packs in their recipe and then need only legendary fish as a resource to launch rockets.
Or legendary biters that revive as epic biters upon death.

I completely agree with you, I would change only 1 thing, IMO a recipe would not need quality, instead just an optional way to replace an "item.name" in ingredients and results for "item.quality_group", but that's my opinion, the system you described is excellent

[gujarat6]

I wanted to mod the roboports range scaling with quality on day1, but found out everything is hardcoded. I'd love this change to happen.

[Rseding91]

Any potential changes always have to keep performance in mind. It's extremely unlikely we would implement a system for mods to use that will negatively impact the entire base/space-age game performance when not used by mods.

The more variability the system allows the more memory indirection happens every time anything needs to use any of these values and the worse performance gets.

[curiosity]

Any potential changes always have to keep performance in mind. It's extremely unlikely we would implement a system for mods to use that will negatively impact the entire base/space-age game performance when not used by mods.

The more variability the system allows the more memory indirection happens every time anything needs to use any of these values and the worse performance gets.

Seems to me like the current system would have more indirection than a "prototype per quality" one. There you'd already have properties free to be read whereas currently you have to calculate them from quality.

[Rseding91]

Seems to me like the current system would have more indirection than a "prototype per quality" one. There you'd already have properties free to be read whereas currently you have to calculate them from quality.

I'm not understanding what you're referring to

[curiosity]

I'm not understanding what you're referring to

The idea behind the big write-up above.

[Rseding91]

I'm not understanding what you're referring to

The idea behind the big write-up above.

Quality was *specifically* not implemented as a bunch of prototype copies because that approach is messy and error prone for the rest of the game logic.

[CyberWizard2261]

I'm not sure if UberWaffe's idea was well understood, what we do want is a different item for each quality so we can freely specify all of its properties, each item will be able to place its entities, equipment, etc, and everything could be customized at will the main difference from the old system would be that a single recipe can make different items if quality modules are used
Of course, if a recipe can use quality we would need to specify an item for each quality level but the system would offer unrivaled versatility

[MaxAstro]

The ideal, to my mind, would be a hybrid system: Quality being programmatically generated by default, but having the option to specifically define a prototype to be a higher quality version of another prototype. "is_quality_of :: LuaEntityPrototype, LuaQualityPrototype" or something like that.

And then have things check if a defined prototype exists and fall back to automatic calculation if not.

[zanven]

Any potential changes always have to keep performance in mind. It's extremely unlikely we would implement a system for mods to use that will negatively impact the entire base/space-age game performance when not used by mods.

The more variability the system allows the more memory indirection happens every time anything needs to use any of these values and the worse performance gets.

if every statistic ( that made sense ) on a prototype was instead a tuple of 2 numbers, the first being the value and the second being the "quality modifier" would this avoid the perf issues outside of more memory consumption per prototype, you would always get the same serialization for a prototype, memory read for calculation would be sequential, you could be fancy with reading both numbers at once from memory to calculate the final value with less indirection.

[cackling.fiend]

I don't like the idea of quality using separate prototypes with `next_upgrade`. But I too was disappointed by how restricted the possibilities are. I hoped for something like a property table called `quality_effects` with a selection of things that can be configured and parametrized by mods. So that you can not only define which effects are active on an entity but also how strong the benefit of quality is per effect. So I could create for example a medium mining drill with resource drain going from 90 to 60% with quality. Or let the pollution or base productivity scale with quality.

[CyberWizard2261]

if every statistic had 2 values or a "quality_effects" table were introduced the whole prototype system would have to be rewritten if we use different itens for each quality only minor changes would be required
If you wanna change only a few properties of an item/entity/equip/etc you can easily copy the item you want to change with table. deepcopy change the name and the few properties you wanna different that's all

[The_Mormegil]

I guess I'll add my idea to this thread as well, given that it is somewhat related.

Quality is hardcoded and we don't want to mess with the base game. Fine. I might have a workaround, depending on how exactly it is implemented.

Given that we can modify quality's "level" and that affects how much of a boost things get, I am assuming that at some point in their code these entities have a "* level" or something equivalent that reads from the quality table for the object's quality. My proposal is to split that "level" to one entry per effect category.

For example: instead of

"rare" = {... level = 2}

We get

"rare" = {... crafting-speed-level = 2, spoil-time-level = 2,...}

For the base game what changes is that each individual method reading quality's level needs to be redirected to a specific kind of level. You add a few integers to a few tables and you'd need to clean up god knows how many methods, which sucks, but it also doesn't sound completely unreasonable.

What happens for us modders is that we get to individually affect each of the possible quality bonuses individually. Bonus points if fractional levels can be supported (even with some rounding) so that we can, say, set crafting-speed-level of uncommon to 3.3333333333 and have uncommon machines that have double speed.