Inserter (Stack or Not) Should not be Limited to 254.0

[Murez]

In this current version, inserter's capacity bonus is limited to 254.

So, please don't restrict its value.

[FuryoftheStars]

Hmm, that sounds like they restricted it to 1 byte of data. They may have done this for memory reasons, similar to tile IDs.

[mrvn]

I wonder what 0 and 255 is used for then.

[FuryoftheStars]

I wonder what 0 and 255 is used for then.

Hmm, I wonder if they actually use 0 & 1 for disabled/enabled, then use the remaining 254 for stack size? Would save a small bit of memory.

[mrvn]

I wonder what 0 and 255 is used for then.

Hmm, I wonder if they actually use 0 & 1 for disabled/enabled, then use the remaining 254 for stack size? Would save a small bit of memory.

Then how would you disable a 200 stack size inserter? Disabling would overwrite the stack size.

If they used the first bit then max size would be 127 or 128.

[FuryoftheStars]

I wonder what 0 and 255 is used for then.

Hmm, I wonder if they actually use 0 & 1 for disabled/enabled, then use the remaining 254 for stack size? Would save a small bit of memory.

Then how would you disable a 200 stack size inserter? Disabling would overwrite the stack size.

If they used the first bit then max size would be 127 or 128.

I wasn’t thinking of the bits, but yeah, what was going through my head I don’t think is possible.



Hmm, well, 0 at least can be explained not being used by stack size as that’s essentially the same as disabling it. Not sure about 255, though.

[mrvn]

I wonder what 0 and 255 is used for then.

Hmm, I wonder if they actually use 0 & 1 for disabled/enabled, then use the remaining 254 for stack size? Would save a small bit of memory.

Then how would you disable a 200 stack size inserter? Disabling would overwrite the stack size.

If they used the first bit then max size would be 127 or 128.

I wasn’t thinking of the bits, but yeah, what was going through my head I don’t think is possible.



Hmm, well, 0 at least can be explained not being used by stack size as that’s essentially the same as disabling it. Not sure about 255, though.

People that squish such numbers into bytes also tend to special case unused numbers to mean something else. Or offset all values. So 0 could mean 256 or stack size - 1 is stored.

[Murez]

https://ibb.co/sqZDHJt

I don't think so, the field in the LuaForce class has uint data type.
It holds 32-bit unsigned integer. Possible values are 0 to 4,294,967,295.

So, it should be restricted in the code by conditional flow.

[mrvn]

That's the LUA interface and in no way means the C++ type is an uint32_t.

[Murez]

Can the property be changed? so it can store a larger value.

I'm struggling to flush the output out of the furnace/assembling machine using the inserter, due to its high productivity (mods' effect).
Imagine the property of worker robots storage bonus is not limited, but why not with the inserter capacity bonus?

It creates a perfect imbalance.

[SoShootMe]

I wonder what 0 and 255 is used for then.

It makes some sense to use 8 bits to store the set stack size of an inserter instance, since there are typically many of them. Same goes for items currently in the inserter's hand.

There surely needs to be a value to indicate "unset" or "max", ie use stack size according to prototype and inserter capacity bonus. I can't see why any other value is reserved though. Perhaps it's hysterical raisins.

Imagine the property of worker robots storage bonus is not limited, but why not with the inserter capacity bonus?

Worker robots don't store a cargo size (only held item count), and perhaps the expectation is there will be fewer active bots, so the benefit of reducing stored size is less.

[Murez]

Worker robots don't store a cargo size (only held item count), and perhaps the expectation is there will be fewer active bots, so the benefit of reducing stored size is less.

Its the property name in LuaForce class by the way (Factorio API docs).
It's talking about handling massive items and bottleneck occurs because of the inserters.

[SoShootMe]

Its the property name in LuaForce class by the way (Factorio API docs).
It's talking about handling massive items and bottleneck occurs because of the inserters.

inserter_capacity_bonus and stack_inserter_capacity_bonus are LuaForce properties but maximum values are also limited by per-entity state (eg "items in hand" and "stack size override"), and it seems almost certain this is limited to eight bits.

To go back to your earlier post:

Can the property be changed? so it can store a larger value.

It's likely it could be increased, but I expect it won't be for several reasons, such as the fact that (due to the above) allowing a greater maximum would increase the overall memory requirements by an amount proportional to the number of inserters.

[FuryoftheStars]

Yup, just like the tile ID limit situation. They're not going to blow up memory consumption of the game to accommodate mods (and I don't blame them).

[Murez]

I agree. But, why worker_robots_storage_bonus can be updated up to 65535.0?
I think, increasing the number of robots drastically decreases UPS/FPS performance compared to inserters.

[mrvn]

Because bots do not store the storage size. There is no cost per bot for the worker_robots_storage_bonus.

As to why they can actually carry that many items that is probably because they have a standard inventory and not their own internal counter for items. Restricting all inventories to 255 items per slot would be bad.

[ssilk]

One question: WHY is it needed?

I have different ideas about the why, I want to know it from the source.