Smaller batch fluid processing

[Shingen]

It's great to hear that you finally fixed the issue caused by multiple items being created per tick.
Could we also get an alternative production-handling logic for fluids, that would process small amounts of fluids each tick, instead of handling them in (relatively huge) discrete batches every few whole seconds, creating unnecessary wiggles in the production graph?
I'd like to make my fluid-smoothing mod redundant.

[Qon]

It's great to hear that you finally fixed the issue caused by multiple items being created per tick.
Could we also get an alternative production-handling logic for fluids, that would process small amounts of fluids each tick, instead of handling them in (relatively huge) discrete batches every few whole seconds, creating unnecessary wiggles in the production graph?
I'd like to make my fluid-smoothing mod redundant.

Awful idea. If you want graph smoothing, don't ask for UPS reduction. Ask for graph smoothing.

[Shingen]

It's great to hear that you finally fixed the issue caused by multiple items being created per tick.
Could we also get an alternative production-handling logic for fluids, that would process small amounts of fluids each tick, instead of handling them in (relatively huge) discrete batches every few whole seconds, creating unnecessary wiggles in the production graph?
I'd like to make my fluid-smoothing mod redundant.

Awful idea. If you want graph smoothing, don't ask for UPS reduction. Ask for graph smoothing.

Ironic phrasing. If you want to say that what i'm asking for would cause a side-effect of a drop in UPS, don't say that i'm asking for UPS reduction. Say that it would be a side-effect.

I don't want graph smoothing. I want production smoothing, or rather a different approach to production. I am aware that processing bits of fluids at given ratios is a bit more computationally 'expensive' than simply calculating the progress of a recipe, but according to my tests even at an extreme division of the recipes, and given that currently it effectively has the computational overhead of both systems, it seems to be only about 50% more expensive, resulting in additional ~3ms per frame for whole 70 000 chemical plants crafting lube in my tests.
For reference, i have dowloaded a random save file of a 12k SPM base that uses only 1.2k of chemical plants and less than 500 refineries, which suggests that dividing it to extreme would probably increase my frametime by about... 0.07ms.
Yeah, i think we can handle that.

[FuryoftheStars]

It's great to hear that you finally fixed the issue caused by multiple items being created per tick.
Could we also get an alternative production-handling logic for fluids, that would process small amounts of fluids each tick, instead of handling them in (relatively huge) discrete batches every few whole seconds, creating unnecessary wiggles in the production graph?
I'd like to make my fluid-smoothing mod redundant.

Awful idea. If you want graph smoothing, don't ask for UPS reduction. Ask for graph smoothing.

Ironic phrasing. If you want to say that what i'm asking for would cause a side-effect of a drop in UPS, don't say that i'm asking for UPS reduction. Say that it would be a side-effect.

I don't want graph smoothing. I want production smoothing, or rather a different approach to production. I am aware that processing bits of fluids at given ratios is a bit more computationally 'expensive' than simply calculating the progress of a recipe, but according to my tests even at an extreme division of the recipes, and given that currently it effectively has the computational overhead of both systems, it seems to be only about 50% more expensive, resulting in additional ~3ms per frame for whole 70 000 chemical plants crafting lube in my tests.
For reference, i have dowloaded a random save file of a 12k SPM base that uses only 1.2k of chemical plants and less than 500 refineries, which suggests that dividing it to extreme would probably increase my frametime by about... 0.07ms.
Yeah, i think we can handle that.

So... you want production smoothing, which will cause a decrease to UPS, to create a smoother graph?

Just... umm... no. There's absolutely no game play value behind that at all. Feel free to create a mod for that (sounds like with 2.0 that'll be easier to do), but for the vanilla game, no, I do not support that at all.

[Shingen]

It's great to hear that you finally fixed the issue caused by multiple items being created per tick.
Could we also get an alternative production-handling logic for fluids, that would process small amounts of fluids each tick, instead of handling them in (relatively huge) discrete batches every few whole seconds, creating unnecessary wiggles in the production graph?
I'd like to make my fluid-smoothing mod redundant.

Awful idea. If you want graph smoothing, don't ask for UPS reduction. Ask for graph smoothing.

Ironic phrasing. If you want to say that what i'm asking for would cause a side-effect of a drop in UPS, don't say that i'm asking for UPS reduction. Say that it would be a side-effect.

I don't want graph smoothing. I want production smoothing, or rather a different approach to production. I am aware that processing bits of fluids at given ratios is a bit more computationally 'expensive' than simply calculating the progress of a recipe, but according to my tests even at an extreme division of the recipes, and given that currently it effectively has the computational overhead of both systems, it seems to be only about 50% more expensive, resulting in additional ~3ms per frame for whole 70 000 chemical plants crafting lube in my tests.
For reference, i have dowloaded a random save file of a 12k SPM base that uses only 1.2k of chemical plants and less than 500 refineries, which suggests that dividing it to extreme would probably increase my frametime by about... 0.07ms.
Yeah, i think we can handle that.

So... you want production smoothing, which will cause a decrease to UPS, to create a smoother graph?

Just... umm... no. There's absolutely no game play value behind that at all. Feel free to create a mod for that (sounds like with 2.0 that'll be easier to do), but for the vanilla game, no, I do not support that at all.

sigh.
essentially everything you add to a world causes "a" decreate to UPS. the important part is the scale, and what you're getting in return.
additional mere ~0.07ms for a factory that already takes ~37ms to render is a ~0.2% larger frametime. it varies more by itself, than this thing adds constantly. you literally wouldn't notice it, if devs did something else of a similar impact, that wouldn't visibly affect the game.
also note that it's ~0.07ms for a factory that is 10x larger than anything that 99% of the players will ever build.
and this TINY hit to UPS is IMO a perfectly justifiable tradeoff for having production that makes sense, and graphs that are finally readable in scales lower than "1 hour" for an average player (i.e. before you start creating millions of amounts of fluids) and which allows to quickly notice that something isn't working correctly, some pipes aren't connected, etc.. this isn't "no gameplay value".

(also tsk tsk, it already is a mod, as i mentioned in the first message.)

[FuryoftheStars]

sigh.
essentially everything you add to a world causes "a" decreate to UPS.

I am fully aware of that.

additional mere ~0.07ms for a factory that already takes ~37ms to render is a ~0.2% larger frametime. it varies more by itself, than this thing adds constantly. you literally wouldn't notice it, if devs did something else of a similar impact, that wouldn't visibly affect the game.
also note that it's ~0.07ms for a factory that is 10x larger than anything that 99% of the players will ever build.
and this TINY hit to UPS is IMO a perfectly justifiable tradeoff for having production that makes sense, and graphs that are finally readable in scales lower than "1 hour" for an average player (i.e. before you start creating millions of amounts of fluids) and which allows to quickly notice that something isn't working correctly, some pipes aren't connected, etc.. this isn't "no gameplay value"

At the stage of the game where the graph can actually be used for this, you don't even need it to see the issues. And at the stage where it becomes more difficult to see the issues unless you have a full system failure, the graph is useless for identifying issues unless you have a full system failure due to it's showing combined values for the entire base.

So, yes, "no gameplay value".

If we were talking a method for better fluid flow and distribution through pipes (while keeping the semi-realism), then that'd be a different story.

(also tsk tsk, it already is a mod, as i mentioned in the first message.)

Yeah, fully aware of that, too.

[mmmPI]

To me that wouldn't be so surprising that the overhead in CPU cost for smooth fluid production be not too high regarding the fluid simulation, as fluids are updated every tick regardless of the frequency at which the entities finish their receipe. But the graph for statistic are expensive in themselves too. If you have 55 UPS because you are reaching the limit of your computer, it will noticeably be worse when opening it at the scale of say 5 hours, where you have a lot of data. Such graph i think should be modified to delete or average some data point overtime to be smoother not by adding more points but just changing the shape of the curve if that is the problem. Doing update of such graph more frequently to add more datapoints is the most costly way of smoothing it i think. ( It would only smooth the graph if the receipe are made to be shorter ).

About the receipe and the game, and not the graph. I think it's part of the challenge to deal with receipe that have different time to complete in machines that have different crafting speed. It would remove one part of it to have no more different time for receipe, only quantity. That is not the same as smoothing the display of stats to me.

I think smoothing the display of stats could potentially even increase perfomance, if some of the old datapoints can be dropped and replaced by their average, maybe it is done already though, or that the sampling is done less often, this would also smooth the graph instead of updating every second or 5 second, only allow to show the last minute or 10 minutes and the graph will be smooth !

If you need information on what's going on in your factory, and you only have the average production in the last 5 second, to me it doesn't matter much if it's stable or not, because even if it IS a somewhat stable value that is shown, i would want to know the average in the last 5 to 10 minutes at least, to avoid seeing result that could be influenced by me picking things on belts, or a recent biter attack, or some expensive inserters that i just built and that are refilled in the mall. I don't think you get a lot of information if you look at too short of a timeframe, and if it's a bit longer then the graph is getting smoother and smoother.

[FuryoftheStars]

To me that wouldn't be so surprising that the overhead in CPU cost for smooth fluid production be not too high regarding the fluid simulation, as fluids are updated every tick regardless of the frequency at which the entities finish their receipe.

Should note here, while they're claiming that on a full base it only had a 0.2% affect on update time, in a pure fluid test map it had an "only about 50%" affect on update time.

About the receipe and the game, and not the graph. I think it's part of the challenge to deal with receipe that have different time to complete in machines that have different crafting speed. It would remove one part of it to have no more different time for receipe, only quantity. That is not the same as smoothing the display of stats to me.

This is also a good point and another reason (for me) to be opposed to the idea.

But yeah, I agree, if they feel as though a smoother graph line could be of more benefit for diagnostic of production issues, then the simpler and less impactful thing on the game to ask for would be a smoothing of the graph....

[Shingen]

But the graph for statistic are expensive in themselves too. If you have 55 UPS because you are reaching the limit of your computer, it will noticeably be worse when opening it at the scale of say 5 hours, where you have a lot of data. Such graph i think should be modified to delete or average some data point overtime to be smoother not by adding more points but just changing the shape of the curve if that is the problem. Doing update of such graph more frequently to add more datapoints is the most costly way of smoothing it i think. ( It would only smooth the graph if the receipe are made to be shorter ).

i'm under an impression that you think that every result of every crafting entity gets saved independently, but that would be just crazy. i'm quite certain all production from each frame gets summed up.
and because of that, if you have enough entities to effectively create some amount of x at every update, there will be no difference in graphs' performance whether in some saved datapoints you'll have 50% of "200 x produced" and 50% of "100 x produced", or if you have 100% of "150 x produced".
also at 5 hour range even fluids no longer need my kind of smoothing.

About the receipe and the game, and not the graph. I think it's part of the challenge to deal with receipe that have different time to complete in machines that have different crafting speed. It would remove one part of it to have no more different time for receipe, only quantity. That is not the same as smoothing the display of stats to me.

uhh what? atm in vanilla there is no fluid recipe that can be crafted in machines of different crafting speeds. besides, of course, the use of modules, but then it's just you who's making it a bigger problem for yourself.
already like 95% of crafting in Factorio is having to deal with assemblers (you know, the buildings with 3 tiers of actual inherent difference of crafting speed which would not be affected) and having a slightly different way to think of crafting some products would be refreshing.
but the most important thing i can say to this is that you don't seem to understand what i'm talking about, because i am not suggesting to make fluids have some static crafting amount/time - it would continue to be affected by crafting speed of the machine, and you will still have to do all the same calculations. the only difference would be, that there wouldn't be a progress bar at a completion of which 100 oil magically turns into 45 petroleum in an instant and flushes down the drain pipe.

Should note here, while they're claiming that on a full base it only had a 0.2% affect on update time, in a pure fluid test map it had an "only about 50%" affect on update time.

to clarify, it increases the chemical plant (and i assume also refinery) entity time by about 50%, which ends up being about 0.2% of total time of a SPM-focused factory, because it's just that small part of the factory.
funnily enough, despite it being "pure fluid map", in the initial tests it wasn't 50% of the entire map, because the damned infinite pipes supplying/draining fluids were taking 2/3 of the update time themselves. that's just how easy is to overwhelm this scary "50%".

[mmmPI]

i'm under an impression that you think that every result of every crafting entity gets saved independently, but that would be just crazy. i'm quite certain all production from each frame gets summed up.

That doesn't matter , the result of every entity has to summed to compute the production of a tick, making 60 times per second sums of 1000 numbers because you have 1000 machines, and making 5 time per second, sum of 10 machine because you have 1000 but they do not produce each tick is a different math. In one case you need much less memory to execute. You propose to do 60 times more update with 1/60 of the quantity to achieve the same result in the end, in 60 times more steps, that doesn't cost 60 times more in fluid simulation but it does cost 60 times more in update of entity production.

But that's just (1) point that make it worse for performance the (2) is worse about memory :

There is no need to store more than 5 points per second to make the graph look curve. 60 ? The graph smoothing process could help performance if the decision was to sample less often and just interpolate in between the value with a curve that would only be for the graph to be smooth.

Accuracy of every pixel in a graph that will change every second makes no sense to. The graph WILL change every second even if it's super smooth curve looking, it can still be 5000 a second, and 0 the second later if suddenly your maxi setup was cut of power, and then resupplied by the power switch after 0.5 second. or 1.5 second, or whatever crazy things that can occur in real game.

You are not proposing a method to smooth the graph, just to make it a heavier graph that need much more computation to update every time to me. You want it to be smooth because the game would query 60 numbers to show 1 second where it could be done with 3 no matter the number of actual machine. And in both case, it would not result in a more readable 1 second or 5 second graph. It would be curvy instead of zigzagy but it would still be very chaotic most of the time and updating too fast for 1 pixel accuracy to be noticeable due to machine backing up or power shortage that is just the most significant example of the impossibility to make a smooth graph by adding more datapoints when the data themselves aren't smooth. Adding more chaotic data more frequently will not result in a smooth graph. ( even if machine are made to produce every tick they won't always you can't guarantee that just by changing receipe to finish every tick)

uhh what? atm in vanilla there is no fluid recipe that can be crafted in machines of different crafting speeds. besides, of course, the use of modules, but then it's just you who's making it a bigger problem for yourself.
already like 95% of crafting in Factorio is having to deal with assemblers (you know, the buildings with 3 tiers of actual inherent difference of crafting speed which would not be affected) and having a slightly different way to think of crafting some products would be refreshing.

Chemical plant are producing battery consuming sulfuric acid, how are you going to produce battery every tick to smooth the consumption ? 0.0012 battery ?
And mining drills consuming sulfuric acid that can back up/ resume / back up / resume every second, how is this going to make a smooth graph ?
And assembly machine consume water for concrete and sulfuric acid for the bue circuits, there is no way to smooth the consumption graph if the consumption is not smooth.

Your proposition is to only have the production graph be smoother not the consumption ? How does that work exactly ? production follows consumption in game once pipes are full.

It wouldn't work in case 20 refinery backs up, and the next second they all start over because a train has arrived and empty a tank so. No way to smooth production either, there will be a sudden jump, even worse with your proposed method of taking more sample points because 1 tick it would be 0, and the next one 20 times the output of a refinery per tick. Straight vertical line, then every tick untill ref backs up, straight horizontal line, then straight vertical lane down to 0 if tank is full, and repeat. The opposite of the expected result.

but the most important thing i can say to this is that you don't seem to understand what i'm talking about, because i am not suggesting to make fluids have some static crafting amount/time - it would continue to be affected by crafting speed of the machine, and you will still have to do all the same calculations. the only difference would be, that there wouldn't be a progress bar at a completion of which 100 oil magically turns into 45 petroleum in an instant and flushes down the drain pipe.

Maybe i dont. What you propose would mean instead a machine stopped at any moment in time would have no progress bar right ? Because every tick the receipe is finished right ? That's the only way, there is no progress to keep track of. This means the receipe crafting time is 1 tick right ?

[bobucles]

Graph? You mean the production graph feedback? A few things on that:
1) The production graph does not feed into the sim, like, at all. It doesn't change production, biters can't see it, circuits can't see it, basically it's an all output system reporting data from the sim. If you're performing any sort of computation on it, why would you drain CPU resources from the main game? That doesn't make sense, this is a job for another CPU core.

2) I'm no CPU architect, but big repetitive math operations on simple arrays? Chances are there's a single CPU instruction for it. I don't know what it is, or how the data needs to be set up, but you can bet someone already printed the silicon to crank it out in record speed. There may even be some black magic to offload the math to GPU.

3) Smoothing doesn't really crate new data, it's merely a reinterpretation of existing data. So, you know, you can probably just smooth the 100 or so visible data points on the production graph, when it's actually open, and call it good.

[mmmPI]

Graph? You mean the production graph feedback? A few things on that:
1) The production graph does not feed into the sim, like, at all. It doesn't change production, biters can't see it, circuits can't see it, basically it's an all output system reporting data from the sim. If you're performing any sort of computation on it, why would you drain CPU resources from the main game? That doesn't make sense, this is a job for another CPU core.
2) I'm no CPU architect, but big repetitive math operations on simple arrays? Chances are there's a single CPU instruction for it. I don't know what it is, or how the data needs to be set up, but you can bet someone already printed the silicon to crank it out in record speed. There may even be some black magic to offload the math to GPU.

Ideally yes, the graph is independant from the game it doesn't send anything to it, only receive, and its look doesn't have to drain ressources. I'm no CPU architect either. From my rudimentary understanding,CPU load is not only measured in the amount of computation of complexity of them, but there is also a dimension of what is the data on which the operations are done. The CPU cache and the transmission of data between the CPU cache and the RAM would more often be the bottleneck rather than the speed at which the CPU can do the operation in Factorio. Giving one's computer other task to do while playing on a different core would be less likely to impact perfomance of the game than tasking the same computer to process data from the game more often, as those data would need to be fetched/read from the memory, RAM or CPU cache, when transmitted to that other core or GPU. To me that has a cost that i can't quantify, it's different from doing the computation only which would be similar to doing other unrelated tasks in my comparaison. That's the "cost in memory" i wanted to mention, as sums of arrays is not what strikes me as particularly costly for a CPU, but when such arrays are very long, it's a datathroughput question too.
Considering the proposing of adding data points to the graph in order to smooth it, by altering the way fluid producing entities function, to make them output everytick. I think it would be going the "wrong" direction. This is just from reading discussion on factorio, i'm interested in the more technical side, but there's not that many CPU architect doing vulgarization out there .

3) Smoothing doesn't really crate new data, it's merely a reinterpretation of existing data. So, you know, you can probably just smooth the 100 or so visible data points on the production graph, when it's actually open, and call it good.

I agree maybe it was not clear in my wording but i'd rather have a smoothing that doesn't create new data, just a reinterpretation of it for its look to be more pleasant to players that desire a more curvy less zigzaggy graph. The proposed suggestion that made me react proposed to change the way machines using fluids would process their receipe ( to produce a little every tick ) with the aim of using those extra data points to smooth the graph. Which i think was "wrong". As there are other ways that would cost less ressources. ( and wouldn't require to modify the gameplay).

My point was that such method to smooth the graph is "adding points" , it will not even necessarily yield in a smoother graph, it misses the point, the smoothness depend on the factory life, if there is chaotic production the graph is bound to be too. I think the idea of making a mod like the one Shingen did is pretty cool, it allowed to give estimate for performance, it does work in some condition, it produce smoother curve, but you can also create chaotic ones quite easily.

On the other hand, i think others tools conceptually wouldn't need any more computation such as having less datapoints and replacing the gaps by curve could "smooth the graph" at the cost of accuracy. It could even 'make up' for for the chaotic production of the fatory if you take a time scale large enough. Similar to trend approximation in economical chart, those do not try to represent accuratly by adding data, but rather discarding points and averaging periods, in order to extract meaning from the zigzaggy line.

[Shingen]

That doesn't matter , the result of every entity has to summed to compute the production of a tick, making 60 times per second sums of 1000 numbers because you have 1000 machines, and making 5 time per second, sum of 10 machine because you have 1000 but they do not produce each tick is a different math. In one case you need much less memory to execute. You propose to do 60 times more update with 1/60 of the quantity to achieve the same result in the end, in 60 times more steps, that doesn't cost 60 times more in fluid simulation but it does cost 60 times more in update of entity production.

i don't know what is the summing up of the production of last tick counted as, but it either is a part of the 0.2% entity update time, or it's an additional, but apparently even smaller and less significant value, so eh, whatever.

There is no need to store more than 5 points per second to make the graph look curve. 60 ? The graph smoothing process could help performance if the decision was to sample less often and just interpolate in between the value with a curve that would only be for the graph to be smooth.

You are not proposing a method to smooth the graph, just to make it a heavier graph that need much more computation to update every time to me. You want it to be smooth because the game would query 60 numbers to show 1 second where it could be done with 3 no matter the number of actual machine. And in both case, it would not result in a more readable 1 second or 5 second graph. It would be curvy instead of zigzagy but it would still be very chaotic most of the time and updating too fast for 1 pixel accuracy to be noticeable due to machine backing up or power shortage that is just the most significant example of the impossibility to make a smooth graph by adding more datapoints when the data themselves aren't smooth. Adding more chaotic data more frequently will not result in a smooth graph. ( even if machine are made to produce every tick they won't always you can't guarantee that just by changing receipe to finish every tick)

i may even agree, but how exactly the graph is calculated and displayed is not my business and is not affected by my suggestion whatsoever. if they wanted to change something there it would be completely independent of my suggestion.

Chemical plant are producing battery consuming sulfuric acid, how are you going to produce battery every tick to smooth the consumption ? 0.0012 battery ?
And mining drills consuming sulfuric acid that can back up/ resume / back up / resume every second, how is this going to make a smooth graph ?
And assembly machine consume water for concrete and sulfuric acid for the bue circuits, there is no way to smooth the consumption graph if the consumption is not smooth.

no. quite obviously i'm talking about changing only recipes that both consume and produce only fluids.
however, things that also take multiple solid items, like coal liquefaction, could be also divided to use up only 1, in this case coal, per production cycle.

Your proposition is to only have the production graph be smoother not the consumption ? How does that work exactly ? production follows consumption in game once pipes are full.

no. quite obviously it would end up making the consumption graph smoother too. they're both graphs in the "production" window, hence "production" graphs.

Accuracy of every pixel in a graph that will change every second makes no sense to. The graph WILL change every second even if it's super smooth curve looking, it can still be 5000 a second, and 0 the second later if suddenly your maxi setup was cut of power, and then resupplied by the power switch after 0.5 second. or 1.5 second, or whatever crazy things that can occur in real game.

It wouldn't work in case 20 refinery backs up, and the next second they all start over because a train has arrived and empty a tank so. No way to smooth production either, there will be a sudden jump, even worse with your proposed method of taking more sample points because 1 tick it would be 0, and the next one 20 times the output of a refinery per tick. Straight vertical line, then every tick untill ref backs up, straight horizontal line, then straight vertical lane down to 0 if tank is full, and repeat. The opposite of the expected result.

if your factory suddenly runs out of power or no longer has the space to push products to, then it'll stop, and the graph will, at last, accurately and quickly reflect that.
if your factory's production actually fluctuates for whatever reason, the graphs will at last, accurately and quickly reflect that, instead of fluctuating constantly.

Maybe i dont. What you propose would mean instead a machine stopped at any moment in time would have no progress bar right ? Because every tick the receipe is finished right ? That's the only way, there is no progress to keep track of. This means the receipe crafting time is 1 tick right ?

uh... no? yes? i don't even know, forcefully using naming and features from the current system, that is affected by various bonuses of modules etc., will not help you understand the proposed system.

this is pointless and exhausting.

3) Smoothing doesn't really crate new data, it's merely a reinterpretation of existing data. So, you know, you can probably just smooth the 100 or so visible data points on the production graph, when it's actually open, and call it good.

to repeat again, i'm not talking about strictly speaking "smoothing the graphs", i.e. as you've put it "reinterpreting existing data". i'm talking about changing the production of fluids creating more data points that would just end up as "smoother" graphs.

My point was that such method to smooth the graph is "adding points" , it will not even necessarily yield in a smoother graph, it misses the point, the smoothness depend on the factory life, if there is chaotic production the graph is bound to be too. I think the idea of making a mod like the one Shingen did is pretty cool, it allowed to give estimate for performance, it does work in some condition, it produce smoother curve, but you can also create chaotic ones quite easily.

no, the smoothness should depend on factory life, but now it doesn't, unless you happen to have enough perfectly evenly spread out in time machines. with my suggestion it would always.
my idea isn't to have a perfectly horizontal line no matter the situation, it's to reflect the actual state of the factory.

[bobucles]

In terms of "data points", there's no point in having more than one data point per tick. Nothing happens between ticks.
There is also very little value in storing a completely new stream of data, when it is simply the original data but with a short term average.
It really feels like something you do on demand, when someone is looking at the production screen, with the handful of data points they're actually looking at.
Or, it's a small button that changes modes for the 1-5 minute production screen.
It doesn't make sense to smooth curves beyond that point, because "total per minute/per hour" already performs a massive running average for free.

It sounds like something that costs less than a dozen ticks, over multiple hours. How are you burning 3ms a tick on this?

Edit: Or is this more about changing liquid machines to produce every tick, but the flow rate of their outputs changes depending on machine speed? Might be neat? Sounds like it could get messy if flow rates change frequently or if it starts dipping into floating point hell, where 0.99999999998462 of a resource isn't 1.

[Shingen]

In terms of "data points", there's no point in having more than one data point per tick. Nothing happens between ticks.

nobody was talking about the nothing that happens between ticks, why are you?

It sounds like something that costs less than a dozen ticks, over multiple hours. How are you burning 3ms a tick on this?

something that takes time each update should cost updates per multiple hours?
also let's not forget the significant number of 70 000 chemical plants (corresponding to an about 700 000 SPM base) that already ate 6ms by their mere existence + regular work.

[mmmPI]

Chemical plant are producing battery consuming sulfuric acid, how are you going to produce battery every tick to smooth the consumption ? 0.0012 battery ?
And mining drills consuming sulfuric acid that can back up/ resume / back up / resume every second, how is this going to make a smooth graph ?
And assembly machine consume water for concrete and sulfuric acid for the bue circuits, there is no way to smooth the consumption graph if the consumption is not smooth.

no. quite obviously i'm talking about changing only recipes that both consume and produce only fluids.
however, things that also take multiple solid items, like coal liquefaction, could be also divided to use up only 1, in this case coal, per production cycle.

And if you add productivity module, then it reduce the speed of the machine and it takes only 0.75 coal ?
if you add speed module it use up 1.2 coal, and the inserter cut pieces of coal to keep for later ?

It's part of the challenge to have different receipe time that are not only 1 tick in duration and manage the different crafting time in machines with different crafting speed, i said, You said it would only affect machines that deals with fluids, and not the assemblies, but assemblies that makes blue circuit consume sulfuric acid, if they consume their sulfuric acid every tick, they will produce how many blue circuit do you think ?

to repeat again, i'm not talking about strictly speaking "smoothing the graphs", i.e. as you've put it "reinterpreting existing data". i'm talking about changing the production of fluids creating more data points that would just end up as "smoother" graphs.

to repeat again, it doesn't work, if factory production is not smooth due to trains, data will not be smooth, adding more data point does not change that, haven't you seen it using your mod ?

Edit here is a situation in which your mod, despite the good ideas can't do anything :

doesntwork.jpg (240.09 KiB) Viewed 1738 times

the screenshot was made with the mod active, i made clock to cause the refineries to be active only 10 ticks and stop for 50 ticks effectively creating chaotic behavior.

not smooth fluid despite mod to smooth fluid.zip

(1.93 MiB) Downloaded 23 times

[bobucles]

I dunno. Changing the operating behavior of a third of the factory just to make a graph look pretty seems kinda... overkill? A minor smoothing tool for small duration graphs would get the job done, practically for free.

[Shingen]

And if you add productivity module, then it reduce the speed of the machine and it takes only 0.75 coal ?
if you add speed module it use up 1.2 coal, and the inserter cut pieces of coal to keep for later ?

It's part of the challenge to have different receipe time that are not only 1 tick in duration and manage the different crafting time in machines with different crafting speed, i said, You said it would only affect machines that deals with fluids, and not the assemblies, but assemblies that makes blue circuit consume sulfuric acid, if they consume their sulfuric acid every tick, they will produce how many blue circuit do you think ?

oh my fucking dog.
why on Nauvis would you think it would do such nonsense? it doesn't work like that now, and i have NOT suggested anything like that.
my mod currently modifies coal liquefaction exactly as i'd want Factorio devs to divide it in vanilla. does it suddenly require 0.75 or 1.2 coal? no, it just uses 1 coal instead of 10, and every couple of cycles, when the bonus productivity progress goes past 100%, it generates some products out of thin air, just like it does in vanilla, just 10x less of them. and it just does everything 10x faster.
my proposed altered "recipes" are not 1 tick in duration and have no effect on the complexity of the factory.
i did not say anything like "it wouldn't affect assemblers". i did write, however, very clearly:

no. quite obviously i'm talking about changing only recipes that both consume and produce only fluids.
however, things that also take multiple solid items, like coal liquefaction, could be also divided to use up only 1, in this case coal, per production cycle.

"only fluids" - are blue circuits fluids?
"take (and by extension produce) multiple solid items" - are there multiple blue circuits created per cycle?
no and no. so what are you talking about?

to repeat again, it doesn't work, if factory production is not smooth due to trains, data will not be smooth, adding more data point does not change that, haven't you seen it using your mod ?

cool. to repeat again, you create arbitrarily chaotic scenarios, you receive arbitrarily chaotic results. bullshit in, bullshit out.
the goal was to accurately reflect the actual production, and that's what you're getting.

i'm done replying to you.

[mmmPI]

i did not say anything like "it wouldn't affect assemblers". i did write, however, very clearly:

uhh what? atm in vanilla there is no fluid recipe that can be crafted in machines of different crafting speeds. besides, of course, the use of modules, but then it's just you who's making it a bigger problem for yourself.
already like 95% of crafting in Factorio is having to deal with assemblers (you know, the buildings with 3 tiers of actual inherent difference of crafting speed which would not be affected)and having a slightly different way to think of crafting some products would be refreshing.

cool. to repeat again, you create arbitrarily chaotic scenarios, you receive arbitrarily chaotic results. bullshit in, bullshit out.
the goal was to accurately reflect the actual production, and that's what you're getting.
i'm done replying to you.

I tried my best to explain politely to you why your idea doesn't apply to situations that players faces, that's why i think it's good as mod , but it makes little sense to add something to smooth the graph that doesn't smooth the graph when the graph isn't smooth in the first place. Your mod works in very precise conditions, play a little different and it doesn't work anymore.
I think sometimes people pulls out a lot of bullshit without even noticing and it's hard not throw some back in return. I wouldn't mind you stop trying to convince me.

[FuryoftheStars]

3) Smoothing doesn't really crate new data, it's merely a reinterpretation of existing data. So, you know, you can probably just smooth the 100 or so visible data points on the production graph, when it's actually open, and call it good.

to repeat again, i'm not talking about strictly speaking "smoothing the graphs", i.e. as you've put it "reinterpreting existing data". i'm talking about changing the production of fluids creating more data points that would just end up as "smoother" graphs.

So, seriously, what point is there behind this other than smoothing the graph? If there is none, then asking for some type of graph smoothing that won't cost any update time normally is the better way to go, yes?

By changing the recipes, in addition to adding needless overhead, you are changing the ratio relationships between them (refinery recipes are 5 secs while the chem plant has 1, 2, & 3 (or was it 4?) sec recipes), as well as running into the issue of (especially recipes that consume or produce items) not being able to cut it further without changing the balance.

It just makes absolutely no sense to me to want to change one aspect of the game that comes with overhead and side effects for a singular purpose when there's a method that nets you the same result without the undesired.