[Feature request] Accounting for Somersloops with best-recipe selection

[paolocrippa87]

It would be helpful to have the engine select the best recipe (i.e., the most resource-efficient) also taking into account the use of Somersloops.

E.g., if somersloops are not used, the best recipe is the base one.
…but when somersloops are used, the best one becomes Steel Screw.

Moreover, without Somersloops, you make Screws with the classic route, because you use Steel Rods from Pure Iron Ingots + Solid Steel Ingots.
With Somersloops, you make Steel Screws with a completely different route, because you use Aluminum Beams (yet from the classic Sloppy Alumina + Electrode Aluminum Scraps + Pure Aluminum Ingots).

Even if it were not possible to include this feature in the main engine (if I have correctly understood from another post—https://github.com/greeny/SatisfactoryTools/issues/171—that would not be easyh), could we have it as a stand-alone feature?

Thank you in advance.
Paolo

[greeny]

The problem is that the current solver doesn't have capability of solving for integer variables, so it's practically impossible to add sloops to it. New Tools I'm working on may have this capability if I'll be able to make it work, but it's not feasible to add it to current Tools.

[paolocrippa87]

Thank you very much for your prompt reply.

I am not willing to take your job—you are far a better programmer than me ;)—but wouldn't it be easy if you just had two sets of recepies: one with the base outputs, and one with doubled (i.e., Somerslooped) outputs.
For each item, you get the engine check this second set of recipes as well, as if they were just new alternate ones.

I mean, I have an Excel model that is able to replicate the whole best-recipe selection process (based on the resource-scarcity approach) and gives me the same results as yours; to have it work with Somersloops, I have just made another set of recipes, with doubled outputs.

Am I missing something? (Probably yes.)

[greeny]

The only problem with that approach is limiting number of sloops. Assuming infinite sloops, your solution would obviously work (but also, all the recipes will be slooped). But once you introduce limitation and expect the solver to pick places where the sloops make most impact, it breaks down due to the above mentioned lack of integer solving. The solver could very easily decide to put 0.4 sloop in one machine and 0.6 sloop to other machine and say "I've managed to fit into limit of 1 sloop", but result is two slooped machines.

[greeny]

(Also, there's nothing like "best recipe selection", the whole thing is solved as a linear solver model)

[paolocrippa87]

You are perfectly right—In fact, you caught me red-handed: in my megafactory, I am just using unlimited Sloops, so I just have no need to account for their scarcity.
If you have to take that into consideration, I get that it is something far more complicated.

Still, would you consider adding that as a proof-of-work solution? (i.e., assuming infinite sloops, that would be the best theoretical recipe/route to get that item.)

[greeny]

I don't really see a use of that, since "assuming infinite sloops" would just mean "everything is slooped". I don't think it would change much in terms of different recipe choices, since if every step doubles output, everything is twice as "good", hence nothing changed at all.

[paolocrippa87]

Well, not really—it might actually change, since you are just doubling outputs, but neither inputs nor resource limits (i.e., resource nodes on the map stay the same), and different receipes take advantage from this in a different (i.e., non linear/uniform) manner.

I agree with yout that recipes with the same basic inputs—i.e., the standard ones for ores smelting, or even the pure ones (since they use Water, which is virtually unlimited, thus counts as a free-input)—mearly scale linearly/ uniformly: with sloops, the cost of making that one item is simply the half.
The same goes with more down-the-line items which still share the same best-recipe route: their cost is halved times their intermediate production steps.

But with mixed recipes it might actually change, since their scaling is neither linear nor uniform. Take for example Concrete:

• without sloops, Wet Concrete is the best recipe (as with generally any Pure-like receipe, since it increases the production at a nearly-zero cost, just needing Water);
• with sloops, the best recipe seems Rubber Concrete (because using those 20 pieces of Rubber that you trade for 20 less Limestones to get 10×2 = 20 more Concrete has now become convenient: in other terms, without slooping, using 20 pieces of Rubber instead of 20 of Limestome to get just 10 extra Concrete was a bad deal; but with slooping, using the same 20 pieces of Rubber to get 20 extra Concrete is now a good deal.
  And that is because Limestone has kept the same value—since the nodes on the map are the same—but Rubber is now much more convenient to produce, to the extent that it has become cheaper than Limestone, thanks to the fact that in a multi-stage production chaing the effect of the sloops is somehow multiplied at each stage. This non-linearity in the scaling of the effect—0 on basic resources, ~2× on each stage for intermediate items—is the key of this misalignment and eventually in the change of some best-recipe selections).

As I have written, it seems to me that Rubber Concrete is the most convenient one (the math checks, and I get the logic); still I would like to have a double check, because—as you have seen—the fact that the best-recipe selection might change is a bit counterintuitive.

I have made some calculations, and roughly speaking ~20% of the items change as for their best-recipe route.

In terms of utility, a tool like this (i.e., one that account fors unlimited sloops) would still be useful for small factories/ production chains (of course not for megafactories, for which the 106 sloops cap is reached almost immediately).

[greeny]

While that is a valid point, it's still something I don't want to "waste" my time on - I'm focusing on new Tools and current Tools are basically "abandoned" (not really, but since they are planned to be replaced, I don't want to spend extra time on it).

Technically one could make their own dataset and host own API with the slooped recipes, I could provide some help if needed (as readme is VERY outdated). But again, I don't really want to waste dev time on it.

[paolocrippa87]

I get it. Thanks for your patience though. Best