Hello, so I've started creating new mod that should be almost identical to yours, and someone pointed me here.

I see yours is working pretty well and I have some suggestions.

1/ FLUIDS
This is my biggest issue with your mod because just when I started my factory with your mod at 30 UPS, my nuclear power started failing due to lack of water. This can definitely be considered bug.

Fluid containers have obj["fluid_box"]["height"], which if you increase, you increase the container throughput, it seems.
So at lower UPS speeds, pipes can keep their throughputs.
However, it does also increase volume of the container. But reducing obj["fluid_box"]["base_area"] fixes that while keeping the throughput.

2/ Spidertron could you perhaps add scripts to add some modules to spidertron to modify its speed according to desired UPS?

3/ I wish your mod was more well-known because I feel like it is what many people want/need, but it is hard to find for people who wish to optimize their fps/ups (just as I searched), how about creating another mod that will contain fps and ups keywords and just have this one as dependency?

I, too, have hit the same problem with fluid flow causing nuclear reactor problems. I assume that it's related to this issue noted in the mod description:

"Factorio 0.17 removed the variable that adjusted fluid speeds, so the mod is unable to change those for the time being."

Anyway, no promises but if I were to look into a new API for accomplishing what this mod used to do (before the 0.17 change) and raise a PR, is there interest? (I haven't looked yet so I don't know how feasible it is.)

I, too, have hit the same problem with fluid flow causing nuclear reactor problems. I assume that it's related to this issue noted in the mod description:

"Factorio 0.17 removed the variable that adjusted fluid speeds, so the mod is unable to change those for the time being."

Anyway, no promises but if I were to look into a new API for accomplishing what this mod used to do (before the 0.17 change) and raise a PR, is there interest? (I haven't looked yet so I don't know how feasible it is.)

I already provided solution for fixing the fluids. It would be great if somebody looked into how to make spidertron work with lower UPS speeds though.

Hint: it appears to not be doable by editting prototypes, it may be possible with some scripts though.

I figured out how to speed up or slow down spidertrons. It is not perfect, but I think it can't be. Please, use the source code to learn how to make your mod better. https://mods.factorio.com/mod/DoubleSpeedSpidertron

My apologies for the late reply, I have been somewhat busy with other things lately. I have been thinking about the fluid boxes. I had thought that the general consensus regarding fluid box sizes for pipes was that it made little difference, (at least when bob's mods had larger and smaller pipes). One other issue is that fluid production rates would have to be doubled for double size pipes to match, and that would have a knock-on effect on all the recipes that produce or consume fluids to keep them in line. That's not impossible, but gets very fragile as those recipes are likely ones that would get changed in a data-final-fixes.lua file which could be loaded after this mod makes changes, leaving certain recipies unmodified.

If you have alternate information regarding fluid flow in large and small pipes please do provide it.

As for the spidertron, I will look into integrating that.

I thought about having multiple mods with different default settings, but I don't really like the general idea of adding mods just for different settings of the same mod.

Double post NM

If you have alternate information regarding fluid flow in large and small pipes please do provide it.

As I wrote in one of previous posts, if you double the height and halve the base_area of fluid_box, you get containers/pipes of the same size but double the throughput. Or at least that is the experience from my short testing with nuclear power. Please, do try it yourself.

Can you try adding this to the adjust_prototypes_recursive function between lines 37 and 38 in data-final-fixes.lua to make sure it works how you expect it to?

if type(object) == "table" then
    local fbscale = math.sqrt(gtts_time_scale)
    if object["pipe_connections"] then
        if not object["fluidbox+gtts"] then
            object["fluidbox+gtts"] = true
            if object["base_area"] then
                object["base_area"] = object["base_area"] / fbscale
            else
                object["base_area"] = 1 / fbscale
            end
            if object["height"] then
                object["height"] = object["height"] * fbscale
            else
                object["height"] = 1 * fbscale
            end
            if object["base_level"] then
                object["base_level"] = object["base_level"] * fbscale
            end
        end
    end
end

Test tank balancing with 31 pipe pipeline between.

No Scale
fbscale = 1
60 ups : 14.10s
30 ups : 27.86s
120 ups: 7.03s

Full Scale
fbscale = gtts_time_scale
30 ups : 7.96s [1]
120 ups: 1:46.04s

Half Scale
fbscale = (gtts_time_scale - 1) / 2 + 1
30 ups : 15.45s
120 ups: 38.94s
240 ups: 34.06s

Quarter Scale
fbscale = (gtts_time_scale - 1) / 4 + 1
30 ups : 19.38s
120 ups: 19.48s
240 ups: 14.46s

Square Root Scale
fbscale = math.sqrt(gtts_time_scale)
30 ups : 16.75s
120 ups: 46.80s
240 ups: 53.32s

[1] This is double height and half area fluid boxes, and creates a strong oscillation where the source tank goes all the way well below the 12.5k equilibrium with the other tank, and drops to around 1-2k fluid before rising again to around 20k, back and forth until it stabilizes. It feels like there is a PID unwinding a large integral portion.

I see it is not at all working as expected. This may need some research to get right, and it might not even be possible.

However, as it is, this mod is currently boosting those who increase their UPS and hurting those who decrease it. Alot. I suggest that you speed up liquids when decreasing UPS and keep it as it is when increasing UPS (which by default is speeding them up).

My suggestion is if UPS > 60, then use "No scale" and if UPS < 60, then use "Full scale" or at the very least "Half scale", that way people who want to use this mod to work around the performance limits won't be forced to rework all their fluid systems.

A bug I've found with very low target FrameRates:

When Biters die, there's this fountain of blood animation.

At targets of 12, 15, and 20 that animation never goes away. It just hangs in the air spurting blood forever.

It doesn't happen with a target of 24.

I think the reason this doesn't work perfectly is that base_area affects throughput on it's own (for pipe distance >1), this is probably also the reason why this massively reduces throughput at higher then normal UPS. Basically having higher base area works conceptually like having a longer pipe (just that it's in one entity/fluid box and therefore dosn't work exactly the same).

Not sure if there's a proper way to fix you'd have to fully understand the math that goes into how fluids work to know, it might be possible to compensate and only adjust the values by a certain amount to get the correct results. It may also just be impossible to get perfect results as the perfect adjustment to get the same capacity in throughput for for example length 5 pipes may still lead to wrong results for longer or shorter pipes. This PDF apprently explains all the math behind fluid mechanics, but I'm personaly to stupid to undertand it: https://drive.google.com/file/d/0B7aC5kj-I9vldVNEdlZqS3Iwdmc/view?resourcekey=0-ky-J4ptGR7Oib000F1JYrA

I think one other solution would be to adjust the required/produced fluid amount for recipes (so for 120 UPS everything is takes and produces twice as much fluid and for 30 everything produces/consumes fluid at half rate) instead of changing pipe flow.