[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.