Request: specify non-recursive recipe prototype

[Deadlock989]

Request: recently we got the allow_as_intermediate flag for recipe prototypes, which was massively useful, preventing some kinds of circular recipes.

What I need at the moment is similar, almost the same thing but the other way around. I want to set a flag in a recipe prototype which stops the player recursively searching for intermediates. Sort of like allow_as_intermediate but for this recipe only, not for the recipe as an intermediate step in other recipes. Suggested field name: "disallow_intermediates".

Use case: a recipe turns a wooden chest back into wood. At the moment, the only way to have this kind of thing is to make sure that only machines can craft that recipe, because machines have to have just one recipe set and must be supplied with exactly the items they need. If you allowed the player to have access to that crafting category, and they didn't have any wooden chests in their inventory but they did have wood, then they'd automatically craft a wooden chest out of wood to get the chest, and then craft the chest back into wood.

allow_as_intermediate isn't helpful here because if I set it on the wood recipe, it would stop all recipes everywhere from being able to use wood as an intermediate. I want to be able to say: don't search for intermediates when hand-crafting this recipe, only the exact items it requires.

[Rseding91]

Can you give me an example mod that shows the problem and how it should work for crafting different recipes?

[Deadlock989]

OK ... see attached ... it almost couldn't be simpler.

Start a new game. You'll be given 100 wood planks. Look at your logistics tab. You'll see there's a recipe to disassemble wooden crates. Except you don't have any wooden crates. But you do have wood, so clicking on the recipe results in you assembling a crate out of wood and then disassembling that crate to get the wood back. Crates are 4 planks so you see the option to make 25 crates or disassemble 25 crates because you craft the crates to disassemble them.



allow_as_intermediate fixes the exact reverse of this situation. In this situation, I want to be able to flag this recipe so that it's greyed out if you don't have precisely the ingredients required, i.e. you will not craft any products needed to fulfil the recipe. allow_as_intermediate says "Don't ever use this recipe to fulfil other recipes". I want to say, "Don't use any intermediate recipes for this recipe".

I could get the desired effect by setting allow_as_intermediate = false on the wood, but that would prevent players from ever having wood crafted in their auto-queue for every other product, ever again.

Obviously this is for disassembly/recycling type situations. I have a half-finished big mod going where the recipes are more complex and involve a probability of loss but it's exactly the same situation.

[Rseding91]

Ok, so it sounds to me if the "don't use intermediates" is enabled then "allow as intermediate" should be forced false?

[Deadlock989]

Yes, that sounds right. I hadn't thought of that but it would have to be, to stop it being considered as way of getting components out of things. I realise there's potential for confusion there. But also the intention is to use this with recipes that have probabilities - so they couldn't go into the auto-queue anyway because there's no guarantee they will produce enough. I guess this doesn't factor in for the base game where there is only one probability recipe and it isn't hand-craftable.

e.g. you have a wooden chest in your inventory and the "disassemble chest" recipe available. You don't want to automatically have chests disassembled in order to make, say, small electric poles.

[Deadlock989]

Has this been implemented?? That's brilliant. Thanks for listening.

[Deadlock989]

Rseding: again, thanks so much for implementing this. It works exactly as intended and it was about 15 seconds of work for me to enable it in my system. Really pleased.

[<NO_NAME>]

Ok, so it sounds to me if the "don't use intermediates" is enabled then "allow as intermediate" should be forced false?

I don't think that this restriction is necessary. I can imagine a recipe that should not auto-craft its ingredients but still can be used by other recipes. There is no contradiction here.

[Deadlock989]

I don't think that this restriction is necessary. I can imagine a recipe that should not auto-craft its ingredients but still can be used by other recipes. There is no contradiction here.

For example? I can't think of any.

In the recycling scenario I described it's absolutely required. If a recycling recipe turns something back into raw components, it should never be considered by normal recipes as a way of getting those components. Otherwise the auto-crafting would start pulling assemblers in your inventory apart to make pumpjacks, etc. Furthermore, it's even worse if the recipes are probabilistic. Really any probabilistic recipe should assume allow_as_intermediate to be false, because you can't guarantee you'll actually get the things you wanted. I suppose the responsibility could be on the modder to make these calls, but without a use-case it's hard to see why (and you won't get much out of devs without a good use case).

[<NO_NAME>]

OK, there is one (pretty weak) use case. In my mod there is recipe that should not allow intermediates but there is no reason for it to have explicitly set flag that it can't be used as immediate. That's because it doesn't produce anything.
Removing that requirement would spare me that few minutes of figuring out what is wrong, etc.
However, the fact that I can't think of any better reason doesn't mean that the reason doesn't exist.

My point is that there should not be that kind of restrictions in the first place unless there is a reason for that. AFAIK, there isn't any in this case. The game won't crash if someone set use-intermediates to false but leave use-as-intermediate at default value.
There may be some people that would figure out how to use that configuration.

[Deadlock989]

So, there's no good use for it that you can think of.

Whereas the use case I proposed, which led to the creation of the feature, has good reasons for it.

Seems fairly straightforward to me.