Paradise Island is not being deleted after all

[Vectorspace]

When the devs first announced update 6 or 7 (I forget which) they said that Paradise Island (the land mass to the south west at the edge of the world with nothing on it) would be removed.

Jace has announced on stream that due to player feedback, the plan has changed and the island will be kept. It will not be improved in any way, but the world border kill zone will be extended so that the entire island is safe to walk on.

https://youtu.be/oHHr-VYsx0k

[curtyuiop]

Well that's cool because I like it.

[Die Hand Gottes]

Super then I can build on it what I had planned

[Omega420]

I'm curious if porting to UE5 would fix the belt rounding issues any/or offer a better solution to the issue.

[Wolfgang]

That's great! I love that nice backdrop of my HUB.

[Wolfgang]

Originally posted by Omega420:

I'm curious if porting to UE5 would fix the belt rounding issues any/or offer a better solution to the issue.

Unlikely. That is a precision issue which is something of how computers work. So it can not be fixed really.

[Stellar Remnant]

Originally posted by Wolfgang:

Originally posted by Omega420:

I'm curious if porting to UE5 would fix the belt rounding issues any/or offer a better solution to the issue.

Unlikely. That is a precision issue which is something of how computers work. So it can not be fixed really.

The fastest belts in Satisfactory are 780 items per minute, or 13 per second. Factorio manages to have belts of 45/s (22.5/s per lane), or 2700 per minute.

Somehow I doubt it's 'precision issues'.

[Wolfgang]

Originally posted by MiniHerc:

Originally posted by Wolfgang:

Unlikely. That is a precision issue which is something of how computers work. So it can not be fixed really.

The fastest belts in Satisfactory are 780 items per minute, or 13 per second. Factorio manages to have belts of 45/s (22.5/s per lane), or 2700 per minute.

Somehow I doubt it's 'precision issues'.

See here:
https://youtu.be/zQp4XNB2bU4?t=18
Jace stated that there is a precision issue and I can pretty much confirm that. One of my machines was losing plastic over time even though it should get exactly enough plastic to do the task. And it was not an issue with the refineries as they are all full on crude oil and there is no backup of the residue or the plastic itself. I was losing 0.08 plastic per min or about 10 in 2 hours. And that is on a MK3 belt.

Edit: And here from Snutt:
https://www.youtube.com/watch?v=x2VBWUAqpoQ

[ShadowMystic]

Originally posted by Wolfgang:

Originally posted by MiniHerc:

The fastest belts in Satisfactory are 780 items per minute, or 13 per second. Factorio manages to have belts of 45/s (22.5/s per lane), or 2700 per minute.

Somehow I doubt it's 'precision issues'.

See here:
https://youtu.be/zQp4XNB2bU4?t=18
Jace stated that there is a precision issue and I can pretty much confirm that. One of my machines was losing plastic over time even though it should get exactly enough plastic to do the task. And it was not an issue with the refineries as they are all full on crude oil and there is no backup of the residue or the plastic itself. I was losing 0.08 plastic per min or about 10 in 2 hours. And that is on a MK3 belt.

Edit: And here from Snutt:
https://www.youtube.com/watch?v=x2VBWUAqpoQ

It is a FP(floating-point i.e. decimals) precision issue specifically with the game/engine not because it is "how computers work."

Otherwise, scientific research with computers would be impossible.

More specifically, what's probably happening is that, per tick ,they need to be able to add/multiply n.123456789, but they game engine rounds/truncates it to n.123456. This isn't a problem when a belt/pipe only moves a few times, but that per-tick rounding error compounds at higher and higher speeds.

Factorio is probably coded specifically maybe even a custom engine to handle the ensure their floating-point calculations have enough precision.

[ShadowMystic]

Originally posted by MiniHerc:

Originally posted by Wolfgang:

Unlikely. That is a precision issue which is something of how computers work. So it can not be fixed really.

The fastest belts in Satisfactory are 780 items per minute, or 13 per second. Factorio manages to have belts of 45/s (22.5/s per lane), or 2700 per minute.

Somehow I doubt it's 'precision issues'.

It is a precision issue. Factorio uses a custom engine written in C++ which probably is built to handle the issues.

[LittleEngineer]

Originally posted by ShadowMystic:

It is a FP(floating-point i.e. decimals) precision issue specifically with the game/engine not because it is "how computers work."

Otherwise, scientific research with computers would be impossible.

More specifically, what's probably happening is that, per tick ,they need to be able to add/multiply n.123456789, but they game engine rounds/truncates it to n.123456. This isn't a problem when a belt/pipe only moves a few times, but that per-tick rounding error compounds at higher and higher speeds.

Factorio is probably coded specifically maybe even a custom engine to handle the ensure their floating-point calculations have enough precision.

Floating point numbers in computers have both a single-precision (32 bit variable) and a double-precision (64 bit variable) variant.

The precision of the floating point numbers can be affected (depends on contained number) when a double-precision FP number is cast to a single-precision FP number, but the precision is ultimately related to how computers work.

Please have a look at this Microsoft page as it has a lot of information related to FP precision: https://learn.microsoft.com/en-us/office/troubleshoot/access/floating-calculations-info

But here is a small part of the page anyway:

There are many situations in which precision, rounding, and accuracy in floating-point calculations can work to generate results that are surprising to the programmer. They should follow the four general rules:
[li]

• In a calculation involving both single and double precision, the result will not usually be any more accurate than single precision. If double precision is required, be certain all terms in the calculation, including constants, are specified in double precision.
  
  
• Never assume that a simple numeric value is accurately represented in the computer. Most floating-point values can't be precisely represented as a finite binary value. For example, .1 is .0001100110011... in binary (it repeats forever), so it can't be represented with complete accuracy on a computer using binary arithmetic, which includes all PCs.
  
  
• Never assume that the result is accurate to the last decimal place. There are always small differences between the "true" answer and what can be calculated with the finite precision of any floating point processing unit.
  
  
• Never compare two floating-point values to see if they are equal or not- equal. This is a corollary to rule 3. There are almost always going to be small differences between numbers that "should" be equal. Instead, always check to see if the numbers are nearly equal. In other words, check to see if the difference between them is small or insignificant.[/li]

Another interesting page regarding loss of precision: https://blog.demofox.org/2017/11/21/floating-point-precision/

And if you are interested in an article from a scientific standpoint: https://www.researchgate.net/publication/3422752_High-Precision_Floating-Point_Arithmetic_in_Scientific_Computation#read

This article was published in 2004 so the information may not be accurate for the current times:

At the present time, IEEE 64-bit floating-point arithmetic is sufficiently accurate for most scientific
applications. However, for a rapidly growing body of important scientific computing applications, a higher level of numeric precision is required: some of these applications require roughly twice this level; others require four times; while still others require hundreds or more digits to obtain numerically meaningful results. Such calculations have been facilitated by new high-precision software packages that include high-level language translation modules to minimize the conversion effort. These activities have yielded a number of interesting new scientific results in fields as diverse as quantum theory, climate modeling and experimental mathematics, a few of which are described in this article. Such developments suggest that in the future, the numeric precision used for a scientific computation may be as important to the program design as are the algorithms and data structures.

[ShadowMystic]

Originally posted by LittleEngineer:

Originally posted by ShadowMystic:

It is a FP(floating-point i.e. decimals) precision issue specifically with the game/engine not because it is "how computers work."

Otherwise, scientific research with computers would be impossible.

More specifically, what's probably happening is that, per tick ,they need to be able to add/multiply n.123456789, but they game engine rounds/truncates it to n.123456. This isn't a problem when a belt/pipe only moves a few times, but that per-tick rounding error compounds at higher and higher speeds.

Factorio is probably coded specifically maybe even a custom engine to handle the ensure their floating-point calculations have enough precision.

Floating point numbers in computers have both a single-precision (32 bit variable) and a double-precision (64 bit variable) variant.

The precision of the floating point numbers can be affected (depends on contained number) when a double-precision FP number is cast to a single-precision FP number, but the precision is ultimately related to how computers work.

Please have a look at this Microsoft page as it has a lot of information related to FP precision: https://learn.microsoft.com/en-us/office/troubleshoot/access/floating-calculations-info

But here is a small part of the page anyway:

There are many situations in which precision, rounding, and accuracy in floating-point calculations can work to generate results that are surprising to the programmer. They should follow the four general rules:
[li]

• In a calculation involving both single and double precision, the result will not usually be any more accurate than single precision. If double precision is required, be certain all terms in the calculation, including constants, are specified in double precision.
  
  
• Never assume that a simple numeric value is accurately represented in the computer. Most floating-point values can't be precisely represented as a finite binary value. For example, .1 is .0001100110011... in binary (it repeats forever), so it can't be represented with complete accuracy on a computer using binary arithmetic, which includes all PCs.
  
  
• Never assume that the result is accurate to the last decimal place. There are always small differences between the "true" answer and what can be calculated with the finite precision of any floating point processing unit.
  
  
• Never compare two floating-point values to see if they are equal or not- equal. This is a corollary to rule 3. There are almost always going to be small differences between numbers that "should" be equal. Instead, always check to see if the numbers are nearly equal. In other words, check to see if the difference between them is small or insignificant.[/li]

Another interesting page regarding loss of precision: https://blog.demofox.org/2017/11/21/floating-point-precision/

And if you are interested in an article from a scientific standpoint: https://www.researchgate.net/publication/3422752_High-Precision_Floating-Point_Arithmetic_in_Scientific_Computation#read

This article was published in 2004 so the information may not be accurate for the current times:

At the present time, IEEE 64-bit floating-point arithmetic is sufficiently accurate for most scientific
applications. However, for a rapidly growing body of important scientific computing applications, a higher level of numeric precision is required: some of these applications require roughly twice this level; others require four times; while still others require hundreds or more digits to obtain numerically meaningful results. Such calculations have been facilitated by new high-precision software packages that include high-level language translation modules to minimize the conversion effort. These activities have yielded a number of interesting new scientific results in fields as diverse as quantum theory, climate modeling and experimental mathematics, a few of which are described in this article. Such developments suggest that in the future, the numeric precision used for a scientific computation may be as important to the program design as are the algorithms and data structures.

I think you meant to reply to someone else because... you don't need to explain floating-point to me. Much of what you shared supports what what I said: it isn't something that's unfixable because 'computers.'

[mansman]

Why would they be using floating point numbers during the simulation portion of moving whole numbers of items around? The only time you have partial items during the simulation is in input and output buffers of production or consumption machines depending on recipe or clocking adjustments. There are several C++ libraries that offer functionality similar to Java's BigDecimal implementation. You basically store the remainders as whole numbers including a decimal shift. There should never be item loss during the simulation.