Recursive Resource Calculator

by Herddex

An in-game calculator that can be used to automatically compute the information you need to build a final product at a given rate of production: precise number of machines for each intermediate product, required production rates for all said intermediate products, pollution and energy costs, with options for specifying module configurations, as well as machine types.

Utilities
2 years ago
1.1
5.19K

i [IMPLEMENTED] GUI idea for better reading

2 years ago

Hi, nice mod! Would be cool to be able to toggle the production stats and have production and end product measure units both on [/m] or [/s] on the GUI, otherwise it gets a little confusing. Also, the numbers shown may have too many digits for humans, consider displaying just up to 3 float digits ;)

2 years ago

Hello and thanks for your suggestion. What exactly do you mean by "toggling the production stats"?

About the /m and /s, I might implement that if it doesn't prove too difficult. It is something I thought about in the past too, but ended up abandoning. I'll look into it.
And you have a point about the decimals. If I can limit them to 3 digits (or even a user-picked setting), I definitely will.

2 years ago

I was just referring to the option to visualize product/production in /m, /s

2 years ago
(updated 2 years ago)

The displayed numbers now use a fixed decimal precision of 3 by default, but can be set between 1 and 6 inclusive, via a runtime-per-user setting.

But after some thinking, I am not convinced anything needs to be done about the /m and /s measurements. For the reported numbers, I think it's better for them to be measured per second because:
1) In the case of raw resources, it's easier to compute how many miners / pumpjacks you need, since their mining / extraction rates are also measured per second.
2) It's easier to figure out when you need red/blue belts for a certain item or when yellow belts are just fine, since their transport speeds are also measured per second. A similar argument can be made for the different types of inserters.

And I think the user specified final product rate should me measured per minute because it can save the user from having to input ugly decimal values (for example, you might want to produce 1 Productivity Module 3 every minute; it's easier to write 1/m, then 0.0166666/s in that case)

Can you think of any good reasons why anyone would want to choose differently? And if I were to implement the feature, should it be changeable dynamically trough the GUI or would runtime-per-user settings (separate ones for displayed numbers and input production rate) be just fine?

2 years ago

Hi, thanks for the update! I think you did a really good job! :) I agree that '/m' and '/s' measures are fit to final product and intermediates needed, but it might be useful to change the units on the fly (eg. I have 90 SPM of one kind that requires blu chips, I can open a new thread to see what the subfactory for 107/s blue chips needs). But again, just a suggestion cuz that option has been really useful in Factory Planner.

Also, for the GUI, it might be a cool idea to add a close button on the window and maybe a shortcut button to open/close the GUI too :)

2 years ago
(updated 2 years ago)

Thanks. If I understand your example correctly, you could just multiply 107 by 60 and get what you want... But that is indeed not a trivial calculation. And even if you were to start a new sheet to see what you would need for 107 * 60 blue chips per minute, you'd be adding that calculation to the calculator twice, thus skewing the Totals section results.

I suppose the easiest fix (other then allowing the final product to be specified in both /s and /m to fix the first issue) would be to just add an in-sheet option that would opt out that sheet from the Totals accounting, thus allowing separate 'sub sheets' for sub factories' Though, you'd still need to create and enter the target product yourself this way. Unfortunately, a proper sub factory results report (that you could see just by pressing a button in the main report) would be quite a lot to implement. :P

It's true I built the mod with only unified factory designs in mind (where each single product would be produced in one place only for the entire factory). But I am aware that's not the only viable playstyle and that sometimes you might want to build entire separate sub factories for a given final product. In that case, does the Totals section even provide meaningful value to the player anymore?...

TL;DR I think I get what you mean. That is a valid reason for being able to choose between /m and /s measurements. I'll think about implementing it directly in the GUI then, as part of each individual sheet. And I'll think about the "opt this sheet out of Totals accounting" feature too.

2 years ago
(updated 2 years ago)

And regarding your second paragraph, I've shied away from more advanced GUI styling because the data stage styling documentation is kind of shit. :P So I've just stuck to the limited capabilities that runtime styling brings (which is well documented on the Lua API, at least). And I am not quite sure what you mean by the shortcut button. Do you mean one of the buttons in that section to the right of the quick bar? If so, the idea has some merit...

2 years ago

Yup, just a button on the right of the quickbar (like alt-mode or toggle exocheletron/roboports...). And dont worry, I know GUI docs are not clear at all! But I think you've done a really good job! :)

2 years ago
(updated 2 years ago)

I thought about changing the "/m" label to a dropdown menu between "/m" and "/s". The trouble is that the way I have designed the mod, it would be quite complicated to do this change in the latest version while also maintaining backwards updatability from previous versions without losing player data. Essentially, either the player would have to reenter some of the data (only the final products and the production rates; module, recipe and crafting machine configurations should be safe) or I would need to be really careful with migrating the calculator from any previous version to any newer version so that the migration doesn't cause a crash and doesn't corrupt/lose any of the player's data. And because of some questionable design choices, I find the second option quite difficult to implement right now.

I've had an idea about writing a modular version mechanism. A script that contains methods that will update the mod from any previous version to the current version, step by step. This does have the potential of future proofing against problematic changes in the future. But putting it into place isn't exactly an easy task either.

2 years ago

Update: I ended up implementing the modular version updating mechanism. It wasn't that hard to implement after all. I just had to think about it for a bit.

The /m, /s drop-down feature is now part of the latest update.

2 years ago
(updated 2 years ago)

You might want to take a look at this: https://kirkmcdonald.github.io/
It's pretty similar to your mod, only as an online calculator. I used this a lot back in the day and it has a lot of options I would love to see as an ingame tool. Especially, if it works with modded recipes from Space Exploration, Krastorio and the like.

I love the option to choose the precision of the results for example. So, no 1.4326485 which is entirely unnecessary for what I'am doing. 1.4 oder 1.43 is waaay more readable.

2 years ago
(updated 2 years ago)

The online calculator works only for vanilla, but it can handle the one complex recipe system vanilla has (oil cracking).
I would like my mod to fully work with any complex recipe system brought by any mod out there, but I just don't know how to automate solving generalized complex recipe systems...

This thread has been locked.