Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow setting a "production step" so that automatic trims/fixes produce shorter (nicer) numbers #294

Open
immerrr opened this issue Dec 16, 2024 · 1 comment
Labels
awaiting feedback Issues awaiting feedback or more info

Comments

@immerrr
Copy link
Contributor

immerrr commented Dec 16, 2024

Usually, one wants their producers to be balanced exactly, otherwise those extra digits after floating point will create blockages at some point. But, when storages/sinks come to the picture, this is no longer an issue, and "allocated surplus/sink" configuration for a given part implies that the extra that doesn't fit in the storage will end up in a sink eventually.

This opens a possibility for setting up a "round up to the nearest Y items/min" or "round up to the nearest X% clock speed" for those parts. For example, if a part has 3.1234/min downstream requirement and 5/min "allocated surplus" (see my suggestion in #46), instead of hunting the decimal digits across the factories, both in the app, and in-game, one may set their production output to 9/min, since there is really not much difference between stocking up/sinking items at the rate of 5/min and 5.8766/min. This will not only help with the production line in question, but may reduce the overhead of tweaking the upstream ingredient production, which may be liquid/gas and not as easy to sink.

@github-actions github-actions bot added the Needs Triage Issues awaiting assignment of priority and classification label Dec 16, 2024
@Maelstromeous
Copy link
Member

@immerrr To illustrate this better, could you provide a scenario?

Ideally, could you provide a share link with a simple setup of what you're meaning, with the values that currently show versus what should be shown? I understand sort of what you're getting to, to have it round to a certain amount, but the visualisation of that would be rather tricky and some people may want the exact-ness for specific reasons.

The visualisation of "x.xxx amount sunk" is likely going to be part of the solution within #46, and all of the trim / fix production buttons taking this into account.

@Maelstromeous Maelstromeous added awaiting feedback Issues awaiting feedback or more info and removed Needs Triage Issues awaiting assignment of priority and classification labels Dec 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting feedback Issues awaiting feedback or more info
Projects
None yet
Development

No branches or pull requests

2 participants