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

[Honktown]

To start off, gathering some information:

First:
wiki link to Logistic Chests

Code: Select all

max_logistic_slots

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. 

Second:
(LuaEntity)

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. 

Third:
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. 

Fourth:
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.

Parameters
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).

[Rseding91]

I've read this through 3~ times now but I'm having a hard time pinpointing what things you think are broken.

Can you give a list in the format of:

A: *What it does now*
B: *What you think it should do*

[Honktown]

I've read this through 3~ times now but I'm having a hard time pinpointing what things you think are broken.

Can you give a list in the format of:

A: *What it does now*
B: *What you think it should do*

1. Writing a request with a duplicate name to an index greater-than the last used request slot changes the request_slot_count, even though it fails. Set a request in slot one of a requester and run these commands:

entity requests

Code: Select all

/c
local player = game.player
local selected = player.selected

local request_one = selected.get_request_slot(1)
game.print("Request slot 1: "..serpent.line(request_one))
local result = selected.set_request_slot(request_one, 5)
if result then
	game.print("result positive")
	for i=1, selected.request_slot_count do
		local request = selected.get_request_slot(i)
		if request then
			game.print("Request slot "..i..":"..serpent.line(request))
		end
	end
else
	game.print("result negative")
end
game.print("slot count after: "..selected.request_slot_count)

The request_slot_count changes. From the API for 1.1.36:

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.

/c
local player = game.player
local selected = player.selected
local last_slot = selected.request_slot_count
game.print("Highest configured slot: "..last_slot)
local last_request = selected.get_request_slot(last_slot)
game.print("last slot contents: "..serpent.line(last_request))

What I'd expect: Not 5. Not nil. If request_slot_count is greater than 0, then get_request_slot(request_slot_count) should always be a table of a request. An additional note is clearing a logistic slot with right click or clear_request_slot(N) does seem to update the index.

Continued in next post, because sending that post off to modding api may be a better use of it.

[Honktown]

In the context of requesters/storage chests and potential modding issues to minor gripes (note: not bugs):
2) most of the other issues are documentation or API behavior...
With respect to prototypes, filter_count is nil for requesters if un-set, but defaults to 1000. Just tested with a request with 1 slot and 0 slots, it is accurate. ...and then for storage chests always returns nil. Setting a requesters slot >1000 always returns failure, though 1001-65535 is accepted. Minor gripe (an error because it can't succeed would be relevant).

A storage chest without the optional max_logistic_slots: Error while running setup for entity prototype "logistic-chest-storage" (logistic-container): A storage-type chest can't have more than 1 request slot. I can document this on the wiki, but it'd be nice to have a better explanation of what should be happening (better error message? was supposed to be optional but isn't? ???).

Minor gripe but relevant to the bug: setting personal request slots via the player behaves a little differently than setting the entity request slots. Clearly under normal conditions, only the character, via the player, would be expected to have minimum and maximum apply to logistic requests, but the odd bug with setting a duplicate entity request does not exist when setting a duplicate personal logistic request.

It looks like someone had modified some behavior, but it wasn't documented in the version history? A "target" logistic slot doesn't get cleared in the case of a duplicate set by set_personal_logistic_slot or set_request_slot. From what I had previously mentioned, while setting personal logistic requests that were duplicates, it did.

I hope I covered what I wanted to? Sorry for the wall of text.

[Rseding91]

Ok, the issue with the set_request_slot and duplicates changing the count of request slots is now fixed. The other issues I think might be better here 97880 otherwise I think some of them have been fixed in the meantime (the wrong entity vs player vs vehicle thing).