Fit integer number of items in transport belt

[XKnight]

This suggestion comes from the irritating fact that compressed transport belt can have 3 or 4 items inside.

To solve this issue my proposal is to change distance between items (as it was already changed 0.13.3 to 0.28125):
- to 0.25 (12.5% shrinkage) => 4 items on the belt
- or 0.33(3) (18.5% stretching) => 3 items on the belt

Also, to prevent belt enhancing, yellow/red/blue belt speed should be tweaked in the same way to remain old speed in items/sec.
And mockup:

1.png (25.5 KiB) Viewed 11100 times

[gheift]

Items are 9 pixel wide, a belt is 32 pixels. If you measure 9 full compressed belts you will get 32 items.
The pssible position of the items on the belt, the * marks the middle, which is the relevant part for the measurement.
Items on the yellow belt moves 1 pixel per tick, on a red 2 pixels per tick and 3 pixels on a blue.

Code: Select all

|==============================|
<---*---><---*---><---*---><---* 4 items
><---*---><---*---><---*---><--- 3 items
-><---*---><---*---><---*---><-- 3 items
--><---*---><---*---><---*---><- 3 items
---><---*---><---*---><---*--->< 3 items
*---><---*---><---*---><---*---> 4 items
-*---><---*---><---*---><---*--- 4 items
--*---><---*---><---*---><---*-- 4 items
---*---><---*---><---*---><---*- 4 items

[ssilk]

Not sure if I like this. The size of the items can have a deep game-impact! The throughput is for example much higher, you can store more items on a belt etc.

And it looks ugly.

Before that I would like to see that as mod (a simple loop over all items and change the item size).

EDIT: To measure if a belt is fully compressed I think it takes a bit more work. For example take more belts: Two belts double the precision.

A much better idea would be to measure the number of items that are running through for one belt loop (1 tile, from input side to output side).
Indeed it would be a very helpful extra value, if the belt outputs an impulse for each "rotation". That depends on the belt-speeds and is also a very "uneven" number, but internally it needs to output just this impulse and all you need it to count the number of items for each tick, which are on the belt.

[bobucles]

Perhaps the sensor should itself be larger, or perhaps stretchable in some way? For example if it was like an underground belt you could reach a higher level of precision without allowing outside interference to mess things up.

[ssilk]

That's what I said. Just connect more sensors. They will be added if connected together.
Or count over time, which is the second option to get more precision.

[Rseding91]

Item positions on belts are floating point values. The distance between is a floating point value. You're never going to have a perfect world when an item can be some float value apart from another item.

[bobucles]

Item positions on belts are floating point values.

Curious about this one. With a 64bit integer you can count every single millimeter between the core of the earth's sun and pluto. 128bit floating point can't even reach past the sun's corona before losing accuracy. The vast majority of a float's exponential range is basically meaningless as you're only using the values across a handful of magnitudes.

What level of accuracy is really important to process location information? Anything beyond 1/xx of a pixel is getting pretty pointless. Even the float calculations must have some level of give to consider something "close enough".

[ssilk]

Curious about this one.

Answer: 8 values per pixel.

from https://www.factorio.com/blog/post/fff-64

The first step I'm currently experimenting with is using the fixed-point float numbers for in-game positions. Currently we use the double type for coordinates of the position, which takes 8 bytes per value, and doesn't really follow our needs as well, as it is very (wastefully) precise around the center of the map, and the precision gets smaller the further you are (double format). The solution is to use 4 byte number for the position coordinates, 3 bytes for the integral part and 1 byte for the fractional part. The precision is still good enough for any practical ingame use (8 values per pixel), and the span will be kept reasonable big -2^23 to 2^23 which is above 8 million tiles. I made special huge save for testing, and the size reduction using this technique was 27% of the zipped file. The good thing is, that this also reduced the memory requirements and enhances the cache locality, so the performance is increased (very slightly) as well. There are more quite simple tricks we would like to use to reduce the savegame to half of what it is now.

The good question is of course: How much is one pixel?

[lpw]

[...] the fixed-point float numbers [...]

An even better question, what is a fixed-point float number?

[ssilk]

No, it's not a good question, cause you can answer it yourself.
https://en.wikibooks.org/wiki/Floating_ ... nt_Numbers

[TheSkiGeek]

No, it's not a good question, cause you can answer it yourself.
https://en.wikibooks.org/wiki/Floating_ ... nt_Numbers

I think his point is that "fixed-point" and "floating-point" numeric types are mutually exclusive, so a "fixed-point float" makes no sense. It should be "fixed-point fractional number".

[lpw]

No, it's not a good question, cause you can answer it yourself.
https://en.wikibooks.org/wiki/Floating_ ... nt_Numbers

With the answer "it doesn't exist"?
(The Page is called "Floating Point/Fixed-Point Numbers" but instead of explaining the difference only explains Fixed-Point Numbers)

Edit: Got ninjaed there, but yeah, that's basically my point.

[ssilk]

No, it's not a good question, cause you can answer it yourself.
https://en.wikibooks.org/wiki/Floating_ ... nt_Numbers

I think his point is that "fixed-point" and "floating-point" numeric types are mutually exclusive, so a "fixed-point float" makes no sense. It should be "fixed-point fractional number".

Hm, yeah, obviously. I just used the devs terms. I think "float" is used, because the numbers must be uses like floats. There is no real difference. It's the same as with decimal numbers: you can calculate with both numbers, and they (fixed point and floating point) behave both like floats.

[ross]

how do you change the distance between items on a belt? I can't find anything in the prototypes files.

[ssilk]

If you look above you can see, why. posting.php?mode=reply&f=6&t=29414#pr186263

See also https://wiki.factorio.com/Transport_bel ... s_yourself

[Hannu]

Curious about this one. With a 64bit integer you can count every single millimeter between the core of the earth's sun and pluto. 128bit floating point can't even reach past the sun's corona before losing accuracy. The vast majority of a float's exponential range is basically meaningless as you're only using the values across a handful of magnitudes.

You have some error in that calculation. Mantissa of 64 bit double have 53 bits. It gives resolution of about 0.5 mm at the distance of Pluto. I made once a simple space flight game and it was a problem when I tried docking operations on orbit of outer planets (few cm/s relative speed between crafts and 60 fps). I had to made a shrinked fictive solar system because I did not want to make strange coordinate transformations.

It is probably very bad idea to use fixed point numbers. Current processors have very fast floating point arithmetic for 64 bit doubles. Integers would probably have a negative effect to execution speed. Especially because there are certainly not anything in Factorio which needs more than 53 bit resolution in calculations.

[BenSeidel]

It is probably very bad idea to use fixed point numbers. Current processors have very fast floating point arithmetic for 64 bit doubles. Integers would probably have a negative effect to execution speed. Especially because there are certainly not anything in Factorio which needs more than 53 bit resolution in calculations.

Nope, Integers are far faster than floating points. Why? Because of the space requirements. With an integer, you don't have to use a full 32 or 64 bits to store the value, just the minimum number of bits. With a float you are stuck with the full 32, 64 or 128 bits. This way you can squash your application's memory into a smaller footprint reducing the number of cache misses. The amount of code required to mask and shift the bits is only 2 instructions, but when iterating over 100's or 1000's of entities, it's an extremely significant reduction in memory.

I'm fairly certain that nothing in factorio would need an integer resolution past 16 bits, with most hovering round the 8 bit mark, so using 64 bits or even 32 bits for a float or double is still halving your performance at best.

[ssilk]

Ben, you have a talent: bringing discussions to off-topic.

[BenSeidel]

Ben, you have a talent: bringing discussions to off-topic.

Yes, I know
-50 rep for me.

[MeduSalem]

Ben, you have a talent: bringing discussions to off-topic.

Well we could rename the thread into "Can Factorio run solely using Integer numbers instead of Floating Point numbers?"

Integers will always perform faster... single-cycle instructions vs multi-cycle instructions (even modern Intel CPUs can't do all FP arithmetic in a single cycle. Official Reference Manual, Appendic C.). But that said even if the entire game would be able to use Integer... then you waste possible CPU resources if the FPU never gets to do anything. So a good program first of all uses the correct data type for the required precision and if that's not important then you still have some obligation to use available CPU power to your advantage even if you misused the resources.



At least I don't think that XKnights suggestion of having a constant integer value of items on a single belt tile is possible from a hypothetical perspective even if the item distance was adjusted to be conform with a belt tile length... there'd still be the moment when there are 4 items on the tile and the moment when there are only 3 items on the tile.

Maybe if the belt-motion was step-wise (like in Big Pharma or something) then you'd always have a fixed amount of items on a tile... but not with constant motion like in Factorio.