Jump to content

Mod Request BiDirectional Pipe Segments


Recommended Posts

Ok, what the purpose and what do I mean by this.

Here is the problem and I do believe it's pretty common. Let's assume we have some sort of operation storage of liquid/gas and the main storage tanks, let's call reserves or deposit. So what I'd like to implement is to make this storages bind with a single pipe that could work on transfering the substance in particular direction. One or another - up to user. From or to, but never both simultaneously. But there is allways a certain direction in what the substance should move. But this certain direction must be changable via automatic. There are some active examples where this pattern is in use.

1) Energy facility with it's own small operative storage and some kind of big underground storage capable to store tone of natural gas produced by geiser eruption cycle

2) Cerosine storage again one on energy facility and another one somewhere near the rocket bay (that may be required to pump up to rocket or back to power plants)

3) Electrolyse facility with it's own breathable oxygen tanks and rocket bay oxygen tanks

All these examples reproduces the same pattern: we want two distant storages (both with input and output interface) to be connected with a single pipe. And this pipe should somehow manage the flow one way or another but it's allways a certain direction (but automatically adjusted). And they all fails because the pipes doesn't work correctly where there are both multiple producers and multiple consumers in the network

I tried to achieve this with blockators. So once you need the substance on one particular end you lock it's output and enable input and vice versa. But all of a sudden this doesn't work at all. Both ends of the magistrale do has it's input and output (to let substance enter or go away). So the flow is stuck. Game obviously tells you I do not know what direction of flow do you mean. And no matter your blockators are turned on or off on particular tail of the scheme, it's still considered an output in the scheme and considered. Unless it's wrong. Very frustrating that this sort of things is not doable, not feasible. I tried different ways but I couldn't find the way to trick or bypass it. The only possible way is to construct and deconstruct pipe segment when direction should be chagned. Or. Build another magistrale. One for upload the substance and reversve one for download. That's really stupid. Why liquid can't simply flow desirable direction and share the same pipe? I would like not to buid this excessive pipes. Especially taking into account I'd like to not destroy a lot of initial asteroid landscapes and prevent it from destroying too much of a let's say nature 

So I realised this doesn't work the way it should. This is where my proposition comes in.
What is supposed to do. I see three possible ways of achieving this:

Option A. The very simple and seems the most obvious: do not consider disabled blockatos as an active output. And rebuild plumbing scheme when signal on blockators changed. This is so obvious solution that you may even not read everything below this. This is a perfect small and reliable keypoint solution. This will allow users to switch pipe direction by simple activating or deactivating blockators. This is the best approach imho and kills the problem in a very light and elegant manner

Option B. Other way to resolve this more complicated one to implement, but more flexible. new structure: valve. This "valve" should regulate what the desirable direction flow should have beneath it. It should act as a bridge but with non constant input and output but switchable. Like we can assign the direction for washing basin. Probably it may be triggered manually of with automatic. And of course if input and output changes - it should refresh plumbing scheme to take into account changes. Such a structure should allow to proxy plumbing subnetwork with a single input or output interface behind which the flow will be redistributed according to it's (subnetwork) needs.

Option C. Third way is to my mind is the most complicated. Currently game as far as I can understand finds all pathes between all consumers and all producers in the network. But algorithm of the game serves only shortest relative to every consumer. So current algorithm is not perfect and may be improved. From this:

 - Take the consumer, find closest producer, build path, serve it

To this:

- Take the consumer, if it is active find all pathes to every active producer available in the network, serve them All. Splitting or normalizing consumed amount among all of them proportionally

This new algorithm will work better since if will not cut off distant producers from providing it's materials if relatively nearer less distant producer (for example disabled, aha) is available.

So third way seems to me unrealistic, beyound capabilities. But two previous - are good enough and fixes the problem.

So what do you think of this? I really think this feature deserves attention. Thanks in advance for reading up to this

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.

×
  • Create New...