Seems to be a rounding error. A new machine filled up will use all soft tissue, output 20 refined eitr, and have >1 sap left (that is, a decimal value) that displays as 1. If you fill the machine again it will look like it has 20 sap but it's really 19.whatever sap. Once the machine starts again it will almost immediately go to 19 sap and you can put the 20th in.

Originally posted by Pat Fenis:

Seems to be a rounding error. A new machine filled up will use all soft tissue, output 20 refined eitr, and have >1 sap left (that is, a decimal value) that displays as 1. If you fill the machine again it will look like it has 20 sap but it's really 19.whatever sap. Once the machine starts again it will almost immediately go to 19 sap and you can put the 20th in.

Because there's currently a fascination with using floats for things that should be whole numbers? I can see that it avoids the whole "having to keep a separate 'timing' variable" issue, while keeping track of "partial" task completions... but it's using the memory space anyway, so it might as well be a pair of ints... or a pair of bytes, for that matter. Although to be fair, we don't actually use bytes any more... machines have memory measured in GB instead of MB, these days (and storage is measured in TB), so why not waste 87.5% of the resources?

I don't think anyone actually cares whether a 40-second process is 6% complete or 6.1892567% complete, but there it is.

This is happening to me as well. I would move this discussion to Report a Bug section.

this is NOT a bug. this is intentional. sometimes 1 sap remains sometimes 1 soft tissue. its happening simply because the machine is UNSTABLE. devs said so themselfs.