smart/filter inserter filter slots ('filter_count') >5

[robertpaulson]

hi.

Is it possible to have more than 5 filter slots for these?
is there a mod that handles it? all mods i came across deal with the 0-5 range.

i tried looking for the string of the exception that is thrown (it is a custom string) when the 'filter_count' is set to >5 in all game files but could not find anything and therefore i am not sure where this check/limit is enforced...

a different idea on how to locate/override it would also help since this was the only thing i could think of

-cheers, RP

edit:spelling

[Bilka]

The limit to 5 filters is enforced in the C++ part of the game. You cannot override the limit.

[robertpaulson]

The limit to 5 filters is enforced in the C++ part of the game. You cannot override the limit.

ooooof ok, thanks for the heads up, and VERY quick response!

back to the drawing board of my circuit network then!

[bobingabout]

I think someone should ask the question.

Is there any reason why the C code enforces a 5 filter limit? would there be any performance loss if the filter wasn't enforced under normal (non-modded) operation?

Because, seriously, are there any modders out there who have modded inserters that haven't tried to increase the filter slots count? It would be nice to set a tier 2 filter inserter to 12 for example, because that's how many request slots there are on a requester chest.


EDIT: I looked it up myself. It's not a vector, it's an array of 5, which exists no matter what you set the count to. However, load/save does store the number of filters set for a filter type into the save data before the filters themselves.
From the load/save perspective, filters limit doesn't matter, it would work if you set it to 255. from the internal functionality perspective on the other hand, there's advantages to using an array over a vector (call time), but there's also the disadvantage that it takes the memory space for a full 5 filters no matter how many you use, but there's also an advantage for using a vector instead, in theory a vector would take no extra RAM if it isn't used.

also, why is it referred to as insert_position in inserter_prototype and data phase but drop_position in the entity and game phase? Seriously, I thought it was just an inconsistency in the modder intractable code, but the modable code reflects the inconsistency of the internal code.

So, I guess my question still stands. Is there any reason why the C code enforces a 5 filter limit? replacing the 5 entry array with a vector is likely going to make... pretty much no difference, there'll be a tiny loss in performance for filter inserters, but a tiny memory benefit for non-filter inserters.

[DaveMcW]

I would guess because 5 filters are "free" when you fetch memory in 16-byte chunks. Any more requires an extra fetch operation which doubles the processing time. Fetch operations are the bottleneck.

[Rseding91]

There are a few reasons why it's limited to 5 maximum:

The filters are implemented as an array on the Inserter entity. That means that when the inserter is allocated the filters are in the same memory block as the inserter. In the base game this gives a large performance boost from not having to go touch other places in memory to check filters on a filter inserter. The filters take up 10 bytes of space inside the entity compared to making the number of filters dynamic which takes up 24 bytes by default + how ever many filters the inserter may have.

So, to make the count dynamic it automatically makes it take more memory + makes it slower because it has to go touch other locations in memory to check filters. Inserters are the top CPU consuming entity in the game at the moment and I'm not about to make them consume more just for mod support when the base game wouldn't benefit.

If at some point in the future we change our minds on this that's most likely what will happen (make them dynamic) but I highly doubt that's going to happen.

[bobingabout]

Well, I didn't actually look at how big a filter was, so if the array takes 10 bytes total, that's 2 bytes for a filter. pretty small thing. so, forgive my error in assuming a vector would take less space.