Valves, Sliders

[Shurlan]

I find it irritating, that valves have a minimum throughput of 10 g/s.

While allowing arbitrary values might be undesirable due to floating number weirdness, at least give the option to block the flow of liquid/gas.

 

Every time I see the following in a game i think: "Why, just why are you giving me this stupid slider without the ability to put in numbers? I don't want 45,6g/s i simply want 40g/s."

You already display the value: just make it clickable, round the input and clamp it to the allowed range. Making me happy and ONI a better game.

[Masterpintsman]

While a see a point in minimum flow (look at the description of the valves for a hint why) I also think that a numeric input (in g/s) is needed, as adjusting the slider to (at least somewhat near) an intended value isn't fun.

[DuraLex]

I'd like to say that it should accept 0 as a input, making possible to stop the flow, but that would violate the game mechanichs.

[Shurlan]

1 hour ago, Masterpintsman said:

While a see a point in minimum flow (look at the description of the valves for a hint why) I also think that a numeric input (in g/s) is needed, as adjusting the slider to (at least somewhat near) an intended value isn't fun.

I just looked at the tool tip for the valves and still don't understand what you are hinting at. I'd appreciate explaining your thought on that more directly.

All it says, is in regard to pressure and 0 pressure should be perfectly fine. Especially since the vents aren't really vents but pumps that suck everything out of the pipe due to how the conduits are implemented. Otherwise the minimum pipe pressure would be limited by the outside pressure.

1 hour ago, DuraLex said:

I'd like to say that it should accept 0 as a input, making possible to stop the flow, but that would violate the game mechanichs.

I don't think that this change would violate the game mechanics. As far as the system is concerned the valve has a conduit consumer (green side) and a conduit dispenser (white side). As long as a dispenser is connected to a consumer flow in its directing is going to happen.

When setting the valve to 0 g/s the liquid/gas would simply build up on the consumer side, which already happens when you have more flowing in than out.

[Masterpintsman]

53 minutes ago, Shurlan said:

I just looked at the tool tip for the valves and still don't understand what you are hinting at. I'd appreciate explaining your thought on that more directly.

" It's the metal pipe equivalent of kinking a garden hose "

Did you ever try to kink a metal pipe?
Unless you jump through some hoops it's unlikely that you'll get it perfectly closed, especially in case you want to un-kink it later.

Also: In theory you should get zero flow by disabling the valve, but this dosn't work - it shows the icon but it continues to pass matter.
Just filed this as a bug, should it get fixed it would even be better than a slider to zero as the set value could be preserved.

[Shurlan]

45 minutes ago, Masterpintsman said:

" It's the metal pipe equivalent of kinking a garden hose "

Did you ever try to kink a metal pipe?
Unless you jump through some hoops it's unlikely that you'll get it perfectly closed, especially in case you want to un-kink it later.

Also: In theory you should get zero flow by disabling the valve, but this dosn't work - it shows the icon but it continues to pass matter.
Just filed this as a bug, should it get fixed it would even be better than a slider to zero as the set value could be preserved.

Oh wow... I never read this description anywhere and still can't find it.

I agree that kinking and un-kinking a metal pipe would be hard to do, but since the valve experiences no deterioration from switching between  10 g/s and 10 kg/s an arbitrary amount of times, why make it a limiting factor?

Being serious: The disabled behavior being a bug and getting fixed would resolve everything.

[Masterpintsman]

1 hour ago, Shurlan said:

Oh wow... I never read this description anywhere and still can't find it.

Click the valve in the build menu, the popup right of it contains it at the bottom of the upper part.

[Crimeo]

9 hours ago, DuraLex said:

but that would violate the game mechanichs.

This is the suggestions forum. The point of the forum is to suggest things that are not currently part of the game's mechanics.
 

Quote

Unless you jump through some hoops it's unlikely that you'll get it perfectly closed

Every faucet I've ever owned seems able to perfectly close water flow in a metal pipe.

I agree that 0 g/s is definitely a good thing to have. However @Shurlan, I can't say that I see the purpose of why we need to set exact numbers like 40 vs. 43.6. Why do you need exactly 40? 
 

Quote

 it would even be better than a slider to zero as the set value could be preserved.

It would also be much less good though in the sense that disabling requires a dupe, whereas the slider does not, which seems far more important than preserving the value to me.

[jigggy2000]

I also wouldn't mind an increase to the max volume in gas valves. 100g seems small compared to how much much a gas pipe can hold. Although I'd be fine with 100 as anymore would be a nice luxury for me.

[Shurlan]

On 12.3.2017 at 6:31 AM, Crimeo said:

I agree that 0 g/s is definitely a good thing to have. However @Shurlan, I can't say that I see the purpose of why we need to set exact numbers like 40 vs. 43.6. Why do you need exactly 40? 

Several reasons:

1) I'm somewhat OCD (not in the medical term) about numbers and I know that I'm not the only one.

2) The game gains nothing from one being unable to exert perfect control over the throughput. This would be different if the value was not shown which could work for some types of games.

3) I'd like to see this as a general rule of design: If there is a slider manipulating a number let me be able to input that number directly.

4) The game relying heavily on physics can yield interesting systems that need exact adjustments. For Example:

We have steam and liquid oxygen. Mix them in the correct ratio and we get Water and O2 at a nice temperature range that doesn't annihilate your crops. Sure if one gets both of them fast enough the numbers get big enough that small errors due to slider inaccuracy no longer matter, but it could be important in the beginning or for other systems.

 

Other than that I simply don't see a reason not doing it other than the time required by the programmers, which shouldn't be all that much since it probably only affects one or two classes.

On 12.3.2017 at 6:31 AM, Crimeo said:

It would also be much less good though in the sense that disabling requires a dupe, whereas the slider does not, which seems far more important than preserving the value to me.

This is indeed something to consider. A separate button for stopping the flow would be the best of both worlds.

On 12.3.2017 at 7:23 AM, jigggy2000 said:

I also wouldn't mind an increase to the max volume in gas valves. 100g seems small compared to how much much a gas pipe can hold. Although I'd be fine with 100 as anymore would be a nice luxury for me.

I think the maximum should at least be increased to 500 g/s since this is the maximum amount provided by a gas pump.

I can see that the current maximum could be this way to allow finer control over the value with the slider, which would be unnecessary if one could input values directly. *hint, hint, nudge, nudge*

Then again: The maximum throughput should be the same as the maximum throughput of the pipe. Currently one would need 100 gas-valves to allow for one saturated pipe... somewhat unreasonable. Dropping the gas pipe volume from 10kg to 1kg would be fine with me since there current throughput would be insane in real life. (given that an in-game square represents a cubic meter)

One could even think about expanding the range of pipes available like they did/are planning to do with the high-wattage-wire, even tough at some point the menus would get too cluttered.

[Crimeo]

OCD etc. sure, okay. For most of the other reasons, I think a better solution game design-wise would be to make the processing buildings/facilities simply only take in exactly what they need in the first place, instead of any amount then trashing the rest.

So if you need component X and 3*Y to chemically produce 2*Z, then if you try to input 2*X and 3*Y, the building simply won't accept half your X and it will back up the system, solving the issue without needing to do unfun ratio math in game (or needing to control it via valves and such). This is also superior in that it would dynamically adjust on the fly as that building is used more vs. less, whereas a valve based solution does not accomplish that.

I guess I don't see any problem with inputting the numbers, so sure do both, but only doing that as a solution would be a suboptimal solution / band aid fix, so just wanted to be clear that I think there's a more elegant underlying solution to the same issue.

[Shurlan]

On 13.3.2017 at 9:50 PM, Crimeo said:

OCD etc. sure, okay. For most of the other reasons, I think a better solution game design-wise would be to make the processing buildings/facilities simply only take in exactly what they need in the first place, instead of any amount then trashing the rest.

So if you need component X and 3*Y to chemically produce 2*Z, then if you try to input 2*X and 3*Y, the building simply won't accept half your X and it will back up the system, solving the issue without needing to do unfun ratio math in game (or needing to control it via valves and such). This is also superior in that it would dynamically adjust on the fly as that building is used more vs. less, whereas a valve based solution does not accomplish that.

I guess I don't see any problem with inputting the numbers, so sure do both, but only doing that as a solution would be a suboptimal solution / band aid fix, so just wanted to be clear that I think there's a more elegant underlying solution to the same issue.

I wasn't talking about piping stuff into buildings and I agree that this wouldn't fix the problems with material deletion in buildings (which has already been addressed by the devs).

I'm manly concerned about makro-systems set up to run the colony. My example above does not require buildings to run at a specific ratio. The mixing is done in the world.

A new example would be the separation of enough waste water from the conduit to generate enough fertilizer for ones plants without overproducing and clogging up storage.

Regarding the funness of ratio math: That is clearly subjective and I am guilty of occasionally having fun with it.

Edit: I'm also sorry for the late reply... must have missed the notification somehow.

[Crimeo]

Quote

without overproducing and clogging up storage.

Fixing the problem I mentioned fixes this automatically, If buildings (which INCLUDES compactors)stop accepting more when they're full, then it will automatically regulate itself as a system to never overproduce, because once you've filled up however much storage you deemed necessary to make, the initial intake will stop intaking, due to being backed up, thus no waste and a self-balancing system.

In other words, clogged up = a GOOD thing. It's the simplest least effort most automatic way to set up an easily regulated system.

[Shurlan]

14 hours ago, Crimeo said:

Fixing the problem I mentioned fixes this automatically, If buildings (which INCLUDES compactors)stop accepting more when they're full, then it will automatically regulate itself as a system to never overproduce, because once you've filled up however much storage you deemed necessary to make, the initial intake will stop intaking, due to being backed up, thus no waste and a self-balancing system.

In other words, clogged up = a GOOD thing. It's the simplest least effort most automatic way to set up an easily regulated system.

Could you at least try to read my comment?! It is NOT about ratios for buildings and NOT about them having a buggy intake. In the current update it can be very handy for temperature control trough heat exchange at a constant rate. Your building intake problem doesn't help with that at all.

Clogging up storage also wouldn't help with waste water from toilets and showers. Your storage filling up with fertilizer won't stop your dupes from using them. This approach doesn't work there. One will either run out of fertilizer or overproduce without fine control. The intake bug has also already been fixed.

All that aside: There currently exists no building, which requires different types of inputs through one intake, and my guess is that there never will be one due to how the conduits are programmed.

[Crimeo]

13 hours ago, Shurlan said:

In the current update it can be very handy for temperature control trough heat exchange at a constant rate.

I don't see how this plausibly requires 40.6 vs. 40 g/s  level of control. Not that I'm against that, but it's already very doable as-is. This isn't a problem that needs solving as far as I can see?

Quote

Clogging up storage also wouldn't help with waste water from toilets and showers. 

Clogging up liquid storage is already in the game and is an example of this done right currently: liquid outlets won't output when they become submerged, so you can already make a reservoir of the size you want and it will stop when full. Also, toilet usage is intermittent anyway, so is an especially poor example of something solved by precise valve control, since it comes in fits and spurts seconds or minutes apart already -- a level of noise much higher than that valve precision. It's like arguing you need a millimeter marking on your ruler to more accurately measure the height of a guy on a pogo stick.

Again, I have no problem with that feature being implemented anyway, because why not, but it doesn't actually solve several of the issues very well, so it's important to ALSO have the better fix at the same time.

Quote

All that aside: There currently exists no building, which requires different types of inputs through one intake

1) I think they well might if they add partial pressures, which they should do, later. And 2) Doesn't really matter anyway, because the same logic applies to pipe intersections too: one pipe branching to 3 buildings (supplying a shower, toilet, and electrolyser with water for example) is the same problem as would be a building with 3 type input and the same solution.

[Shurlan]

5 hours ago, Crimeo said:

I don't see how this plausibly requires 40.6 vs. 40 g/s  level of control. Not that I'm against that, but it's already very doable as-is. This isn't a problem that needs solving as far as I can see?

Maybe for you if you have a higher screen resolution. For me, looking at the liquid valve, I get jumps of 46 g/s which leads to errors of up to 23 g/s and about 10 g/s on average.

5 hours ago, Crimeo said:

Also, toilet usage is intermittent anyway, so is an especially poor example of something solved by precise valve control, since it comes in fits and spurts seconds or minutes apart already -- a level of noise much higher than that valve precision. It's like arguing you need a millimeter marking on your ruler to more accurately measure the height of a guy on a pogo stick.

Since we are basically agreeing and just arguing about whether control up to 10g/s is necessary or not: Here my final example.

If you can tell me how to do it up to a similar precision without exact values I will concede my point.

5 dupes currently need 9 bristle blossoms to sustain, which require 2kg of fertilizer per cycle (a cycle is 600s), so 18kg per cycle in total.

The fertilizer maker currently turns 1kg of waste water in 0.75 kg of fertilizer. Therefore we need to pipe 18kg / 0.75 = 24kg of waste water per cycle to the fertilizer maker. This results in 24000g / 600s = 40 g/s. (It being 40 is by accident... funny though)

If the incoming waste water includes outside sources or showers the huge variance of the time between toilet visits doesn't matter, but let's make things complicated.

A toilet use transforms 5kg of water into 5kg of waste water. Without small bladder this gives us 25kg of waste water per cycle to work with, or in other terms we can only allow 1 kg of run of. 1000g / 600s = 1.666 g/s is the maximum error we can allow. This gives us a range from 25kg / 600s = 41.666 g/s to 43.333 g/s we need to hit for a sufficient trickling of the waste water. (granted I'd hook up a shower and the margin gets huge, but it shows how precise a system might have to be)

Of course the system is not perfect since the consumption of fertilizer is not constant due to the plants having to be replanted every 18th cycle. Let's assume it takes about 30s to replant (for me it's way less especially if planted at staggered time intervals). This results in 9 * 2kg / 600s * 30s = 0.9kg of overproduction every 18 cycles or 50g / cycle.

On the other hand, an error of 10 g/s leads to 10 g/s * 0.75 * 600s = 4.5kg of over- or underproduction per cycle, which I have no way of circumventing if my target is in the ranges of 10 to 36, 56 to 82, 102 to 138... (about 56% of the values)

And yes: I realize that it would take more than 4000 cycles for that error to fill a storage compactor, but to me it's just annoying and more important, it's hauling jobs that don't need to be done.

You already wrote that ratio math is not to your liking, which might be why you can't see a reasonable application of exact values. That however doesn't make it unnecessary for everyone else. I obviously use "necessary" somewhat loosely since it is not necessary to play the game at all.

[Crimeo]

Quote

If you can tell me how to do it up to a similar precision without exact values

Not as the game is right now, but with the change I suggested, it would be not only possible, but trivial and automatic without even thinking about it.

You would just unleash infinite waste water into the fertilizer maker, blindly, like any player would do intuitively first. It would only take in as a building whatever it could without overflowing. I have no idea what this is offhand, but let's say like 100 g/s, whatever. If you simply disallow fertilizer in any compactors, it's buffer will very soon fill up with fertilizer, and with my suggested change, it will stop taking any more input at that time. 

Now, your dupes mosey on by and they collect exactly as much fertilizer as their blossom updating jobs require, with current AI: 40 g/s on average, because their jobs are only triggered when and as need arises, so they will become 40 g/s jobs assuming the dupes aren't distracted by stuff (this is priority 9 alone).

Thus, the fertilizer maker dips PRECISELY below the maximum buffer that it got clogged up and stopped at, by 40 g/s on average. Thus, its production will unclog and skip and jump along at again, precisely, 40 g/s, without any effort or thought.

If there is any problem, it might be that you'd only want something like filtering to happen for whatever isn't fertilizer water. But that is better solved by a third thing neither of us mentioned: basically just a pipe check valve-y priority gate. A "Go left unless clogged, then go right" thing. Because that's also intuitive, just set and forget, and should achieve perfect precision as long as you choose your priority correctly (and it matches the current priority system flavor)

[Shurlan]

@Crimeo Given that currently buildings dump there product into the world I suppose the change you propose would include buildings internally building up a stockpile from which dupes can take and stopping to produce when reaching a certain threshold. The dupes then only take stuff when needed: problem solved.

The problem I have with this that you never proposed such a change in this thread (I checked all your posts here, just to be sure), leading me to argue about your incomplete and therefore not working system. (you only talked about input, the buildup of output inside the producing  building is essential)

Next time please make a complete outline of the system you imagine or link to it or something. This whole thread could be have as long and yes: such a logistic system would work but only as long as the limiting factor as transportation by dupes. As soon as some sort of automation comes into play all if this falls apart.

[Crimeo]

Quote

would include buildings internally building up a stockpile

It could, but does not need to, hence not mentioning it. It could still be precisely perfect, so long as processing time in between grabs was enough to regenerate a grab's worth. A buffer would certainly make that more consistently true, though. I hadn't really considered it too carefully, but it would be an improvement to the concept to add that to everything consciously.

Quote

such a logistic system would work but only as long as the limiting factor as transportation by dupes. As soon as some sort of automation comes into play all if this falls apart.

Eh what? It works just fine without dupes being the limiting factor. If blossoms were somehow hooked up to pipes directly to the fertilizer machine, the above example would work exactly as well at achieving perfect 40 g/s, so long as the fertilizer CAN produce more than that, it would be perfect. If it can't, just build two, now it's perfect. You don't ever need to match any ratios exactly: output is always just your bottleneck, as it should be.

If they were 30 each, two would be 60, 20 would be automatically throttled, and perfect 40.

If they were 50 each, one would be 50, 10 throttled automatically, and perfect 40.

[Shurlan]

@Crimeo Than tell me: How do you limit production? What in game mechanism do you propose to make your system work? I already plead you to give an outline the next time, jet you don't.

[Crimeo]

8 minutes ago, Shurlan said:

@Crimeo Than tell me: How do you limit production? What in game mechanism do you propose to make your system work? I already plead you to give an outline the next time, jet you don't.

I don't even understand your question. Why would you ever want to limit production when you have active demands at the end of the line that require production? That just doesn't make sense.

In the above example, if you don't want the fertilizers to keep producing, stop planting bristle blossoms. This does not require a game feature or mechanic, so it is not part of my "outline." It's not necessary, it's just common sense to not place orders for things you don't actually want done.

If for some reason you change your mind about a thing you ordered, then use the disable (or deconstruct) building option. That doesn't need to be automated, because screwing up and changing your mind (or long term change in base strategy) is not a reasonable thing to expect an automation system to account for. It's reasonable for this to be manual. Then, once you know enough to place only orders you want filled, my small change suggested will fill them perfectly without waste.

[Shurlan]

19 minutes ago, Crimeo said:

Then, once you know enough to place only orders you want filled, my small change suggested will fill them perfectly without waste.

That's the problem: There is no change you suggested. As far as I can tell you plant the seeds and the game works out the rest for you?

The game checks all the consumption and recursively works out what needs to be produced? If so: I don't think that such a thing will ever be implemented. As a logistic sim that is exactly the job of the player.

All I want you to tell me: Given how the game is right now, what changes need to be made to make it work like you imagine.

 

[Crimeo]

Quote

14 minutes ago, Shurlan said:

Given how the game is right now, what changes need to be made to make it work like you imagine.

 

(sorry I'm stuck in this quote box) Your addition above was a good one for efficiency, so simply add that to what I said originally, and that's the whole up to date as of right now plan, I'm not holding back secrets, lol?

1) Sure add a buffer to all machines that don't have one. I was originally thinking in terms of fluid machines, which already have buffers right now in the form out their outgoing pipes and don't need this, but for the solid production machines, that makes those work as efficiently as well.

2) Machines turn off when they don't have an output (which now includes buffer space as well, as per 1). Some machines do this as well, but not all--some destroy things when they fill up output, which makes the whole concept not work.

Both concepts already exist for several machines, but should simply exist for all. That's it. The game otherwise works exactly as now, but no exact ratios remain an issue.