Open Tempuser8734 opened 2 weeks ago
1/60s is 16.6666... milliseconds
which is one game tick - I can understand why you might be interested in items per tick, but less so for a quarter/half/three quarters of a second.
They all should be easy enough to implement, but I'd be interested to hear the use case since the dropdown menu could get quite bloated.
For me it's more about belt throughput, for which calculation I do mostly in my head now. Lets say there is a node that outputs 136 items/s. Now I divide it by 30 to get 4.5 red belts of items, which is to much, so I divide it by 45 and get 3.something blue belts of items, which I implement into my base. So with those options in base time, I would just click and switch between them to see exact numbers without using calculator.
I thought there might be some extra label on arrows/connections to show what belt and how many would be necessary for that connection, but this one may be so difficult to implement, that I decided to ask for easier option.
in my opinion such "number of belts" indicator could be quite easly implemented on "throughput node"
in my opinion such "number of belts" indicator could be quite easly implemented on "throughput node"
That's good idea
in my opinion such "number of belts" indicator could be quite easly implemented on "throughput node"
Then implement it and submit a Pull Request?
OK - I will try to do it. I will describe my idea later today (before I will start any development - just to check if I'm covering all cases)
Well... while I still believe that my initial idea is "quite easy to implement" (small change in PassthroughNodeElement.DetailsDraw=>display ActualRate/belt speed from settings) - I've got problems with creation of proper UseCases.
How it should look like? And how the users should use it? What is the best approach?
As for now for my own graphs - I'm adding a node with limit and than proper number of assemblers: ... maybe it's the best way of using it and no other changes are required?
1,2 - From my side the best option would be to read all available belts and automatically put the icon of the one that will be the slowest with grater capacity in the middle of throughput node, maybe if "Show belt throughput on pass-through nodes" is enabled in options. There could be also global option to force the use of a belt type, dropdown with all available options would be the best, but if not maybe putting belts in enabled objects will do. 3 - In my opinion the number of belts should not be rounded to much. It's good to see how much throughput is left, and rounding up by myself is easy. 4 - I don't think it is necessary. If you have base time flow rate on the bottom and top of the node, and number of belts in the middle, you can easily work out what number you need to put as it is to get desired result. 129 items/s - 2.8 blue belts, you can easily see that you need 90 or 135. Ok with other numbers or time bases it may be less easy, so I don't know now.
So now I think the best is drop down list with belts to choose on each node, and no, of belts flow rate limitation.
Whatever you decide on and give us will be better than nothing, so definitely take benefits versus time needed to implement into consideration when making the decision. And there are also liquids. Vanilla's 1200/s makes it easy, but mods may complicate things here to.
Could you add base time option 1/15s, and maybe 1/30, 1/45, and 1/60? It would make simple way of displaying how many belt worth of stuff you need to meet the demand, and should be easy to add, unless there are some weird problems with fractions and precision with calculations like that.