One person suggested making a ItemProductPrototype::ignored_by_quality member that is an integer, and would mean that specific product could produce both the same quality and a different quality in one cycle of the recipe.

Seems unnecessary to me. It only concerns the products and you can have ...

I'm not sure what you mean by a byproduct in this context.

The reason I suggested pushing all "different quality" items into these slots was to give uniform behavior - the player knows that if a recipe normally produces a product B at quality X, but some effect/probability means it is produced ...

That problem, of needing output slots for each quality, was why I suggested breaking machine outputs into two sets of output slots - same & different quality outputs. Same for outputs of the corresponding advertised quality, different for outputs that aren't. So you don't need slots for each ...

2. It appears exactly the same externally - and even then, the recipe could just have "extra outputs" which are generated during the prototype stage, instead of needing to use a "dump inventory" as you say that changing the recipe does.


I can see two reasons why it doesn't create more ...

This is reasonable. It gives the most control to modders, albeit without any higher-level API (e.g. queueing).
But it's better to have low-level control than a high-level API that is inevitably limited, as modders can construct the high-level API from the low-level features.
And someone will likely ...

I'm wondering if you could take it a step further, and always have outputs that are of a different quality (relative to the "expected" quality) go into special "different quality" slots. So even in the base game, if a recipe's output is bumped up a quality, it will go into the special ...

Proposed solution of "ignored_by_quality" being an integer has a fundamental flaw that makes it impossible to add: if a recipe would finish, due to value of this field it coukd happen that X items of better quality and Y items of original quality would be given but they would have to be both ...

protocol_1903 wrote: Sun Nov 09, 2025 12:18 am To be honest a lot of this sounds like breaking changes, i dont see any of it happening before 2.1 (although i love to be proven wrong)

That was actually why I brought it up now - the devs have outright said they're working towards 2.1 now.

I imagine it would be one global network for each type of connection category, then each entity connects to every network that it is compatible with.


That would be preferable. I just hope that wouldn't be too much work for the devs - I'd rather just have connection masks for non-global surfaces ...

How about allowing modders to define custom "playlists" in the prototype stage (procedural music systems, like planets already have), and then at runtime, they can set which playlist to play?


As an inexperienced modder, it doesn't appear clear to me right away how to avoid conflict if a mod ...

This would determine which other heat pipes/power poles a given heat pipe/power pole could connect to.
Would work the same as fluidboxes's connection filters.
Machines would also have a power_connection_mask that determines which power poles they can receive power from.

This would allow for heat ...

i know this isnt a bonus or multiplier, but being able to turn off quality on a prototype completely would be a massive help - as due to some runtime scripting stuff, getting quality on some of my mods buildings actually makes them worse :lol:


I am afraid i do not want to be doing that ...

How about allowing modders to define custom "playlists" in the prototype stage (procedural music systems, like planets already have), and then at runtime, they can set which playlist to play?
Something like:
start_playlist(playlist=<playlist_name|default|nil>, where=<global|surface|surface_list ...

Because i do not want to allow other qualities to be specified. I was already attempting that and it always creates issues near crafting queue which is unable to handle quality. I would have to add a lot of safeguards such recipes never appear in the crafting queue, not even indirectly through ...

+1 Both a minimum and maximum per-machine level for each machine. Something like:

consumption_limits = {min_percent=20, max_percent=nil}
quality_limits = {min_percent=0, max_percent=20}

Where if min_percent / max_percent are nil , they default to w/e the effect's default limits are.
If a limit ...

In other words, the main use for it is as an alternative for researching certain technologies that exactly match it. So it's exactly equivalent to running a lab w/ the exact same science packs, except it can't research techs that take a subset of those packs?

Kind of a pity it's getting removed - I ...

I thought there were some modded planets that had custom multipliers, so I thought I was just missing the way to set it. Ideally, it's something you could set at runtime, so you could have a dynamic energy multiplier for certain planets.

The syntax error is because it's not a valid lua identifier, so it has to be used as a string, like ["robot-energy-multiplier"] = 2.
Doing is the same as doing But the former is only valid if "key" is a valid variable name.

I have looked through the data- and control-stage docs, and I can't find any kind of surface-property or SpaceLocation member that determines the multiplier for robot energy usage. I even looked through the data.raw, and didn't find anything like this in Aquilo's defintion

I searched for things ...

+1

Communicating this to the player unambiguously might be tricky - if you just say it reduces drain by 10%, they might think 10 levels == 0 drain. You could say it increases lifetime yield by 10%, but that makes it sound just like productivity.

Maybe say it depletes the ore patch 10% slower? So ...