Describe

removeItemFromPlayer and removeItemFromPlayerNBT seemingly always take from the first occupied slot in the players inventory regardless of the arguments specified. either that or absolutely nothing happens.

according to the documentation:
removeItemFromPlayer(direction: string, count: number[, slot: number, item: string])
where "direction" is the relative location of the container to place the items
"count" is the maximum amount it items to take
and "slot" is the slot to take items from in the player's inventory

Therefore:
inventoryManager.removeItemFromPlayer("south", 64, 3)
should take up to 64 items out of slot 3 from the players inventory and place them in the adjacent chest located to the south.

However, this doesn't appear to be the case in practice. and it consistently takes my pickaxe from slot one (or my sword from slot 2 if there isnt anything in slot one) and places it in the chest. I understand the docs label one or the other of these methods as being deprecated so i tried the same syntax for both the NBT and non-NBT versions. I got the same exact results both times.

Here is the code i wrote in game, im hoping i made a mistake somewhere but i did double and triple check the docs.

player = peripheral.find("inventoryManager")
for _,i in pairs(player.getItems()) do 
    print(i.slot,i.displayName,i.count)
end
player.removeItemFromPlayer("south",64,3)

Steps to reproduce

1. Load Game with mods installed
2. Try to write code like what i wrote above to interface with the inventoryManager
3. run code...
4. watch in amazement as either the first slot is emptied OR absolutely nothing happens

Multiplayer?

No

Version

1.19.2-0.7.28r (Latest 1.19.2)

Minecraft, Forge and maybe other related mods versions

Forge 43.2.4 Minecraft 1.19.2

Screenshots or Videos

No response

Crashlog/log

Does not cause crash

After looking over the code i think i may have spotted the problem.
In InventoryManagerPeripheral.java: Line 114 and 129
it seems like whats happening is the "slot" argument is being assigned to the "toSlot" key in the ItemFilter
I think this line may have been copied directly from the addItemToPlayer method where this arrangement would make perfect sense.
However, In the removeItemFromPlayer method and its NBT counterpart, the "slot" argument means something completely different as it references the slot in the PLAYERS inventory, as opposed to addItem where it means the slot in the CONTAINERS inventory.
This is confirmed when manually specifying the itemfilter
removeItemFromPlayerNBT("south", 64, nil, {fromSlot=3, toSlot=0})
Will indeed take up to 64 items out of player inventory slot 3 and place it in south located chest slot 0.

If instead the "slot" argument was mapped to "fromSlot" at lines 114 and 129, then I suspect this behavior would be corrected.
Unfortunately, I'm not in a position to be able fix these couple lines of code however i do hope this has proved useful

as the doc said, remove/addItemFromPlayer is deprecated, and will be replace by the *NBT version
https://docs.intelligence-modding.de/peripherals/inventory_manager/#removeitemfromplayer

as the doc said, remove/addItemFromPlayer is deprecated, and will be replace by the *NBT version https://docs.intelligence-modding.de/peripherals/inventory_manager/#removeitemfromplayer

Yes, I understand that. But as I stated this effects both of them. Neither one works as documented.

If you look at my second comment you'll see that i used the NBT version. My point is that the normal slot argument doesn't work correctly. In the code it points to a slot in the adjacent container, but in the documentation it states that the slot argument refers to the slot in the players inventory.

Currently the only way to get the method to do its job is to manually specify fromSlot in the item argument.

That's an issue with the documentation, not really with the peripheral itself
It's inteded that the inventory manager uses toSlot for the removeItemFromPlayer function
I would recommend not using that "older" function and specify everything in the filter

These functions will be removed anyway in the future, so using the filters directly would be good practice