Quick-deliver unity costs excessively high as of 4.1 update

I'm seeing a significant increase in quick-deliver costs across blueprints from yesterday to today. Blueprints that previously cost 30-40 are now routinely requiring hundreds of unity. This change is not reflected in the patchnotes if intentional (and I doubt it was, as I am unable to create even modest blueprints with a normal unity cap).

Do you have a specific example?

here

Can you share the BP?

testmap, default settings. (captain)

yep

want the save too?

Doesn't hurt, thank you

and a reddit post about this:
https://www.reddit.com/r/captain_of_industry/comments/1snyg5j/quick_delivery_costs_are_magnitudes_higher_after/

Yours or from someone else?

someone else

Saw the discord message, tested it, found similar result

I was noticing this also after switching to experimental this week, no hard comparison but found that unity building was leaving me drained

I can't find anything new from 4.1, maybe it's from an "old" change from U3 (0.7.7):

Removed quick-delivery discount for large quantities. The cost is now linear with the number of quick-delivered products, at 0.05 unity per product.

OK, Math checks out in my blueprint

ty!:)

i think there IS something weird going on with the unity cost of rail construction using the quick build tool, specifically

No it seems to be correct:
(100 + 100) * 0.05 = 200 * 0.05 = 10 ~~ 9.96.
And the "rounding error" might be down to the use of
the Mafi.Fix32 type during the calculations.

drtbg [discord] wrote:

i think there IS something weird going on with the unity cost of rail construction using the quick build tool, specifically

Here's an explanation for the calculation error:
The Mafi.Fix32 type is just an implementetion
of a 1.21.10 fixed-point number (where the top-most bit
is used for the sign, like it is used for just about every common
number representation, then 21 bits for the integer part
and the last 10 for the fractional part), so the smallest
representable number change is as much as 1/1024.

Since were being asked to store 0.05 in a Mafi.Fix32,
then the internal value would get set to the integer 51,
which when converted back is exactly 0.0498046875;
which when multiplied by 200 would be exactly 9.9609375.

And the rest is just rounding to a specific number of decimal places.

Perhaps this is a significantly over-engeneered solution to this problem,
but perhaps something like this could work (other than swapping to a type
that can store this more precisely, or hardcoding the path from the following
code snippet that would get chosen (a.k.a. the middle if statement)): cs public readonly struct Multiplier { public readonly Func<Fix32, Fix32> Apply { get; } public Multiplier(float value) { if (value.ToFix32().Abs() < Fix32.Epsilon) { Apply = (val) => Fix32.Zero; return; } if (value.Abs() < 1f) { var m_value = (1f / value).ToFix32(); Apply = (val) => val / m_value; return; } { var m_value = value.ToFix32(); Apply = (val) => val * m_value; } } }