Relevant read:
https://www.dreamsongs.com/RiseOfWorseIsBetter.html

For reference, this is the current insertion limit calculation.


Looks like that besides some hard-coded exceptions, it's about exactly what I described, except it's for every recipes per 70 ticks instead of 60 ticks (per second).


What applications?

Helps with buffering and tight ...

Also expose it to the API, so that you can set an entity to have a custom insertion limit.

Currently, it looks like it's being calculated relatively to the entity consumption rate, and as a multiple of the recipe source item requirement, say for example if you need 1 iron and 3 wires to make an ...

Thanks for the report however I'm not seeing anything broken here. The check logic is as simple as it can be: if (surface.darkness > night_vision.darkness_to_turn_on) then it is on. That's it, that's the full logic for how this is used.


Actually, come to think of it, changing "surface.darkness ...

I know your code excepts are (obviously) consistent with the current game behavior, but can you at least try and explain/document what's happening with the LUT transition that makes it not accurately follow its formal boundaries, such that I might properly fix it by myself in lua instead of just ...

darkness has nothing to do with the LUT logic. It's just this:

float DayTime::getDarkness(double maxDarkness) const
{
if (this->position < this->dusk)
return 0;
if (this->position < this->evening)
return float(Math::min(maxDarkness, 1 - (this->evening - this->position) / (this->evening ...

Thanks for the report however I'm not seeing anything broken here. The check logic is as simple as it can be: if (surface.darkness > night_vision.darkness_to_turn_on) then it is on. That's it, that's the full logic for how this is used.


Well then, the issue is that the calculated (how ...

Setting it to 0.0 leaves in about a few seconds of transition, meaning it doesn't activate as soon as darkness begins to set, which is defined by default to be in terms of being between the 0.45 and 0.55 fraction of day-ticks.
Not exactly sure what "darkness_to_turn_on" is tuned with, or if it's ...

Looks like this issue is somehow being acknowledged at last?
Not holding my breath since they're used pretty much everywhere at this point.

Another issue to consider is, what happens when an operation should take a non-whole valued tick duration to complete? For example 60 + 1/2. At tick 60, it's not done, at tick 61, it's overshot by 1/2 tick, is this taken into account for the next cycle already?

You'll have to update it -- in this case subtract the energy consumption from the fuel value -- every tick.


But this already happens with floating-points? The actual calculation only needs to be done once, then cached, then added every tick, which is the current behavior. Rational addition is ...

q requires zero bits of storage; it's hard-coded.

That's the point of a fixed-point data type: it's functionally identical to floating-point representations, but you don't have to use any bits to store the exponent part because you fix it to a constant (in this case to -16) and never change it ...

the devs which made the game like this probably for a good reason.


There really isn't, using floating-points is not faster, and is simply less accurate, they probably defaulted to this without thinking much about it, then realized the problem by themselves while designing quality, changed the ...

48.16 means that when you write out numbers in binary notation, there are always 16 places to the right of the point and 48 places to the left of the point. (thus, the position of the point is "fixed")

That corresponds to q being hard-coded to the constant 65536 in the rational number format ...

One way to go though while technically staying at floats is to resnap it back to 1/60 grid after every +-*/, e.g. v = floor(v*60е8+0.5)/60e8


Again, this is exactly how the /= operator works, and what is effectively being used for quality effects already, which is stored as an integer at a fixed ...

Currently, only reflection is respected (line 2), but not its rotation (line 3), which is inconsistent, and makes manual placement based on ghost planning quite tedious, where you have to press Q twice between each machine, such that the previous one is deselected, then the next one is selected in ...

Example: Ctrl+S overwrites the last manual save, or makes a new one (maybe even with a different shortcut), with the same warning system (when overwriting a future save) already in-place, plus same for loading.
Not sure why this doesn't already exist, I usually have to manually navigate the save ...

Harkonnen wrote: Sat Jun 27, 2026 9:09 pm working on rational numbers in p/q format, both p and q being integers

This is exactly how "fixed-point" works. The library linked is a "48.16" implementation, meaning 48 bits for p (including 1 for parity), and 16 for q.

This is essentially correct, floating-point arithmetic has a very specific use-case,

There is also the very specific use-case of high-performance calculation, since CPUs have the floating-point logic built-in and often have a more robust suite of operations for efficiently working on floating ...

The game is not fixed at 60 ups, and machines may run faster or slower depending on beacons, modules, and available power. Functionally, these things don’t matter at scale - scale the game heavily encourages and incentivizes.


Are you just going to bury this issue even after practical solutions ...