aVENGER_(RR) Posted November 14, 2007 Share Posted November 14, 2007 Contrary to the current IESDP description, action #116 - TakePartyItem(S:Item*) actually takes a single stack of the referenced items from the party instead of just one item. For example, if Player1 has 5 Potions of Extra Healing in his first quickslot and 3 Potions of Extra Healing in his second quickslot, then TakePartyItem("POTN52") would remove the entire stack of 5 potions from his first quickslot and leave the 3 potions in his second quickslot intact. As for action #204 - TakePartyItemNum(S:ResRef*,I:Num*) if a stack of items which is to be taken is currently inside one of the quickslots, then this action will bump the stack from the quickslot into the first free inventory slot after removing the desired item amount. For example, in the abovementioned situation, TakePartyItemNum("POTN52",1) would take 1 Potion of Extra Healing from the stack of potions in Player1's first quickslot and then place the remaining 4 potions into his first free inventory slot. No idea why it does that, but unfortunately, that can cause Player1 to drop an item to the ground in case all of his inventory slots are currently full. EDIT: it also appears that action 169 - DestroyItem(S:ResRef*) merely removes a single stack of the referenced item from the target's inventory, rather than completely removing all instances of the referenced item as IESDP currently states. Link to comment
devSin Posted November 14, 2007 Share Posted November 14, 2007 A is known (the reason you sometimes lose a whole stack of diamonds, etc., in the default game). I've never heard B mentioned, but it doesn't surprise me (it sounds like the engine does Take() and then Give(quantity - 1)). C is known (I'm not sure why the IESDP has that -- you need a "looping" condition or TakePartyItemAll() to get rid of every occurrence). Link to comment
Nythrun Posted November 14, 2007 Share Posted November 14, 2007 I've never heard B mentioned, but it doesn't surprise me (it sounds like the engine does Take() and then Give(quantity - 1)). I wonder if this is related to the oddness with TakePartyItemNum("item",x) on containers with y items where x > y, where you get the unremovable phantom item (I think it was Smoketest who found this)? Maybe the same thing happens to .cre files also? /edit No, it doesn't. Inventory droppage only occurs when Take X < Has Y. Link to comment
Avenger Posted November 15, 2007 Share Posted November 15, 2007 It is good to document all of these oddities, thanks. I consider the moving of the rest of the stack to another inventory slot as a bug. (Won't implement it in gemrb) Link to comment
aVENGER_(RR) Posted November 15, 2007 Author Share Posted November 15, 2007 Oddly, the "bumping" only happens if the item stack which should to be taken is currently inside one of the quickslots. OTOH, if the stack is in one of the inventory slots everything works fine and nothing gets dropped even if all other inventory slots are occupied. Link to comment
Smoketest Posted November 22, 2007 Share Posted November 22, 2007 I wonder if this is related to the oddness with TakePartyItemNum("item",x) on containers with y items where x > y, where you get the unremovable phantom item The bugs/oversights I noticed with TakePartyItemNum and TakePartyItemAll (in BG2) were tied to carried containers such as bags. - If you had only 20 Arrows and they were in a bag, and you used TakePartyItemNum("arow01",99), the item stack would appear to the player to have been completely removed, though a hidden "phantom" stack with a quantity of zero would remain in the bag's STO component. - If you try to remove all instances of an item with TakePartyItemAll, it will ignore whatever is stored in carried containers (bags). This annoying limitation is what prompted me to use TakePartyItemNum instead, which led to the above observation. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.