Immersiveengineering: Controlled conveyors

[elhedran]

This is an idea for two new blocks.

The first is a controlled conveyor (conveyor + redstone) which runs unless it gets a red-stone signal. These are connected such that any connected conveyor that feeds to this conveyor also gets the red-stone signal (and also stops)

The second is a comparator scaffold (scaffold + comparator) which emits a redstone signal if an inventory to the side (not above) has contents.

This would allow making 'run on demand' factories so that items are only produced when the inventory they feed into is empty. Can be more advanced by using a normal comparator to only stop the end conveyor when the amount reaches a preset threshold (e.g. silo half full).

[elhedran]

If a factory thing (say assembler) takes more than one kind of input the signal needs to be attached from a buffer block on the output, and the signal run manually around.

[BluSunrize]

Well normal comparators already do that. What's the point of wrapping them in a scaffold?

And conveyors already shut off when supplied with a signal. The signal doesn't propagate because that's not very easy or fun to code.

[elhedran]

I take it if you got a push request the conveyor behaviour that it would be a "maybe"? I.e. Someone else did the not fun not easy code?

[BluSunrize]

Nah, probably still not, because redstone propagation is already horrible code within MC itself.

I don't see the use case, either. If one conveyor is off the ones that follow it don't need to be because items never get there anyway.

[Eufranio]

The use of comparators inside scaffoldings would (maybe?) be place stuff like wire relays/connectors that can only be placed in full solid blocks, we can't place wire connectors above an comparator atm.

If that's the case, I agree with this idea.

[elhedran]

I guess the problem I was trying to solve was this one (A and B are machines, = conveyors)

A===B

If B fills up, the last = stops putting items into it, but is still running, meaning A still empties out. Currently as I understand it I now need to involve a bunch of external redstone to make A stop. However if instead;

AB

B fills up and stops accepting items from A, A fills up and stops. So aiming for that behavior, when its A===B. So lets forget I mentioned redstone for a while. how about;

• if a conveyor can't feed into the next block, it's not active even if no redstone signal
• if a conveyor is feeding to an inactive conveyor, it is also inactive (block -> facing is conveyor type and block -> facing is inactive)
• if ia splitter is feeding to an inactive conveyor it favors the active conveyor. If it feeds to two inactive conveyors it is inactive
• not sure how an item sorter is affected. Probably same behavior as if it was feeding into a blocked inventory?

The goal is to have a factory with multiple machines stop when the end one stops. Conveyors break this at the moment because they will keep pulling from the middle machines even when the end one is full.

Can't be implemented trivially by calling isActive on the next block in the current block isActive if the conveyors loop;

   ===
   = =
   ===

So a trivial 'check at facing' is obviously not sufficient. More likely the conveyors would have to check the active states of the next ones at some defined point (feeding item into them, tick, etc) and remember that for their own 'isActive' rather than calling the isActive call of the other block in their own isActive call.

Hopefully this is a better suggestion than the original one I made

[BluSunrize]

Well you described the biggest issue in all of that, how to detect the inactivity of the following conveyors.
That could chain endlessly which would be a nightmare to performance.

So depending on your machinery, you can still accomplish your goal though. Comparator on a crate/hopper/whathaveyou at the target machine. From there, run redstone wires to the controlpanels of the inputting machines (if they're not IE machines, there's probably a similar way to disable them).
Since RS wires don't lose strength and can be colour coordinated, (and probably perform better than a chain of redstone) that should disable the machines when their target output is full.

[elhedran]

Same question as before then.

If someone else did the pull request in a way that performance was sweet and didn't chain endlessly, would you consider it? e.g. if current conveyors or a modified conveyer could stop in a run based on whether the end of the run could output anywhere (targeted inventory not full or running out into a drop) - would that be something you accept in the mod?

If you are interested my plan would be to look at RS cables and networks. I think if you defined the output conveyor as the trunk of a tree and things that feed into it as branches then that could form a shared state. The tree would only update on block breaks or placements so should avoid the chaining issue, at least when not breaking or placing conveyors.

[elhedran]

PS. yes, I've used refined storage to solve this issue in my server already - but I REALLY like Immersive Engineering and would like to solve it with just the single mod.

[BluSunrize]

If it's doable in a very clean and performant fashion, maybe. No guarantees though.
I forsee this being tricky given the externalized, abstract implementation style of Conveyors, but by all means, try it.

[elhedran]

Dropping it anyway as it doesn't solve the problem.

if an acceptor (like a assembler) takes more than one input type this can still lead to starvation as it can only turn all inputs off, not as per required.

And for single items types can just put a hopper, comparator, and existing redstone wiring.

Recommend closing this ticket

[Bihlbo]

Seems like there's a simpler way to handle this. Make a tool that marries conveyors together. You have one master conveyor, and every other conveyor you click on with the tool becomes a slave conveyor. When the master gets a signal, the slaves also obey. This way there's no checking anything on the fly, no additional redstone required, etc.

If I were making this thing, I'd add 2 items: Conveyor Master Panel (CMP), and Conveyor Configurator. The CMP is something you attach to the side of a conveyor, making it easy to see which conveyor is the Master, and where the redstone signal is accepted. Actually, I'd probably code it as the CMP is the master and the conveyor on which you place the CMP is the first Slave, but functionally that's the same thing. Use the Conveyor Configurator on the CMP, then at the cost of some energy use it on other conveyors to mark them as its Slaves. You probably want to limit the distance to something like 12 conveyors, and if it's easy enough to do, make sure that all of the Slaves are adjacent (connected) to others owned by the Master.

The end result would be something similar to what you'd get out of the signal strength of one lever powering a line of redstone that feeds repeaters that control the conveyors, but without all the extra and ugly real estate. That's seriously ugly, and not welcome in my factory.