Talk:RemoveItem
Why does RemoveItem not have a TargetContainerID like RemoveAllItems? This could be useful for toggling the ownership flag (where the target is the same as the caller).
-- Grey Where's even the point in having an ownership override tag? Does that mean all objects of the id will be cleared from "stolen flag" or the first 50 items of that id with "stolen flag" will be removed, or what? edit: RemoveItem won't even compile with override flag, remove note?
How can an object have an inventory? I'd be pretty scared if a weapon had it's own items. This must surely be referring to the object's CONTAINERS inventory, right? --MaXiMiUS 20:49, 11 April 2006 (EDT)
-- Grey Nope, you get that wrong. The "calling object" is the container, since the function is run/called on the container, not on the item. One could possibly change ObjectID into ItemID, but for consistency reasons this should NOT be done, since ObjectID is used widely in the wiki. Note: I also removed the note on the retainownership flag, since it's clearly wrong, as of now.
Refresh and Lag notes
The notes come from my experience with the Keychain mod (by the way, credit for the refresh code should go to mmmpld - the code was in there long before I started working on it). I have a section of code that, when the player equips the Keychain, will either remove all the keys from a remote container back to the player (Unhook keys), or move all the keys from the player to the remote container.
;Take keys on/off the keychain when player equips it (Hook keys). begin onEquip player if Mode ;Unhook keys set Mode to 0 con_ToggleMenus P1DkeyContainer02.RemoveAllItems player, 1 ;Still causes lag in inventory menu, but AddItem does no better con_ToggleMenus ;Equipping and unequipping an item will force the inventory menu to update, showing the keys if (MenuMode 1002) message "Unhooked keys from Keychain" message "Unhooked keys from Keychain" player.EquipItem P1DKeychain player.UnEquipItem P1DKeychain else message "Unhooked keys from Keychain" endif else ;if (Mode == 0) ;Hook keys set Mode to 1 set NoKeysRemoved to 1 con_ToggleMenus message "Re-hooked keys to Keychain" message "Re-hooked keys to Keychain" set InvPos to 0 Label 2 set pItem to (player.GetInventoryObject InvPos) if pItem if (IsKey pItem) if (pItem != P1DKeychain) ;&& ((IsQuestItem pItem) == 0) set KeyCount to (player.GetItemCount pItem) P1DkeyContainer02.AddItem pItem KeyCount player.RemoveItem pItem KeyCount Label 3 set KeyCount to (player.GetItemCount pItem) if KeyCount player.RemoveItem pItem KeyCount Goto 3 endif if NoKeysRemoved set NoKeysRemoved to 0 endif else set InvPos to (InvPos + 1) endif else set InvPos to (InvPos + 1) endif Goto 2 endif con_ToggleMenus ;Refresh inventory menu if necessary if (MenuMode 1002) if (NoKeysRemoved == 0) player.EquipItem P1DKeychain player.UnEquipItem P1DKeychain endif endif endif end
If you comment out the Refresh inventory menu section and try it out in-game (tested with all the non-scripted keys from Oblivion and SI), when the keys are hooked all of the key icons will remain displayed, as if the player still had them. However, if you click on anything in the inventory, close and re-open the inventory, or move to a different tab and back the keys will correctly no longer show. Add back the Refresh inventory menu section and the keys will correctly disappear without the need to close the menu, etc.
If you comment out the con_ToggleMenus, there will be a noticeable pause/delay in the game (the player avatar stops bouncing). Add them back and the lag disappears.
Finally, if you extend the con_ToggleMenus section to include the Refresh inventory menu section, it will no longer refresh the menu.--Haama 16:07, 23 January 2008 (EST)
RemoveItem Bug
Based upon gameplay reports, there appears to be a bug with RemoveItem. I was wondering whether any modders could confirm this bug, and whether information about the bug belongs in the article.
The bug occurs if there are multiple stacks of the same item in an inventory. For example, if the player inventory contains both 15 legitimate Minotaur Horns and 10 stolen Minotaur Horns, then the command:
Player.RemoveItem MinotaurHorn 20
will attempt to remove all 20 minotaur horns from just one of the two stacks. Even if that stack contains less than 20 horns, and even if the other stack contains the other horns necessary to reach 20. Therefore, the player will end up with 15 legitimate horns or 10 stolen ones... instead of ending up with just 5 horns of one type or another. On the other hand, commands such as GetItemCount (correctly) sum all of the different stacks. So scripts for quests such as "Expelled from the Mages Guild" will check and see that the player has the 20 horns necessary for the quest -- but then won't actually remove all 20 horns.
This also happens with cases where items "invisibly" exist in multiple inventory slots. For example, on NPCs gold may come from multiple sources (multiple leveled lists from original inventory list; a separate stack for gold added by additem commands). Although only the total amount of gold is generally visible, "RemoveItem Gold001" will only empty the requested gold from one of the inventory slots, and therefore will not correctly reduce the NPC's available gold.
I'd guess it also happens with weapons/armor that have differing amounts of health, although I haven't seen specific examples of that. --Nephele 18:32, 10 June 2008 (EDT)
- Yes, the first example has been noted in the Troubleshooting section - oh, looks like someone's updated it with relevant info too, so follow the link. The same might apply to the NPC example as well, but I don't remember anyone trying it on an NPC.
- To be clear - when you say slots, do you mean multiple containers owned by the NPC, or multiple levelled lists on the NPC 'emself? For bartering, the player sees everything owned by the NPC in the cell - in multiple container, outside of containers, everything.--Haama 00:51, 11 June 2008 (EDT)
Removing torches
For the record: I've found recently that RemoveItem has a special behavior with torches (EditorID: Torch02 - Base FormID: 0002CF9F) (removing torches is usually done for poses and statues, so the NPC does not produce a torch at night)
The first attempt to remove torches removes just 2 torches, you need to repeat the function to actually remove all of them from the NPC inventory:
set iCount to refNPC.GetItemCount Torch02 refNPC.removeitem Torch02 iCount refNPC.removeitem Torch02 iCount
Really can't imagine why, but it is consistent.QQuix 18:13, 2 September 2009 (EDT)
- Could be because torch objects are actually LIGHT records ?
- shadeMe TALK 19:03, 2 September 2009 (EDT)
- May be, but, somehow, it seems directly related to Torch02. Further tests indicated that this behavior seem to occur only with if Torch02 items are present in the player inventory and a player copy is created with CreateFullActorCopy.
- To further clarify the issue:
- Player has 20 x Torch02
- Player clone is created with "Set PlayerCopyRef to Player.CreateFullActorCopy"
- A script uses a "PlayerCopyRef. RemoveItem Torch02 999"
- PlayerCopyRef now has 18 Torches02 - only 2 torches removed.
- A script uses a "PlayerCopyRef. RemoveItem Torch02 999" again
- All remaining torches removed from PlayerCopyRef.
- To further clarify the issue:
- If the player has no Torch02 items when cloned, you can add and remove Torch02 normally, but if the player has some, using the above example, if you add, say, 200 torches to the copy (totaling 220), the first RemoveItem still removes just 2 torches, leaving 218 in the inventory .
- This behavior does not occur with the other carriable lights (e.g the vanilla TestToddTorch or a new carriable light object). This behavior does not occur with NPCs. This behavior does not occur with copies of NPCs created with CreateFullActorCopy.
- It only happens with Player.CreateFullActorCopy. Weird, because, in one hand, I know it is not just me (I've found this while helping Sornan at Beth Forums and this fixed his problem). On the other hand, the vanilla player statue script uses just one RemoveItem function and I don't see a horde of players complaining their statue is holding a torch! Go figure. QQuix 10:22, 3 September 2009 (EDT)