terasology / additionalitempipes Goto Github PK

This doesn't necessarily have to be a literal "block", but more of an "add on". Essentially, this is a switch/lever that can be placed on pipes and when acted upon, disable or enable the item pipe. In this case, disabling and enabling refers to stopping the flow of items from the pipe to the deposit. For example, if a Suction Block sucked in an item and was transporting it through a pipe to a chest, but one of the pipes in the chain had a switch on it that was enabled, the item would stop and not be able to move through the pipe until the switch was enabled again.

The implementation of this concept does not require the integration of any other modules. However, instead of changing the coding of the original pipe to allow this, there is also the option of creating a new type of pipe that is the only kind that can be enabled or disabled. By using this method, players can stop the transportation of items after a certain amount of time and control the pipes however they want to.

This pipe would be attached to the end of a pipe and left open. Currently, when the pipe ends, blocks just fall out. With this pipe on the end, the blocks would shoot out really fast like a cannon. It would be useful for transferring items really fast across large distances. Perhaps if implemented in concert with projectiles, the projectile could be shot out the end of the pipe not as an item, but as a projectile. It could also be used along with suction pipes to launch items long distances and allow them to continue down a different pipes once sucked in.

This pipe will essentially function as the counterpart to the Suction pipe. It will check for adjacent chest / inventory blocks and continuously pull items out of them and insert them into any adjacent pipes. If no adjacent pipes are connected then it will not remove items from the nearby chest. If more than one adjacent pipe is connected then it will distributed the items randomly or evenly between the output pipes.

This pipe shouldn't require any additional modules as it functions as the reverse role of the Suction block from ItemPipes. It may even make sense to include this block as part of ItemPipes rather than AdditionalItemPipes as it is a "basic operation" in pipe mechanics and mirrors the actions of the suction block which is in ItemPipes.

This pipe would be sort of delete everything pipe. It would be an opaque pipe attached at the end of pipe, that would delete everything that goes in. (Is there something like entityRef.delete()? I believe there is)

Do you know that feeling, when you have your inventory full of useless items you want to get rid of, but have no other choice than throwing them around? Or you have some quarry hooked to your pipe system, and nowhere to store all that stone? Well, here goes the solution! Just hook this pipe, which is using our patented black-hole technology, to your network and be good to go! World of no more full chests await!

DISCLAIMER:
We deny any liability for:

• loss of valuable items
• spacetime instabilities
• Gamma ray emitting
• random explosions
• random implosions
• lamma outbreaks
• any other issues that might arise from usage of our product

When I open the in-game terminal and enter give unificator, it says Could not find an item or block matching "unificator". Doing the same with the sorter works.

This teleporting system consists of two blocks - an input block and output block. Items are transported into the input block by a chain of pipes and come out into the pipes connected to an output block. This will make it easier to transport items over large distances and eliminate the need for long, complicated systems of pipes, making everything more organized. Each input and output block has an ID. The input blocks can be named by the player and the output blocks will be associated with numbers (1, 2, 3...). When a player interacts with an input block, a UI opens up in which they can name the block and assign a corresponding output block by typing the number in.

When this pipe is laid down, it plants crops on both sides. Both ends of the pipe must have a chest for the planting process to start. One of the chests must also have seeds in it for the pipe to plant. The other chest will be used to store the crops when they are harvested.

One plants one one side of the pipe will be harvested for their crops when they are fully grown, while the other side will be harvested for their seeds. These seeds will be pushed back along the pipe to the seed chest to start the planting process again.

This pipe will help larger farms be automatic, only needing a player or another system to remove the crops from the chest. The only input needed is the original seeds put in the seed chest by the player. The planting, harvesting and seed collection proceeds on it's own in a recurring cycle.

This block is like a splitter on a hose. There is one pipe that brings input to the block. All of the other sides could be outputs. Each side that has a pipe attached that isn't an input is an output. The block alternates between all of the output pipes, putting the next item from input in each successive pipe. When all of the outputs have gotten an item, it wraps back around to the first output and starts again. Thus, the input is split evenly between all of the output pipes. This pipe has a practical use in splitting items between between workstations or chests.

The Sorting Pipe would let player decide what items would go which way. It would have one input side and up to 5 output sides.

Upon activation, an UI screen would show up used to configure the pipe.

One of these sides should be used to pass items which would not have been defined in the settings of the pipe.

The Sorter would let the player input items to it using a pipe to dispose them into other pipes connected to the sorter.

The Sorter would open an UI screen upon activation, which would contain the configurator and player's inventory display. It would let the player input items into inventory slots which colours would match block sides.

Items could be inserted from all sides. One of the sides would be marked with a checkbox in the UI Screen to mark which side would accept all items not defined in other Sorter's sides. One of the checkboxes (and only one) must be checked.

For example, putting a torch into a red slot would make the Sorter redirect every torch that would come to it to pipe connected to block's red side. Items not marked in any of the sides would go to the side marked with a checkbox.

Items defined in more than one side would be randomly disposed between them.

The block would be not rotatable.

Description

The pipe block will emit a signal of infinite strength for the duration something is inside it, much like the pressure plate in the signalling module.

Dependencies

• Signalling

Proposed Implementation

The segment entry and exit events will be used to detect the presence of something inside the pipe block. This can be done by maintaining a counter of the number of entities inside the pipe; a counter is incremented and decremented every time the entry and exit events are called respectively.

On every update, if the above defined counter is non-zero, there is something inside the pipe block and a signal is emitted.

Possible uses

• As a trigger to call a cart to the loading bay when the pipe contents are nearing the mouth of the pipe
• As a general signal generator equivalent to the Signalling module's pressure plate but for carts

The unificator will be a block that needs to have one output and at least two inputs. To diferenciate the inputs and the outputs, the unificator will open an UI screen where you will select which side of the block will contain the output. The other sides will be the input