Applied Energistics 2

Applied Energistics 2

137M Downloads

True Blocking Mode™️

Technici4n opened this issue · 6 comments

commented

Describe the feature

Implement blocking mode by tracking the status of the current crafting job, instead of just checking if items can be extracted from the target.

Reasons why it should be considered

Blocking mode doesn't work for most modern machines. Additionally, the current behavior is not very intuitive for players. It would be better to actually track the status of the current job.

Additional details

I'd suggest giving each pushed crafting task a unique id, and keeping a list of currently active ids in a WorldSavedData to ensure that pattern providers properly unblock even if their CPU is not available anymore. We should also have a visual indication that the provider is currently blocked, and a button to unblock it if it is, both in case the player makes a mistake, and in case we forget to mark a task id as unblocked in the first iteration of the feature. :P

commented

Good points, thanks for your comment. I think the following would work:
If the pattern is already in use when a second instance of it is pushed (could be multiple sides of the same provider or multiple providers), then both have to be complete to unblock the providers.

I'm not sure what to do about one pattern provider in blocking mode and another with blocking mode disabled though, but I guess this case doesn't matter too much.

commented

I don't think this will work right because it assumes the returns come in the same order of pushing the ingredients out.

Without respecting it per machine-side (which needs cooperation from the mod that provides the machine), I can only see it working when the pattern provider requires the results to be piped back into itself in blocking mode to actually unblock.

commented

Interesting take, looks a bit different from the ones suggested previously.
i think the description given of the implementation would work as-is for a unique pattern using one side of a pattern provider
but:
1)one pattern provider, multiple machines
will a blocked side only unblock after receiving an result from the same side?
2)multiple pattern providing an same pattern
b)which pattern provider would get unblocked if the result of a craft came from an item interface?

commented

I dont know how far you are willing to go for some kind of blocking mode, without exposing 30 different options for the user. The furthest i got to a blocking mode i liked was blocking the side on the presence of any ingredient specified on the encoded patterns. But add another interface and it may not work properly anymore. Or if a machine consumes the ingredients on recipe start ( like gregtech )

Maybe in those cases a "Blocking group" could be configured, so ingredients of the patterns of these other interfaces could be checked against.
Im not sure how expensive can these checks get.

commented

So I was indeed thinking that we will have to stick to a "local" approach to avoid the aforementioned issues. I do really like your suggestion of "blocking the side on the presence of any ingredient specified on the encoded patterns", let me try doing that instead. 😄

A note about GT machines (and I'm particularly interested in that because machines from my mod Modern Industrialization work similarly :P): once the input has been consumed, it's fine if we push one set of items.

commented

We could in theory allow configuration of some subset of it via tags or config file mod patterns defined on the block-id of the adjacent BE