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)