[Rseding] [1.1.35] Many odd issues around request slots (including documentation)

Post Reply
Filter Inserter
Filter Inserter
Posts: 798
Joined: Thu Oct 03, 2019 7:10 am

[Rseding] [1.1.35] Many odd issues around request slots (including documentation)

Post by Honktown »

To start off, gathering some information:

wiki link to Logistic Chests

Code: Select all


Type: uint16
The number of request slots this logistics container has. Requester-type containers must have > 0 slots and can have a maximum of 1000 slots. Storage-type containers must have <= 1 slot. 

Code: Select all

request_slot_count :: uint [Read-only]

The index of the configured request with the highest index for this entity. This means 0 if no requests are set and e.g. 20 if the 20th request slot is configured. 
LuaEntityPrototype filters

Code: Select all

filter_count :: uint [Read-only]

The filter count of this inserter, loader, or logistic chest or nil. For logistic containers, nil means no limit. 
LuaEntity set (and get) request slots

This information is very mis-matched. I'm going to go by vanilla chests, since I haven't tested all possibilities yet (chests with fewer than 20 slots, chest with 1000 slots)

First problem: There was a change to request slots, so that they start with 20 shown on requesters/buffers, 40 on characters, and expand to many. This means how many max a prototype has is lost... unless (Third) applies. The reason I suspect it could apply, is because it mentions more than one for logistic containers. Logically speaking, storage containers have 0 or 1 filter, so "filter" must mean request slots? Except it returns nil. Not 1000 as the prototype says, unless "no limit" == 1000, which is an odd meaning of "no limit". I understand there needs to be some limit, and 1000 is about 1024 and "big enough". An explicit value could go there, though. If it applies in the first place, to all logistic chests.

Fifth information:
get_personal_logistic_slot, via LuaPlayer

Code: Select all

get_personal_logistic_slot(slot_index) → PersonalLogisticParameters

Sets the personal request and trash to the given values.

slot_index :: uint: The slot to get.
Note: This will silently return an empty value (.name will be nil) if personal logistics aren't researched yet.
The description is wrong, but the function otherwise works fine, right? ...except a character is what possesses the personal logistics behavior, not the player. This leads to an odd bug:

If the character is not attached to the player, the requests can't be interacted with... kind of. One can call get_request_slot on it, and receive an "old" / wrong request looking stack, a table of item and count. This is the same as requester chests, except it's from the character. Writing this table (past the end) causes a temporary glitch. The character entity reports the last_request_slot as the written slot. But getting the slot returns nil. If a player used their own attached player.character or re-assigned the character from a different one, the player can open their character and see the request slot has nothing, but the entity bug is still present. One has to assign a new slot (anywhere?), or clear a used slot (anywhere?), and then the last_request_slot is fixed. If the last_request_slot is beyond the written to index, nothing happens. The slot written to is not cleared, no log/print, etc.

With set_personal_logistic_request(), I hadn't considered the effect of a repeated request (which normally is a flying-text error). If the duplicate request is written before the existing index, it will clear a slot and not be in that slot. If the duplicate request is written after, it moves from where it started. No glitch happens.

Double-checking requester chests: they have the same behavior as the character, with glitchy assignments if a duplicate request is set beyond the existing count. Using a non-duplicate item stack works fine for both requests chests AND characters, though I'd believe there's no way to set an upper limit of items on a character entity without being attached (not an API request, only a statement).
I have mods! I guess!

Post Reply

Return to “Assigned”